[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260720192334.GX27423@brightrain.aerifal.cx>
Date: Mon, 20 Jul 2026 15:23:34 -0400
From: Rich Felker <dalias@...c.org>
To: Darshit Shah <darnshah@...zon.de>
Cc: musl@...ts.openwall.com
Subject: Re: [RFC] clone() interaction with seccomp filters and signal
handlers
On Mon, Jul 20, 2026 at 06:06:45PM +0000, Darshit Shah wrote:
> [ Not subscribed to list, please keep me in Cc when responding. ]
>
> Hi,
>
> I'm having some issues with musl 1.2.6 and would like to solicit ideas / recommendations on how to either change our
> usage pattern / fixup musl to work with it.
>
> The context is this: I am building an application linked with musl that installs both, 1. a seccomp filter and 2.
> A signal handler for the filtered syscall. This normally works without an issue. However, starting with musl 1.2.5
> fa4a8abd06a ("fix public clone function to be safe and usable by applications"), the clone() wrapper now blocks all
> signals before actually invoking the underlying syscall. I understand the intent behind it. But this breaks our workflow
> where we have a seccomp filter, configured with SECCOMP_RET_TRAP, to block calls to clone() and a signal handler that
> catches the resulting SIGSYS and handles the blocking gracefully.
>
> On a filtered clone() the kernel raises a SIGSYS synchronously on the calling thread. Because the wrapper has masked all
> signals at that point, the signal is blocked when the kernel tries to deliver it. This is a forced/synchronous signal,
> so the kernel doesn't just queue it and move on: force_sig_info() unblocks SIGSYS and resets its handler to SIG_DFL
> to guarantee the thread can't ignore a synchronous fault. The net effect is that our handler is silently torn down and
> the SIGSYS is delievered directly to the thread, killing it.
>
> What paths forward do we have here? We would like to be able to continue installing a signal handler to handle seccomp
> filters. The direct proposal that comes to mind is that clone() should not mask SIGSYS. But that creates an edge case in
> how clone() is implemented in musl and is not a neat solution. Any ideas on how this can be resolved neatly?
clone isn't the only place this happens. There are several places
where all signals need to be blocked so that no intevening application
code can interrupt a context where it would be exposed to an
inconsistent state or where locks that need to work from async-signal
contexts could deadlock.
This is basically a fundamental problem with the SECCOMP_RET_TRAP
mechanism, and was the motivation for SECCOMP_RET_USER_NOTIF being
introduced as an alternative that's actually possible to use reliably.
Note that neither is an actual security boundary if the interception
is happening in the same process. I'm not sure if that matters to your
usage or not. But SECCOMP_RET_USER_NOTIF can be made into a security
boundary by isolating the handling to a different process. Or it can
be kept in-process with a separate thread handling the events.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
