Solar Designer

> I found the body of `call_p_kallsyms_lookup_name` in `p_lkrg_main.o` rather than `p_exploit_detection.o` Oh, sure, sorry about that. And thanks. So this looks reasonable to me, assuming the relocations are properly...

@fluidog Besides using real exploits on deliberately not-up-to-date kernels, @Adam-pi3 also uses a custom deliberately vulnerable kernel module and exploits against it. We were thinking of cleaning this up, likely...

The sysctl setting used to be `unhide` prior to e5924c419a9565b940a67cc169ad3ba0ebc1f975 in 2017, so prior to public release of LKRG. Changing it to `hide` back then is what made `P_LKRG_UNHIDE` inconsistent...

Disabling `P_LKRG_UNHIDE` currently leaves `p_hide_itself` compiled in, and there's a call from `p_lkrg_register`: ```c if (P_CTRL(p_hide_lkrg)) { p_hide_itself(); } ``` However, there's nothing to enable that setting in such a...

> If we rename to `P_LKRG_HIDE`, Renamed to `LKRG_WITH_HIDE`, which is consistent with `LKRG_WITH_NET`. > we should also exclude that dead code in builds with `P_LKRG_HIDE` disabled. Done. > Alternatively,...

Thank you for reporting this. Those changes you suggest would hide the problem, which I'm not sure is the best thing to do, especially considering that it'd take some effort...

> My current thinking is that if you choose to install an RT kernel, you should uninstall LKRG. Why would you want to keep LKRG installed when it's not working?...

> There's BUILD_EXCLUSIVE_KERNEL I think we need the opposite of it, or else we need to somehow encode that negation in a regexp. Also, I expect the kernel version strings...

Somehow repeating a lighter version of the above command: ``` for n in `seq 0 999`; do sysctl lkrg.trigger=1; done ``` after LKRG reload (rmmod/insmod), did not result in high...

3 concurrent instances of the trigger loop, without ALERTs, gave this: ``` top - 19:36:37 up 1:44, 2 users, load average: 309.46, 100.91, 44.82 Tasks: 763 total, 9 running, 754...