On Wed, 18 Feb 2026 07:18:25 -0800 Dave Hansen <[email protected]> wrote:
> ... adding kprobes folks and Kees to cc > > On 2/18/26 06:47, Elly I. Esparza wrote: > > Kprobes can be used by rootkits to find the address of x64_sys_call(), > > x32_sys_call() and ia32_sys_call(). This in turn allows for the rootkits > > to find an specific syscall handler and hook it. > > > > Add x64_sys_call(), x32_sys_call() and ia32_sys_call() to the kprobes > > blacklist. > I'm an occasional, but not super regular kprobes user. Is this going to > hurt folks who are legitimately probing the syscall dispatch functions? > > I'm a bit worried that the rootkits will just move on to something else > and this will become a never ending game of whack-a-mole where half the > kernel needs NOKPROBE_SYMBOL(). ;) Honesty, if you are worried about this, just run LOCKDOWN on tracing, and prevent *ALL* kprobes. Because yes, there's a 1000 ways to get this information once you have kprobes enabled and have root access. This patch is hurting legitimate debugging of running systems more than it is limiting rootkits from hacking the kernel. In other words, this is causing more harm than good. Because, I do hook these functions a lot, and this will definitely put a cramp into my debugging of running systems if this gets applied. noinstr has already hurt debugging NO_HZ_FULL to track when userspace goes into the kernel. Because now it's much more difficult to trace the latency the kernel causes a task. -- Steve
