On Wed, Feb 18, 2026 at 12:52 PM Steven Rostedt <[email protected]> wrote: > > 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
Fair, thanks for the quick responses.
