The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Gregory Price <gourry@gourry.net>
To: Thomas Gleixner <tglx@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	kernel-team@meta.com, corbet@lwn.net, skhan@linuxfoundation.org,
	peterz@infradead.org, luto@kernel.org, akpm@linux-foundation.org,
	feng.tang@linux.alibaba.com, pmladek@suse.com,
	mhiramat@kernel.org, marc.herbert@linux.intel.com,
	joel.granados@kernel.org, lirongqing@baidu.com, kees@kernel.org,
	nathan@kernel.org, linusw@kernel.org, arnd@arndb.de,
	deller@gmx.de, jpoimboe@kernel.org, ruanjinjie@huawei.com,
	lukas.bulwahn@redhat.com, ryan.roberts@arm.com, ojeda@kernel.org
Subject: Re: [PATCH 1/2] kernel/entry: add CONFIG_SYSCALL_USER_DISPATCH to compile SUD out
Date: Fri, 3 Jul 2026 13:22:41 -0400	[thread overview]
Message-ID: <akfv4ecFcHMqx5Xp@fedora> (raw)
In-Reply-To: <87a4s8m69c.ffs@fw13>

On Fri, Jul 03, 2026 at 05:39:59PM +0200, Thomas Gleixner wrote:
> 
> I buy the miminal system aspect, but high security is just a voodoo
> argument. Why?
> 
>   1) The functionality needs to be enabled with a PRCTL, which can be
>      filtered.
> 
>   2) It requires LD_PRELOAD to be effective
> 
> If your high security system allows #2 then it's not a high security
> system to begin with. If you fail to add the proper filters then it does
> not pass the test either.
> 

sure, it can be filtered, but not all software runs in a sandbox and not
all attack vectors need end in priv-esc or launching new tasks.  It
does not require LD_PRELOAD to be useful to an attacker.

just as an example, if i land remote execution in a task, i can enable
syscall user dispatch and just steal cpu time from that task whenever it
makes a syscall without having to do any of the traditional tricks of
overwriting GDT entries to get hooks.  No need for ld preloading or even
leaving the active task's context.

syscall user dispatch is just a really clean, powerful tool for writing
implants.  I've been playing with it for the better part of 2 years and
just realized I don't want it enabled (or even present at all) on some
of my machines / machines I manage and there's no way to do that.

> I agree that disabling it alltogether reduces the effort, but it's not a
> prerequisite.
> 
> > +config SYSCALL_USER_DISPATCH
> > +	bool "Syscall User Dispatch (SUD)"
> > +	depends on GENERIC_ENTRY
> > +	default y
> > +	help
> > +	  Syscall User Dispatch (SUD) lets a thread have its own system calls
> > +	  redirected to a userspace handler.  It is used by emulators that run
> > +	  foreign binaries which issue system calls directly.
> 
> Huch?
> 
> What is foreign? Different country, different universe or different
> mindset?
> 
> It's also not restricted to emulators. It allows to intercept and abort
> system calls which are issued within a certain IP address range and
> redirect them to a emulator or debugger. 
> 

foreign meaning non-linux, but sure i'll change it to be more general.

> 
> >--- a/include/linux/syscall_user_dispatch.h
> >+++ b/include/linux/syscall_user_dispatch.h
> >@@ -7,8 +7,22 @@
> >
> > #include <linux/thread_info.h>
> > #include <linux/syscall_user_dispatch_types.h>
> > +#include <linux/sched.h>
> 
> Why does this require to pull in the heaviest header?
> 

we dereference current (struct task_struct)

> > +bool syscall_user_dispatch(struct pt_regs *regs);
> > +
> > +static inline bool syscall_user_dispatch_clear_on_dispatch(void)
> 
> Wants to be __always_inline as otherwise agressive compilers like CLANG
> happily put it out of line.
>

ack.

  reply	other threads:[~2026-07-03 17:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-27 20:55 [PATCH 1/2] kernel/entry: add CONFIG_SYSCALL_USER_DISPATCH to compile SUD out Gregory Price
2026-06-27 20:55 ` [PATCH 2/2] kernel/entry: add kernel.syscall_user_dispatch sysctl Gregory Price
2026-07-03 15:46   ` Thomas Gleixner
2026-07-03 17:26     ` Gregory Price
2026-07-03 19:06       ` Thomas Gleixner
2026-07-03 15:39 ` [PATCH 1/2] kernel/entry: add CONFIG_SYSCALL_USER_DISPATCH to compile SUD out Thomas Gleixner
2026-07-03 17:22   ` Gregory Price [this message]
2026-07-03 19:05     ` Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=akfv4ecFcHMqx5Xp@fedora \
    --to=gourry@gourry.net \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=corbet@lwn.net \
    --cc=deller@gmx.de \
    --cc=feng.tang@linux.alibaba.com \
    --cc=joel.granados@kernel.org \
    --cc=jpoimboe@kernel.org \
    --cc=kees@kernel.org \
    --cc=kernel-team@meta.com \
    --cc=linusw@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lirongqing@baidu.com \
    --cc=lukas.bulwahn@redhat.com \
    --cc=luto@kernel.org \
    --cc=marc.herbert@linux.intel.com \
    --cc=mhiramat@kernel.org \
    --cc=nathan@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=peterz@infradead.org \
    --cc=pmladek@suse.com \
    --cc=ruanjinjie@huawei.com \
    --cc=ryan.roberts@arm.com \
    --cc=skhan@linuxfoundation.org \
    --cc=tglx@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox