[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <162208342966.3725800.17683913220837738980.b4-ty@chromium.org>
Date: Wed, 26 May 2021 19:43:59 -0700
From: Kees Cook <keescook@...omium.org>
To: Tycho Andersen <tycho@...ho.pizza>, containers@...ts.linux.dev,
Sargun Dhillon <sargun@...gun.me>,
Andy Lutomirski <luto@...nel.org>,
LKML <linux-kernel@...r.kernel.org>
Cc: Kees Cook <keescook@...omium.org>,
Rodrigo Campos <rodrigo@...volk.io>,
Mauricio Vásquez Bernal <mauricio@...volk.io>,
Christian Brauner <christian.brauner@...ntu.com>,
Giuseppe Scrivano <gscrivan@...hat.com>,
Mickaël Salaün <mic@...ux.microsoft.com>
Subject: Re: [PATCH v2 0/4] Atomic addfd send and reply
On Mon, 17 May 2021 12:39:04 -0700, Sargun Dhillon wrote:
> This is somewhat of a respin of "Handle seccomp notification preemption"
> but without the controversial parts.
>
>
> This patchset addresses a race condition we've dealt with recently with
> seccomp. Specifically programs interrupting syscalls while they're in
> progress. This was exacerbated by Golang's recent adoption of "async
> preemption", in which they try to interrupt any syscall that's been running
> for more than 10ms during GC. During certain syscalls, it's non-trivial to
> write them in a reetrant manner in userspace (socket).
>
> [...]
Thanks for your patience on this series! I think this is a clear solution
for the race. Applied to for-next/seccomp, thanks!
[1/4] Documentation: seccomp: Fix user notification documentation
https://git.kernel.org/kees/c/1e2ca403fa89
[2/4] seccomp: Refactor notification handler to prepare for new semantics
https://git.kernel.org/kees/c/6a1e0616acde
[3/4] seccomp: Support atomic "addfd + send reply"
https://git.kernel.org/kees/c/ba9ef89cf83e
[4/4] selftests/seccomp: Add test for atomic addfd+send
https://git.kernel.org/kees/c/75c98a0d5d3a
--
Kees Cook
Powered by blists - more mailing lists