From: Sargun Dhillon <sargun@sargun.me> To: Kees Cook <keescook@chromium.org>, LKML <linux-kernel@vger.kernel.org>, Linux Containers <containers@lists.linux-foundation.org>, Rodrigo Campos <rodrigo@kinvolk.io>, Christian Brauner <christian.brauner@ubuntu.com> Cc: Giuseppe Scrivano <gscrivan@redhat.com>, Will Drewry <wad@chromium.org>, Andy Lutomirski <luto@amacapital.net>, Alban Crequy <alban@kinvolk.io> Subject: [PATCH RESEND 0/5] Handle seccomp notification preemption Date: Mon, 26 Apr 2021 11:06:05 -0700 [thread overview] Message-ID: <20210426180610.2363-1-sargun@sargun.me> (raw) 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 (mount). This has a couple semantic changes, and relaxes a check on seccomp_data, and changes the semantics with ordering of how addfd and notification replies in the supervisor are handled. I'm resending after rebasing and testing on v5.12. It turns out this change also fixed a bug Rodrigo found that could occur with addfd around certain race conditions[2]. It also follows up on the original proposal from Tycho[3] to allow for adding an FD and returning that value atomically. Changes since v1[1]: * Fix some documentation * Add Rata's patches to allow for direct return from addfd [1]: https://lore.kernel.org/lkml/20210220090502.7202-1-sargun@sargun.me/ [2]: https://lore.kernel.org/lkml/20210413160151.3301-1-rodrigo@kinvolk.io/ [3]: https://lore.kernel.org/lkml/202012011322.26DCBC64F2@keescook/ Rodrigo Campos (2): seccomp: Support atomic "addfd + send reply" selftests/seccomp: Add test for atomic addfd+send Sargun Dhillon (3): seccomp: Refactor notification handler to prepare for new semantics seccomp: Add wait_killable semantic to seccomp user notifier selftests/seccomp: Add test for wait killable notifier .../userspace-api/seccomp_filter.rst | 15 +- include/uapi/linux/seccomp.h | 4 + kernel/seccomp.c | 129 ++++++++++++++---- tools/testing/selftests/seccomp/seccomp_bpf.c | 102 ++++++++++++++ 4 files changed, 220 insertions(+), 30 deletions(-) base-commit: 9f4ad9e425a1d3b6a34617b8ea226d56a119a717 -- 2.25.1 _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/containers
WARNING: multiple messages have this Message-ID (diff)
From: Sargun Dhillon <sargun@sargun.me> To: Kees Cook <keescook@chromium.org>, LKML <linux-kernel@vger.kernel.org>, Linux Containers <containers@lists.linux-foundation.org>, Rodrigo Campos <rodrigo@kinvolk.io>, Christian Brauner <christian.brauner@ubuntu.com> Cc: "Sargun Dhillon" <sargun@sargun.me>, "Mauricio Vásquez Bernal" <mauricio@kinvolk.io>, "Tycho Andersen" <tycho@tycho.pizza>, "Giuseppe Scrivano" <gscrivan@redhat.com>, "Andy Lutomirski" <luto@amacapital.net>, "Will Drewry" <wad@chromium.org>, "Alban Crequy" <alban@kinvolk.io> Subject: [PATCH RESEND 0/5] Handle seccomp notification preemption Date: Mon, 26 Apr 2021 11:06:05 -0700 [thread overview] Message-ID: <20210426180610.2363-1-sargun@sargun.me> (raw) 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 (mount). This has a couple semantic changes, and relaxes a check on seccomp_data, and changes the semantics with ordering of how addfd and notification replies in the supervisor are handled. I'm resending after rebasing and testing on v5.12. It turns out this change also fixed a bug Rodrigo found that could occur with addfd around certain race conditions[2]. It also follows up on the original proposal from Tycho[3] to allow for adding an FD and returning that value atomically. Changes since v1[1]: * Fix some documentation * Add Rata's patches to allow for direct return from addfd [1]: https://lore.kernel.org/lkml/20210220090502.7202-1-sargun@sargun.me/ [2]: https://lore.kernel.org/lkml/20210413160151.3301-1-rodrigo@kinvolk.io/ [3]: https://lore.kernel.org/lkml/202012011322.26DCBC64F2@keescook/ Rodrigo Campos (2): seccomp: Support atomic "addfd + send reply" selftests/seccomp: Add test for atomic addfd+send Sargun Dhillon (3): seccomp: Refactor notification handler to prepare for new semantics seccomp: Add wait_killable semantic to seccomp user notifier selftests/seccomp: Add test for wait killable notifier .../userspace-api/seccomp_filter.rst | 15 +- include/uapi/linux/seccomp.h | 4 + kernel/seccomp.c | 129 ++++++++++++++---- tools/testing/selftests/seccomp/seccomp_bpf.c | 102 ++++++++++++++ 4 files changed, 220 insertions(+), 30 deletions(-) base-commit: 9f4ad9e425a1d3b6a34617b8ea226d56a119a717 -- 2.25.1
next reply other threads:[~2021-04-26 18:06 UTC|newest] Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-26 18:06 Sargun Dhillon [this message] 2021-04-26 18:06 ` [PATCH RESEND 0/5] Handle seccomp notification preemption Sargun Dhillon 2021-04-26 18:06 ` [PATCH RESEND 1/5] seccomp: Refactor notification handler to prepare for new semantics Sargun Dhillon 2021-04-26 18:06 ` Sargun Dhillon 2021-04-26 18:06 ` [PATCH RESEND 2/5] seccomp: Add wait_killable semantic to seccomp user notifier Sargun Dhillon 2021-04-26 18:06 ` Sargun Dhillon 2021-04-26 19:02 ` Tycho Andersen 2021-04-26 19:02 ` Tycho Andersen 2021-04-26 22:15 ` Sargun Dhillon 2021-04-26 22:15 ` Sargun Dhillon 2021-04-27 13:48 ` Tycho Andersen 2021-04-27 13:48 ` Tycho Andersen 2021-04-27 16:23 ` Andy Lutomirski 2021-04-27 16:23 ` Andy Lutomirski 2021-04-27 17:07 ` Tycho Andersen 2021-04-27 17:07 ` Tycho Andersen 2021-04-27 22:10 ` Sargun Dhillon 2021-04-27 22:10 ` Sargun Dhillon 2021-04-27 23:19 ` Andy Lutomirski 2021-04-27 23:19 ` Andy Lutomirski 2021-04-28 0:22 ` Tycho Andersen 2021-04-28 0:22 ` Tycho Andersen 2021-04-28 11:10 ` Rodrigo Campos 2021-04-28 11:10 ` Rodrigo Campos 2021-04-28 13:20 ` Rodrigo Campos 2021-04-28 13:20 ` Rodrigo Campos 2021-04-28 14:08 ` Tycho Andersen 2021-04-28 14:08 ` Tycho Andersen 2021-04-28 17:13 ` Sargun Dhillon 2021-04-28 17:13 ` Sargun Dhillon 2021-04-28 3:20 ` Sargun Dhillon 2021-04-28 3:20 ` Sargun Dhillon 2021-04-27 16:34 ` Sargun Dhillon 2021-04-27 16:34 ` Sargun Dhillon 2021-04-26 18:06 ` [PATCH RESEND 3/5] selftests/seccomp: Add test for wait killable notifier Sargun Dhillon 2021-04-26 18:06 ` Sargun Dhillon 2021-04-26 18:51 ` Tycho Andersen 2021-04-26 18:51 ` Tycho Andersen 2021-04-26 18:06 ` [PATCH RESEND 4/5] seccomp: Support atomic "addfd + send reply" Sargun Dhillon 2021-04-26 18:06 ` Sargun Dhillon 2021-04-26 18:06 ` [PATCH RESEND 5/5] selftests/seccomp: Add test for atomic addfd+send Sargun Dhillon 2021-04-26 18:06 ` Sargun Dhillon
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=20210426180610.2363-1-sargun@sargun.me \ --to=sargun@sargun.me \ --cc=alban@kinvolk.io \ --cc=christian.brauner@ubuntu.com \ --cc=containers@lists.linux-foundation.org \ --cc=gscrivan@redhat.com \ --cc=keescook@chromium.org \ --cc=linux-kernel@vger.kernel.org \ --cc=luto@amacapital.net \ --cc=rodrigo@kinvolk.io \ --cc=wad@chromium.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.