seccomp: allow TSYNC and USER_NOTIF together
authorTycho Andersen <tycho@tycho.ws>
Wed, 4 Mar 2020 18:05:17 +0000 (11:05 -0700)
committerKees Cook <keescook@chromium.org>
Wed, 4 Mar 2020 22:48:54 +0000 (14:48 -0800)
commit51891498f2da78ee64dfad88fa53c9e85fb50abf
tree6a75fa013734d64980e797831cf123c69cab0c3f
parent11a48a5a18c63fd7621bb050228cebf13566e4d8
seccomp: allow TSYNC and USER_NOTIF together

The restriction introduced in 7a0df7fbc145 ("seccomp: Make NEW_LISTENER and
TSYNC flags exclusive") is mostly artificial: there is enough information
in a seccomp user notification to tell which thread triggered a
notification. The reason it was introduced is because TSYNC makes the
syscall return a thread-id on failure, and NEW_LISTENER returns an fd, and
there's no way to distinguish between these two cases (well, I suppose the
caller could check all fds it has, then do the syscall, and if the return
value was an fd that already existed, then it must be a thread id, but
bleh).

Matthew would like to use these two flags together in the Chrome sandbox
which wants to use TSYNC for video drivers and NEW_LISTENER to proxy
syscalls.

So, let's fix this ugliness by adding another flag, TSYNC_ESRCH, which
tells the kernel to just return -ESRCH on a TSYNC error. This way,
NEW_LISTENER (and any subsequent seccomp() commands that want to return
positive values) don't conflict with each other.

Suggested-by: Matthew Denton <mpdenton@google.com>
Signed-off-by: Tycho Andersen <tycho@tycho.ws>
Link: https://lore.kernel.org/r/20200304180517.23867-1-tycho@tycho.ws
Signed-off-by: Kees Cook <keescook@chromium.org>
include/linux/seccomp.h
include/uapi/linux/seccomp.h
kernel/seccomp.c
tools/testing/selftests/seccomp/seccomp_bpf.c