linux-kernel - Re: [PATCH v3 6/7] seccomp: allow nested listeners

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANaxB-z8+UhZ+smuocN8h+YZY9tdKobhAu3H6fmzq+WzFmMrjg@mail.gmail.com>
Date: Tue, 20 Jan 2026 23:51:32 -0800
From: Andrei Vagin <avagin@...il.com>
To: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@...onical.com>
Cc: kees@...nel.org, linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, 
	bpf@...r.kernel.org, Andy Lutomirski <luto@...capital.net>, Will Drewry <wad@...omium.org>, 
	Jonathan Corbet <corbet@....net>, Shuah Khan <shuah@...nel.org>, Aleksa Sarai <cyphar@...har.com>, 
	Tycho Andersen <tycho@...ho.pizza>, Christian Brauner <brauner@...nel.org>, 
	Stéphane Graber <stgraber@...raber.org>, 
	Alexander Mikhalitsyn <alexander@...alicyn.com>
Subject: Re: [PATCH v3 6/7] seccomp: allow nested listeners

On Thu, Dec 11, 2025 at 4:46 AM Alexander Mikhalitsyn
<aleksandr.mikhalitsyn@...onical.com> wrote:
>
> Now everything is ready to get rid of "only one listener per tree"
> limitation.
>
> Let's introduce a new uAPI flag
> SECCOMP_FILTER_FLAG_ALLOW_NESTED_LISTENERS, so userspace may explicitly
> allow nested listeners when installing a listener.

I am not sure we really need SECCOMP_FILTER_FLAG_ALLOW_NESTED_LISTENERS.
If nested listeners are completely functional, why would we want to
implicitly allow or disallow someone from using them?

Actually, even the current behavior of SECCOMP_RET_USER_NOTIF looks a
bit illogical. I think the following behavior would be more expected:
instead of running all filters and picking the most restrictive result,
the kernel should execute them one by one (most recent fist). If a filter
returns USER_NOTIF, the kernel pauses immediately to let the listener
handle the call. If that listener then issues "CONTINUE", the kernel
resumes by running the remaining older filters in the chain.

Thanks,
Andrei