From: Thomas Gleixner <tglx@kernel.org>
To: Gregory Price <gourry@gourry.net>, linux-kernel@vger.kernel.org
Cc: 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,
gourry@gourry.net, 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, 03 Jul 2026 17:39:59 +0200 [thread overview]
Message-ID: <87a4s8m69c.ffs@fw13> (raw)
In-Reply-To: <20260627205551.769684-1-gourry@gourry.net>
Gregory!
On Sat, Jun 27 2026 at 16:55, Gregory Price wrote:
First a few formal notes.
- Multi patch series require a cover letter
- The subject prefix is not a matter of personal preference
See https://docs.kernel.org/process/maintainer-tip.html and the related
generic process documentation.
Please also refrain from made up acronyms in the subject line. What the
heck is SUD and why needs this to spell out the CONFIG option name
prominently.
syscall_user_dispatch: Make it configurable in Kconfig
or something like that is concise and clear, no?
> Syscall User Dispatch is built under CONFIG_GENERIC_SYSCALL and cannot
> be disabled independent of the core syscall-entry machinery.
>
> Native foreign-binary emulators (Wine/Proton) need it, but it should
> be an optional for minimal/high security systems.
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.
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.
>--- 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?
> +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.
Thanks,
tglx
next prev parent reply other threads:[~2026-07-03 15:40 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 ` Thomas Gleixner [this message]
2026-07-03 17:22 ` [PATCH 1/2] kernel/entry: add CONFIG_SYSCALL_USER_DISPATCH to compile SUD out Gregory Price
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=87a4s8m69c.ffs@fw13 \
--to=tglx@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=corbet@lwn.net \
--cc=deller@gmx.de \
--cc=feng.tang@linux.alibaba.com \
--cc=gourry@gourry.net \
--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 \
/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