[PATCH 1/2] x86: Prevent syscall hooking

[PATCH 1/2] x86: Prevent syscall hooking

[Elly I. Esparza]

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.

Signed-off-by: Elly I. Esparza <ellyesparza8@gmail.com>
---
 arch/x86/entry/syscall_32.c | 2 ++
 arch/x86/entry/syscall_64.c | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/arch/x86/entry/syscall_32.c b/arch/x86/entry/syscall_32.c
index 2b15ea17bb7c..75d34d2c8067 100644
--- a/arch/x86/entry/syscall_32.c
+++ b/arch/x86/entry/syscall_32.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0-only
 /* 32-bit system call dispatch */
 
+#include <linux/kprobes.h>
 #include <linux/linkage.h>
 #include <linux/sys.h>
 #include <linux/cache.h>
@@ -48,6 +49,7 @@ long ia32_sys_call(const struct pt_regs *regs, unsigned int nr)
 	default: return __ia32_sys_ni_syscall(regs);
 	}
 }
+NOKPROBE_SYMBOL(ia32_sys_call)
 
 static __always_inline int syscall_32_enter(struct pt_regs *regs)
 {
diff --git a/arch/x86/entry/syscall_64.c b/arch/x86/entry/syscall_64.c
index b6e68ea98b83..1e8045a499d4 100644
--- a/arch/x86/entry/syscall_64.c
+++ b/arch/x86/entry/syscall_64.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0-only
 /* 64-bit system call dispatch */
 
+#include <linux/kprobes.h>
 #include <linux/linkage.h>
 #include <linux/sys.h>
 #include <linux/cache.h>
@@ -39,6 +40,7 @@ long x64_sys_call(const struct pt_regs *regs, unsigned int nr)
 	default: return __x64_sys_ni_syscall(regs);
 	}
 }
+NOKPROBE_SYMBOL(x64_sys_call)
 
 #ifdef CONFIG_X86_X32_ABI
 long x32_sys_call(const struct pt_regs *regs, unsigned int nr)
@@ -48,6 +50,7 @@ long x32_sys_call(const struct pt_regs *regs, unsigned int nr)
 	default: return __x64_sys_ni_syscall(regs);
 	}
 }
+NOKPROBE_SYMBOL(x32_sys_call)
 #endif
 
 static __always_inline bool do_syscall_x64(struct pt_regs *regs, int nr)
-- 
2.43.0

Re: [PATCH 1/2] x86: Prevent syscall hooking

[Dave Hansen]

... 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(). ;)

Re: [PATCH 1/2] x86: Prevent syscall hooking

[Peter Zijlstra]

On Wed, Feb 18, 2026 at 07:18:25AM -0800, Dave Hansen 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(). ;)

So I really think this should be noinstr; pretty much all the code here
is noinstr already, so why not include the syscall dispatch.

Better still, noinstr ensures the spectre-v1 mitigation actually works.

Re: [PATCH 1/2] x86: Prevent syscall hooking

[H. Peter Anvin]

On February 18, 2026 7:32:44 AM PST, Peter Zijlstra <peterz@infradead.org> wrote:
>On Wed, Feb 18, 2026 at 07:18:25AM -0800, Dave Hansen 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(). ;)
>
>So I really think this should be noinstr; pretty much all the code here
>is noinstr already, so why not include the syscall dispatch.
>
>Better still, noinstr ensures the spectre-v1 mitigation actually works.

Yes, and merging the x64 and x32 dispatches into one function actually enables a lot of code sharing.

Re: [PATCH 1/2] x86: Prevent syscall hooking

[Steven Rostedt]

On Wed, 18 Feb 2026 07:18:25 -0800
Dave Hansen <dave.hansen@intel.com> 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

Re: [PATCH 1/2] x86: Prevent syscall hooking

[ellyndra]

On Wed, Feb 18, 2026 at 12:52 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Wed, 18 Feb 2026 07:18:25 -0800
> Dave Hansen <dave.hansen@intel.com> 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.

Re: [PATCH 1/2] x86: Prevent syscall hooking

[Kees Cook]

On Wed, Feb 18, 2026 at 10:52:04AM -0500, Steven Rostedt wrote:
> 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.

Yeah, I agree. If kprobes is available, there is a lot of harm an
attacker can already do. If a bright line between root/ring-0 is
desired, a system needs to be configured to be using lockdown or similar
things to turn off the interfaces that let root write to kernel state.

-- 
Kees Cook

Re: [PATCH 1/2] x86: Prevent syscall hooking

[Masami Hiramatsu]

On Thu, 19 Feb 2026 10:45:02 -0800
Kees Cook <kees@kernel.org> wrote:

> On Wed, Feb 18, 2026 at 10:52:04AM -0500, Steven Rostedt wrote:
> > 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.
> 
> Yeah, I agree. If kprobes is available, there is a lot of harm an
> attacker can already do. If a bright line between root/ring-0 is
> desired, a system needs to be configured to be using lockdown or similar
> things to turn off the interfaces that let root write to kernel state.

Agreed. The blacklist (or blocklist) of kprobes is designed for preventing
nesting software breakpoint handling, not for security.

Thank you,

-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>

Re: [PATCH 1/2] x86: Prevent syscall hooking

[Christoph Hellwig]

On Fri, Feb 20, 2026 at 11:45:40AM +0900, Masami Hiramatsu wrote:
> On Thu, 19 Feb 2026 10:45:02 -0800
> Kees Cook <kees@kernel.org> wrote:
> 
> > On Wed, Feb 18, 2026 at 10:52:04AM -0500, Steven Rostedt wrote:
> > > 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.
> > 
> > Yeah, I agree. If kprobes is available, there is a lot of harm an
> > attacker can already do. If a bright line between root/ring-0 is
> > desired, a system needs to be configured to be using lockdown or similar
> > things to turn off the interfaces that let root write to kernel state.
> 
> Agreed. The blacklist (or blocklist) of kprobes is designed for preventing
> nesting software breakpoint handling, not for security.

It still can be useful.  As mention in the other thread, we just need
to make it clear.  I.e. add something like "noprobe_for_security".
And if we really, really care it could be conditional on a config
option.

Re: [PATCH 1/2] x86: Prevent syscall hooking

[Steven Rostedt]

On Fri, 20 Feb 2026 09:04:39 -0800
Christoph Hellwig <hch@infradead.org> wrote:

> > Agreed. The blacklist (or blocklist) of kprobes is designed for preventing
> > nesting software breakpoint handling, not for security.  
> 
> It still can be useful.  As mention in the other thread, we just need
> to make it clear.  I.e. add something like "noprobe_for_security".
> And if we really, really care it could be conditional on a config
> option.

As I already mentioned, we have the LOCKDOWN infrastructure for that. If
you care about security of kprobes, use lockdown to disable it. As
previously stated, there's 1000 other ways kprobes can get this same
information. Adding a "noprobe_for_security" will lead to a false sense of
security. Basically the same as leaving your car unlocked and hiding the
keys in the visor and thinking nobody will steal your car.

-- Steve