From xiyou.wangcong at gmail.com  Wed Jul  1 14:31:34 2026
From: xiyou.wangcong at gmail.com (Cong Wang)
Date: Wed, 1 Jul 2026 14:31:34 -0700
Subject: [PATCH 0/7] um: skas: harden the seccomp userspace stub
In-Reply-To: <c4bc735d4413410c6ff5c5011ebdf0fffe05866f.camel@sipsolutions.net>
References: <cover.1781925126.git.xiyou.wangcong@gmail.com>
 <1e1681eecfa5dd30181534674b1a17756df802f8.camel@sipsolutions.net>
 <CAM_iQpWj+daY6tsPXKq=B4ekjr-8-tpfX+2twLhW_oGP_YqOHw@mail.gmail.com>
 <03b2134eea62d664781069c8bd072705e0fc4aee.camel@sipsolutions.net>
 <CAM_iQpUc4dQvYXbGpUgBXke+a8hVXnBCtjziXd1QX=QJXWiwjA@mail.gmail.com> <c4bc735d4413410c6ff5c5011ebdf0fffe05866f.camel@sipsolutions.net>
Message-ID: <CAM_iQpU_GdBn3b=PmWRgoKYmJOoAN58+-sO7xsEb5oTQvDopTw@mail.gmail.com>

On Sat, Jun 27, 2026 at 9:21?AM Benjamin Berg <benjamin at sipsolutions.net> wrote:
>
> Hi,
>
> On Wed, 2026-06-24 at 16:12 -0700, Cong Wang wrote:
> > On Wed, Jun 24, 2026 at 12:54?AM Benjamin Berg
> > <benjamin at sipsolutions.net> wrote:
> > >
> > > On Tue, 2026-06-23 at 15:08 -0700, Cong Wang wrote:
> > > > On Mon, Jun 22, 2026 at 5:08?AM Benjamin Berg <benjamin at sipsolutions.net> wrote:
> > > > >
> > > > > On Fri, 2026-06-19 at 20:22 -0700, Cong Wang wrote:
> > > > > > From: Cong Wang <cwang at multikernel.io>
> > > > > >
> > > > > > In the seccomp ("SECCOMP") userspace mode, each guest userspace process
> > > > > > runs in a stub under a seccomp filter and traps to the monitor (the UML
> > > > > > kernel) on every syscall. Two items on the stub.c "Known security issues"
> > > > > > list could not be addressed by the filter alone:
> > > > > >
> > > > > >   - a hijacked stub could mmap() arbitrary physmem offsets, which is an
> > > > > >     intra-guest disclosure and, on this base (single physmem fd, no
> > > > > >     kernel/user split), a host escape; and
> > > > > >
> > > > > >   - a hijacked stub could block SIGALRM via a crafted rt_sigreturn to
> > > > > >     evade preemption and wedge the monitor indefinitely.
> > > > > >
> > > > > > This series closes both:
> > > > > >
> > > > > >   1-2: route the stub's mmap() through a SECCOMP_RET_USER_NOTIF listener
> > > > > >        owned by the monitor (no behavioural change yet).
> > > > > >   3-4: validate each mmap() against the mm's page table -- allowed iff the
> > > > > >        PTE already maps the requested frame with no more access than it
> > > > > >        grants -- including out-of-batch mmaps a hijacked stub issues on
> > > > > >        its own.
> > > > > >   5:   route and validate munmap() the same way (range-confined below
> > > > > >        STUB_START).
> > > > >
> > > > >
> > > > > That approach seems odd to me. Adding an explicit out-of-band check
> > > > > means you require two extra context switches per mmap syscall. I would
> > > > > expect that this makes the SECCOMP approach a lot slower than ptrace().
> > > > > My take is still that it is possible to carefully craft a SECCOMP
> > > > > filter as well as stub/kernel code that makes exploitation impossible
> > > > > for non-SMP.
> > > > >
> > > > > The true SMP case is more complicated, but we do not have that anyway,
> > > > > so I would not worry about it for now.
> > > > >
> > > > > Did you run any performance tests?
> > > >
> > > > Sorry, I thought I included them in patch 4/7, but I missed them.
> > > >
> > > > Here they are:
> > > >
> > > > mmap() -- ns/call
> > > > -----------------
> > > > size   WITH med   WITHOUT med   delta            WITH p99   WITHOUT p99
> > > > 4K     13056      10368         +2688  (+26%)     17408      15104
> > > > 16K    13824      11008         +2816  (+26%)     15616      12544
> > > > 64K    19840      15616         +4224  (+27%)     21760      17408
> > > > 256K   33152      28928         +4224  (+15%)     36352      31744
> > > > 1M     95616      84608         +11008 (+13%)     117504     108032
> > > >
> > > > munmap() -- ns/call
> > > > -------------------
> > > > size   WITH med   WITHOUT med   delta            WITH p99   WITHOUT p99
> > > > 4K     11008      8448          +2560  (+30%)     13568      11264
> > > > 16K    10752      8448          +2304  (+27%)     12288      9472
> > > > 64K    12032      9728          +2304  (+24%)     13824      10752
> > > > 256K   15360      12800         +2560  (+20%)     17152      14592
> > > > 1M     27648      24832         +2816  (+11%)     30976      26880
> > > >
> > > > Since this is a clear security-vs-performance balance, I picked security
> > > > over performance. Please let me know if you prefer otherwise.
> > >
> > > So, I still believe that (almost) zero-overhead is possible in the
> > > current framework. Maybe one could add a non-zero overhead option, but
> > > then I would like to be able to disable it as there are plenty of
> > > scenarios where security is of no concern.
> >
> > This is fair, I can add an option to keep it disabled by default.
>
> Sure. But I still think that a discussion is needed on whether another
> option is viable. I would really prefer not adding your proposed
> solution if another low/zero overhead option is viable.
>
> And I still absolutely believe that it is viable to modify the current
> code and make it secure. I just never finished that work because it
> requires a lot of care and it is not that important to us.

OK. Just to provide more context: I am evaluating using UML for
multi-tenant cloud, security is a must there, not just optional.

I guess I might be the first one doing so, otherwise these security
issues would have been resolved. :)

>
> > > Also, I am unsure what you measured there. When you write "mmap" here,
> > > is that an "mmap" call made by the userspace process (which might not
> > > actually change the page mappings), or is that an "mmap" call that was
> > > queued for the stub to process?
> > >
> > > A large amount of the overhead that UML tends to have happens when
> > > handling both minor and major page faults. Simple tests for this is for
> > > example a relatively tight fork/exec loop or just applications starting
> > > up. In our test runs, we saw major speed improvements (>10%) just by
> > > fixing bugs in the TLB handling code that resulted in fewer page faults
> > > happening at application runtime.
> >
> > It is just a simple user-space mmap() loop just for benchmarking this
> > patchset.
>
> If you just say "mmap() loop" I think that you are purely doing an
> mmap/unmap syscall of anonymous memory in a loop. However, the kernel
> may not map any of those pages until they are actually accessed. I
> would not have been surprised if you did not see any performance
> difference at all in such a test.
>
> Are you actually touching (writing) each of the mapped pages?

Yes, with MAP_POPULATE. Sorry for forgetting to mention it.

>
> > > > Meanwhile, after a second thought, there is a zero-overhead solution.
> > > > pidfd_mmap(), which can be built on top of another patch of mine:
> > > > https://lore.kernel.org/all/20260613001533.314739-2-xiyou.wangcong at gmail.com/
> > >
> > > Sure, should some sort of method land that allows directly modifying
> > > the mappings of the remote process, that would be rather convenient.
> > >
> >
> > Great. I will work on it. One question: should I drop this one or we can use
> > this one as the short term solution before the pidfd_mmap() solution gets in?
> > Even if we had pidfd_mmap(), UML might still want to keep compatibility with
> > older host kernels?
>
> Of course, UML should not regress on older kernels. Also, any new API
> like that will probably still take a while. That said, I am not sure
> there is a pressing need to fix the security problem as long as we have
> ptrace mode available.

Maybe I am greedy, I want both security and performance. I ruled out
ptrace model due to low performance and try to improve seccomp mode
for better security.

Anyway, I agree to drop this patchset and work on pidfd_mmap(),
I will send them out shortly.

>
> >
> > > > Something like:
> > > >
> > > > int map(struct mm_id *mm_idp, unsigned long virt, unsigned long len, int prot,
> > > >         int phys_fd, unsigned long long offset)
> > > > {
> > > >         return pidfd_mmap(mm_idp->stub_pidfd, (void *)virt, len,
> > > >                           prot_to_mmap(prot), MAP_FIXED | MAP_SHARED,
> > > >                           phys_fd, offset);
> > > > }
> > > > int unmap(struct mm_id *mm_idp, unsigned long addr, unsigned long len)
> > > > {
> > > >         return pidfd_munmap(mm_idp->stub_pidfd, (void *)addr, len);
> > > > }
> > > >
> > > > Obviously, this one requires a new syscall for the host kernel first.
> > > >
> > > > >
> > > > > >   6:   add a watchdog thread that detects a stub which stops reporting
> > > > > >        back (e.g. blocked SIGALRM) and SIGKILLs it, letting the monitor
> > > > > >        recover via the existing teardown.
> > > > >
> > > > > That also seems like an odd solution to me. Architecturally, UML first
> > > > > receives the SIGALRM and forwards it to the child. It would seem much
> > > > > easier to set a flag and clear it again when the process reports back
> > > > > that it received the SIGALRM. Then, when the kernel receives the next
> > > > > SIGALRM, just kill the child immediately if the flag is still set.
> > > >
> > > > The flag-and-recheck scheme matches the ptrace path (wait_stub_done), where
> > > > the monitor is the tracer: it sees the stub's SIGALRM as a waitpid()
> > > > signal-stop and PTRACE_CONTs it, so "monitor receives, then deals with the
> > > > child" is accurate there. This patch is on the seccomp path
> > > > (wait_stub_done_seccomp), which is architecturally different.
> > > >
> > > > Or am I missing anything?
> > >
> > > The fact that it is not actually different from an architectural
> > > standpoint. In both cases SIGALRM is reported back to the kernel. It
> > > obviously has to be reported back, otherwise scheduling would not work.
> >
> > You're right.
> >
> > In the seccomp path the monitor also receives the SIGALRM and
> > forwards it to the stub: the per-vCPU POSIX timer targets the monitor thread
> > and um_timer() -> os_alarm_process() -> kill(stub, SIGALRM) forwards
> > the tick. ptrace vs. seccomp differ only in how the monitor
> > learns the stub stopped (waitpid vs. futex), not in the point you raised.
> >
> > So the watchdog thread is redundant. The inner FUTEX_WAIT loop in
> > wait_stub_done_seccomp already wakes on every forwarded tick via EINTR;
> > responsive stub acks by flipping data->futex out of FUTEX_IN_CHILD, a
> > SIGALRM-blocking one doesn't, exactly your flag scheme. I'll drop the helper
> > thread and timerfd and detect the stall inline: count consecutive ticks where
> > the stub didn't report and goto out_kill past a small threshold.
>
> Not sure I follow and the description makes me wonder if it was written
> by an LLM. To me it seems overly complicated and incorrect in subtle
> ways.

Yes, I marked it with Assisted-by: Claude:claude-opus-4.8.

Thanks.


From tglx at kernel.org  Fri Jul  3 02:48:49 2026
From: tglx at kernel.org (Thomas Gleixner)
Date: Fri, 03 Jul 2026 11:48:49 +0200
Subject: [PATCH v16 01/18] seccomp: Convert __secure_computing() to
 return boolean
In-Reply-To: <akdp6GAu77-ipsXA@kunlun.suse.cz>
References: <20260629130616.642022-1-ruanjinjie@huawei.com>
 <20260629130616.642022-2-ruanjinjie@huawei.com>
 <akdp6GAu77-ipsXA@kunlun.suse.cz>
Message-ID: <87cxx4mmim.ffs@fw13>

On Fri, Jul 03 2026 at 09:51, Michal Such?nek wrote:
> On Mon, Jun 29, 2026 at 09:05:59PM +0800, Jinjie Ruan wrote:
>> -	if (secure_computing())
>> +	if (!secure_computing())
>>  		return -1;
>
> Hello,
>
> I am not fond of this logic inversion. The boolean is meaningless in
> itself.
>
> Previously -1 was used to indicate that the syscall was filtered but you
> chose to invert the logic choosing true to mean syscall was not filtered.
>
> You could choose true to mean that syscall was fitered avoiding this
> inversion.

That's just wrong. Boolean logic makes more sense with having
(!condition()). Just because the old 0/-1 nonsense had it the other way
round does not mean it has to stay that way.

> Sashiko points out some places in existing code where it supposedly
> explodes which might or might not be true

The vsyscall one is correct, but that's a bug like any other one and should
be caught in review.

The blurb about bypass is AI halluzination nonsense.

> but any in-flight patches that use secure_computing would also be
> affected.

Maintainers know how to deal with collisions of that kind. Stop making
problems up.



From mark.rutland at arm.com  Fri Jul  3 03:00:11 2026
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 3 Jul 2026 11:00:11 +0100
Subject: [PATCH v16 01/18] seccomp: Convert __secure_computing() to
 return boolean
In-Reply-To: <87cxx4mmim.ffs@fw13>
References: <20260629130616.642022-1-ruanjinjie@huawei.com>
 <20260629130616.642022-2-ruanjinjie@huawei.com>
 <akdp6GAu77-ipsXA@kunlun.suse.cz>
 <87cxx4mmim.ffs@fw13>
Message-ID: <akeIK5TRCjlKbzbp@J2N7QTR9R3>

On Fri, Jul 03, 2026 at 11:48:49AM +0200, Thomas Gleixner wrote:
> On Fri, Jul 03 2026 at 09:51, Michal Such?nek wrote:
> > On Mon, Jun 29, 2026 at 09:05:59PM +0800, Jinjie Ruan wrote:
> >> -	if (secure_computing())
> >> +	if (!secure_computing())
> >>  		return -1;
> >
> > Hello,
> >
> > I am not fond of this logic inversion. The boolean is meaningless in
> > itself.
> >
> > Previously -1 was used to indicate that the syscall was filtered but you
> > chose to invert the logic choosing true to mean syscall was not filtered.
> >
> > You could choose true to mean that syscall was fitered avoiding this
> > inversion.
> 
> That's just wrong. Boolean logic makes more sense with having
> (!condition()). Just because the old 0/-1 nonsense had it the other way
> round does not mean it has to stay that way.

100% agreed!

Bikeshedding below; sorry.

I think the bigger problem is just that secure_computing() is a terrible
name that does not express the intended semantic -- it's not clear
whether "secure computing" means "seccomp permit the syscall" or
"seccomp is enabled and some special rules now apply" or something else
entirely.

If we're changing the return type, it might be worth renaming the
function something like:

	seccomp_permits_syscall()

... so for the code quoted at the start of the mail, we'd have:

	if (!seccomp_permits_syscall())
		return -1;

... or for arm64, where we have NO_SYSCALL:

	 if (!seccomp_permits_syscall())
	 	return NO_SYSCALL.

Thomas, any thoughts on that?

It's also odd that seccomp aquires the syscall number itself via , rather
than than being passed down explicitly by the arch code. That completely
obscures what seccomp is doing, vs having:

	if (!seccomp_permis_syscall(syscall))
		...

... but I guess that saves some duplication in the ptrace code.

Mark.


From msuchanek at suse.de  Fri Jul  3 03:27:26 2026
From: msuchanek at suse.de (Michal =?iso-8859-1?Q?Such=E1nek?=)
Date: Fri, 3 Jul 2026 12:27:26 +0200
Subject: [PATCH v16 01/18] seccomp: Convert __secure_computing() to
 return boolean
In-Reply-To: <akeIK5TRCjlKbzbp@J2N7QTR9R3>
References: <20260629130616.642022-1-ruanjinjie@huawei.com>
 <20260629130616.642022-2-ruanjinjie@huawei.com>
 <akdp6GAu77-ipsXA@kunlun.suse.cz>
 <87cxx4mmim.ffs@fw13>
 <akeIK5TRCjlKbzbp@J2N7QTR9R3>
Message-ID: <akeOjqMy7HVgRRCr@kunlun.suse.cz>

On Fri, Jul 03, 2026 at 11:00:11AM +0100, Mark Rutland wrote:
> On Fri, Jul 03, 2026 at 11:48:49AM +0200, Thomas Gleixner wrote:
> > On Fri, Jul 03 2026 at 09:51, Michal Such?nek wrote:
> > > On Mon, Jun 29, 2026 at 09:05:59PM +0800, Jinjie Ruan wrote:
> > >> -	if (secure_computing())
> > >> +	if (!secure_computing())
> > >>  		return -1;
> > >
> > > Hello,
> > >
> > > I am not fond of this logic inversion. The boolean is meaningless in
> > > itself.
> > >
> > > Previously -1 was used to indicate that the syscall was filtered but you
> > > chose to invert the logic choosing true to mean syscall was not filtered.
> > >
> > > You could choose true to mean that syscall was fitered avoiding this
> > > inversion.
> > 
> > That's just wrong. Boolean logic makes more sense with having
> > (!condition()). Just because the old 0/-1 nonsense had it the other way
> > round does not mean it has to stay that way.
> 
> 100% agreed!
> 
> Bikeshedding below; sorry.
> 
> I think the bigger problem is just that secure_computing() is a terrible
> name that does not express the intended semantic -- it's not clear
> whether "secure computing" means "seccomp permit the syscall" or
> "seccomp is enabled and some special rules now apply" or something else
> entirely.
> 
> If we're changing the return type, it might be worth renaming the
> function something like:
> 
> 	seccomp_permits_syscall()

Then not only it is clear which way the boolean value should be
interpreted, it also pervents the accidental inversion of existing
calls. Overall great.

Thanks

Michal


From mkchauras at gmail.com  Fri Jul  3 04:13:11 2026
From: mkchauras at gmail.com (Mukesh Kumar Chaurasiya)
Date: Fri, 3 Jul 2026 16:43:11 +0530
Subject: [PATCH v16 02/18] syscall_user_dispatch: Introduce a weak
 fallback for arch_syscall_is_vdso_sigreturn()
In-Reply-To: <20260629130616.642022-3-ruanjinjie@huawei.com>
References: <20260629130616.642022-1-ruanjinjie@huawei.com>
 <20260629130616.642022-3-ruanjinjie@huawei.com>
Message-ID: <akeYzL3uQoxaddgU@li-1a3e774c-28e4-11b2-a85c-acc9f2883e29.ibm.com>

On Mon, Jun 29, 2026 at 09:06:00PM +0800, Jinjie Ruan wrote:
> Currently, multiple architectures (LoongArch, RISC-V, S390, Powerpc)
> provide identical stubs for arch_syscall_is_vdso_sigreturn() that simply
> return false. This results in redundant boilerplate code across the tree.
> 
> Introduce a default __weak implementation of
> arch_syscall_is_vdso_sigreturn() directly in syscall_user_dispatch.c that
> returns false. This allows architectures that do not utilize a vDSO
> sigreturn to entirely drop their redundant inline definitions.
> 
> Architectures requiring a specialized check (such as x86) will continue to
> override this fallback with their strong symbol definitions.
> 
> Clean up the redundant implementations in loongarch, riscv, s390
> and powerpc.
> 
> Cc: Thomas Gleixner <tglx at kernel.org>
> Signed-off-by: Jinjie Ruan <ruanjinjie at huawei.com>
> ---
>  arch/loongarch/include/asm/syscall.h  | 5 -----
>  arch/powerpc/include/asm/syscall.h    | 5 -----
>  arch/riscv/include/asm/syscall.h      | 5 -----
>  arch/s390/include/asm/syscall.h       | 5 -----
>  include/linux/syscall_user_dispatch.h | 1 +
>  kernel/entry/syscall_user_dispatch.c  | 5 +++++
>  6 files changed, 6 insertions(+), 20 deletions(-)
> 
> diff --git a/arch/loongarch/include/asm/syscall.h b/arch/loongarch/include/asm/syscall.h
> index df8ea223c77b..946886794ced 100644
> --- a/arch/loongarch/include/asm/syscall.h
> +++ b/arch/loongarch/include/asm/syscall.h
> @@ -85,9 +85,4 @@ static inline int syscall_get_arch(struct task_struct *task)
>  #endif
>  }
>  
> -static inline bool arch_syscall_is_vdso_sigreturn(struct pt_regs *regs)
> -{
> -	return false;
> -}
> -
>  #endif	/* __ASM_LOONGARCH_SYSCALL_H */
> diff --git a/arch/powerpc/include/asm/syscall.h b/arch/powerpc/include/asm/syscall.h
> index 834fcc4f7b54..4b3c52ed6e9d 100644
> --- a/arch/powerpc/include/asm/syscall.h
> +++ b/arch/powerpc/include/asm/syscall.h
> @@ -139,9 +139,4 @@ static inline int syscall_get_arch(struct task_struct *task)
>  	else
>  		return AUDIT_ARCH_PPC64;
>  }
> -
> -static inline bool arch_syscall_is_vdso_sigreturn(struct pt_regs *regs)
> -{
> -	return false;
> -}
>  #endif	/* _ASM_SYSCALL_H */
> diff --git a/arch/riscv/include/asm/syscall.h b/arch/riscv/include/asm/syscall.h
> index 8067e666a4ca..987c9a78806f 100644
> --- a/arch/riscv/include/asm/syscall.h
> +++ b/arch/riscv/include/asm/syscall.h
> @@ -112,11 +112,6 @@ static inline void syscall_handler(struct pt_regs *regs, ulong syscall)
>  	regs->a0 = fn(regs);
>  }
>  
> -static inline bool arch_syscall_is_vdso_sigreturn(struct pt_regs *regs)
> -{
> -	return false;
> -}
> -
>  asmlinkage long sys_riscv_flush_icache(uintptr_t, uintptr_t, uintptr_t);
>  
>  asmlinkage long sys_riscv_hwprobe(struct riscv_hwprobe *, size_t, size_t,
> diff --git a/arch/s390/include/asm/syscall.h b/arch/s390/include/asm/syscall.h
> index 4271e4169f45..5f310caad1fc 100644
> --- a/arch/s390/include/asm/syscall.h
> +++ b/arch/s390/include/asm/syscall.h
> @@ -89,11 +89,6 @@ static inline int syscall_get_arch(struct task_struct *task)
>  	return AUDIT_ARCH_S390X;
>  }
>  
> -static inline bool arch_syscall_is_vdso_sigreturn(struct pt_regs *regs)
> -{
> -	return false;
> -}
> -
>  #define SYSCALL_FMT_0
>  #define SYSCALL_FMT_1 , "0" (r2)
>  #define SYSCALL_FMT_2 , "d" (r3) SYSCALL_FMT_1
> diff --git a/include/linux/syscall_user_dispatch.h b/include/linux/syscall_user_dispatch.h
> index 3858a6ffdd5c..73d69e02807d 100644
> --- a/include/linux/syscall_user_dispatch.h
> +++ b/include/linux/syscall_user_dispatch.h
> @@ -10,6 +10,7 @@
>  
>  #ifdef CONFIG_GENERIC_ENTRY
>  
> +bool arch_syscall_is_vdso_sigreturn(struct pt_regs *regs);
>  int set_syscall_user_dispatch(unsigned long mode, unsigned long offset,
>  			      unsigned long len, char __user *selector);
>  
> diff --git a/kernel/entry/syscall_user_dispatch.c b/kernel/entry/syscall_user_dispatch.c
> index d89dffcc2d64..acf545774d37 100644
> --- a/kernel/entry/syscall_user_dispatch.c
> +++ b/kernel/entry/syscall_user_dispatch.c
> @@ -32,6 +32,11 @@ static void trigger_sigsys(struct pt_regs *regs)
>  	force_sig_info(&info);
>  }
>  
> +bool __weak arch_syscall_is_vdso_sigreturn(struct pt_regs *regs)
> +{
> +	return false;
> +}
> +
>  bool syscall_user_dispatch(struct pt_regs *regs)
>  {
>  	struct syscall_user_dispatch *sd = &current->syscall_dispatch;
> -- 
> 2.34.1
> 

Build and boot tested on ppc with P11 LPAR. LGTM.

Tested-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras at gmail.com>
Reviewed-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras at gmail.com>


From mark.rutland at arm.com  Fri Jul  3 04:43:53 2026
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 3 Jul 2026 12:43:53 +0100
Subject: [PATCH v16 02/18] syscall_user_dispatch: Introduce a weak
 fallback for arch_syscall_is_vdso_sigreturn()
In-Reply-To: <20260629130616.642022-3-ruanjinjie@huawei.com>
References: <20260629130616.642022-1-ruanjinjie@huawei.com>
 <20260629130616.642022-3-ruanjinjie@huawei.com>
Message-ID: <akegeU59jSK9t7FX@J2N7QTR9R3>

On Mon, Jun 29, 2026 at 09:06:00PM +0800, Jinjie Ruan wrote:
> Currently, multiple architectures (LoongArch, RISC-V, S390, Powerpc)
> provide identical stubs for arch_syscall_is_vdso_sigreturn() that simply
> return false. This results in redundant boilerplate code across the tree.
> 
> Introduce a default __weak implementation of
> arch_syscall_is_vdso_sigreturn() directly in syscall_user_dispatch.c that
> returns false. This allows architectures that do not utilize a vDSO
> sigreturn to entirely drop their redundant inline definitions.
> 
> Architectures requiring a specialized check (such as x86) will continue to
> override this fallback with their strong symbol definitions.
> 
> Clean up the redundant implementations in loongarch, riscv, s390
> and powerpc.

> +bool __weak arch_syscall_is_vdso_sigreturn(struct pt_regs *regs)
> +{
> +	return false;
> +}

If we need this, please make it:

#ifndef arch_syscall_is_vdso_sigreturn
static inline bool arch_syscall_is_vdso_sigreturn(struct pt_regs *regs)
{
	return false;
}
#endif

... and require that architectures which need this provide a CPP
definition.

The use of __weak is generally problematic, as it prevents the compiler
form being able to elide code, and gets in the way of symbol resolution.
It's perfectly fine to require that architectures need to provide a CPP
definition alongside their own implementation of this function.

That said, as per my comment on v15, I'd prefer that for now we DO NOT
enable syscall user dispatch on arm64, and we first make it possible for
architecture to express whether or not they support that, even if they
use GENERIC_ENTRY. That might mean this patch isn't necessary right now.

[1] https://lore.kernel.org/linux-arm-kernel/akZgV0Y4YAmB43_g at J2N7QTR9R3.cambridge.arm.com/

Mark.


From kevin.brodsky at arm.com  Fri Jul  3 04:59:21 2026
From: kevin.brodsky at arm.com (Kevin Brodsky)
Date: Fri, 3 Jul 2026 13:59:21 +0200
Subject: [PATCH v16 01/18] seccomp: Convert __secure_computing() to return
 boolean
In-Reply-To: <akeOjqMy7HVgRRCr@kunlun.suse.cz>
References: <20260629130616.642022-1-ruanjinjie@huawei.com>
 <20260629130616.642022-2-ruanjinjie@huawei.com>
 <akdp6GAu77-ipsXA@kunlun.suse.cz> <87cxx4mmim.ffs@fw13>
 <akeIK5TRCjlKbzbp@J2N7QTR9R3> <akeOjqMy7HVgRRCr@kunlun.suse.cz>
Message-ID: <fa1f5b39-2703-40a1-81d6-3feba87e19b0@arm.com>

On 03/07/2026 12:27, Michal Such?nek wrote:
> On Fri, Jul 03, 2026 at 11:00:11AM +0100, Mark Rutland wrote:
>> On Fri, Jul 03, 2026 at 11:48:49AM +0200, Thomas Gleixner wrote:
>>> On Fri, Jul 03 2026 at 09:51, Michal Such?nek wrote:
>>>> On Mon, Jun 29, 2026 at 09:05:59PM +0800, Jinjie Ruan wrote:
>>>>> -	if (secure_computing())
>>>>> +	if (!secure_computing())
>>>>>  		return -1;
>>>> Hello,
>>>>
>>>> I am not fond of this logic inversion. The boolean is meaningless in
>>>> itself.
>>>>
>>>> Previously -1 was used to indicate that the syscall was filtered but you
>>>> chose to invert the logic choosing true to mean syscall was not filtered.
>>>>
>>>> You could choose true to mean that syscall was fitered avoiding this
>>>> inversion.
>>> That's just wrong. Boolean logic makes more sense with having
>>> (!condition()). Just because the old 0/-1 nonsense had it the other way
>>> round does not mean it has to stay that way.
>> 100% agreed!
>>
>> Bikeshedding below; sorry.
>>
>> I think the bigger problem is just that secure_computing() is a terrible
>> name that does not express the intended semantic -- it's not clear
>> whether "secure computing" means "seccomp permit the syscall" or
>> "seccomp is enabled and some special rules now apply" or something else
>> entirely.
>>
>> If we're changing the return type, it might be worth renaming the
>> function something like:
>>
>> 	seccomp_permits_syscall()
> Then not only it is clear which way the boolean value should be
> interpreted, it also pervents the accidental inversion of existing
> calls. Overall great.

Totally agreed, if we have the opportunity to rename a completely
undescriptive function name like "secure_computing" we should take it.

- Kevin


From tglx at kernel.org  Fri Jul  3 13:52:43 2026
From: tglx at kernel.org (Thomas Gleixner)
Date: Fri, 03 Jul 2026 22:52:43 +0200
Subject: [PATCH v16 01/18] seccomp: Convert __secure_computing() to
 return boolean
In-Reply-To: <fa1f5b39-2703-40a1-81d6-3feba87e19b0@arm.com>
References: <20260629130616.642022-1-ruanjinjie@huawei.com>
 <20260629130616.642022-2-ruanjinjie@huawei.com>
 <akdp6GAu77-ipsXA@kunlun.suse.cz> <87cxx4mmim.ffs@fw13>
 <akeIK5TRCjlKbzbp@J2N7QTR9R3> <akeOjqMy7HVgRRCr@kunlun.suse.cz>
 <fa1f5b39-2703-40a1-81d6-3feba87e19b0@arm.com>
Message-ID: <87echjlrs4.ffs@fw13>

On Fri, Jul 03 2026 at 13:59, Kevin Brodsky wrote:
> On 03/07/2026 12:27, Michal Such?nek wrote:
>>> If we're changing the return type, it might be worth renaming the
>>> function something like:
>>>
>>> 	seccomp_permits_syscall()
>> Then not only it is clear which way the boolean value should be
>> interpreted, it also pervents the accidental inversion of existing
>> calls. Overall great.
>
> Totally agreed, if we have the opportunity to rename a completely
> undescriptive function name like "secure_computing" we should take it.

Absolutely no objections from my side on that.


From hpa at zytor.com  Fri Jul  3 14:01:29 2026
From: hpa at zytor.com (H. Peter Anvin)
Date: Fri, 03 Jul 2026 14:01:29 -0700
Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_v16_01/18=5D_seccomp=3A_Convert?=
 =?US-ASCII?Q?_=5F=5Fsecure=5Fcomputing=28=29_to_return_boolean?=
In-Reply-To: <87echjlrs4.ffs@fw13>
References: <20260629130616.642022-1-ruanjinjie@huawei.com> <20260629130616.642022-2-ruanjinjie@huawei.com> <akdp6GAu77-ipsXA@kunlun.suse.cz> <87cxx4mmim.ffs@fw13> <akeIK5TRCjlKbzbp@J2N7QTR9R3> <akeOjqMy7HVgRRCr@kunlun.suse.cz> <fa1f5b39-2703-40a1-81d6-3feba87e19b0@arm.com> <87echjlrs4.ffs@fw13>
Message-ID: <F0993CE8-27EB-42D9-80F7-04A7A73C2395@zytor.com>

On July 3, 2026 1:52:43 PM PDT, Thomas Gleixner <tglx at kernel.org> wrote:
>On Fri, Jul 03 2026 at 13:59, Kevin Brodsky wrote:
>> On 03/07/2026 12:27, Michal Such?nek wrote:
>>>> If we're changing the return type, it might be worth renaming the
>>>> function something like:
>>>>
>>>> 	seccomp_permits_syscall()
>>> Then not only it is clear which way the boolean value should be
>>> interpreted, it also pervents the accidental inversion of existing
>>> calls. Overall great.
>>
>> Totally agreed, if we have the opportunity to rename a completely
>> undescriptive function name like "secure_computing" we should take it.
>
>Absolutely no objections from my side on that.
>

Hell yes. 


From linusw at kernel.org  Fri Jul  3 14:32:21 2026
From: linusw at kernel.org (Linus Walleij)
Date: Fri, 3 Jul 2026 23:32:21 +0200
Subject: [PATCH v16 01/18] seccomp: Convert __secure_computing() to return boolean
In-Reply-To: <akeIK5TRCjlKbzbp@J2N7QTR9R3>
References: <20260629130616.642022-1-ruanjinjie@huawei.com>
 <20260629130616.642022-2-ruanjinjie@huawei.com> <akdp6GAu77-ipsXA@kunlun.suse.cz>
 <87cxx4mmim.ffs@fw13> <akeIK5TRCjlKbzbp@J2N7QTR9R3>
Message-ID: <CAD++jLn0Pfhx0bY9XywVkDVU-nyAbvrnf9Wr8TSkuV4hgJL=8w@mail.gmail.com>

On Fri, Jul 3, 2026 at 12:00?PM Mark Rutland <mark.rutland at arm.com> wrote:

> Bikeshedding below; sorry.
>
> I think the bigger problem is just that secure_computing() is a terrible
> name that does not express the intended semantic -- it's not clear
> whether "secure computing" means "seccomp permit the syscall" or
> "seccomp is enabled and some special rules now apply" or something else
> entirely.
>
> If we're changing the return type, it might be worth renaming the
> function something like:
>
>         seccomp_permits_syscall()

Yeah that's way better, let's do this.
(I also had problems with this function!!)

Rusty Russel's API design manifesto tells us to do this:
https://gist.github.com/mjball/9cd028ac793ae8b351df1379f1e721f9

Yours,
Linus Walleij


