summaryrefslogtreecommitdiffstats
path: root/LICENSES
diff options
context:
space:
mode:
authorTycho Andersen <tycho@tycho.ws>2020-03-04 19:05:17 +0100
committerKees Cook <keescook@chromium.org>2020-03-04 23:48:54 +0100
commit51891498f2da78ee64dfad88fa53c9e85fb50abf (patch)
tree6a75fa013734d64980e797831cf123c69cab0c3f /LICENSES
parentLinux 5.6-rc2 (diff)
downloadlinux-51891498f2da78ee64dfad88fa53c9e85fb50abf.tar.xz
linux-51891498f2da78ee64dfad88fa53c9e85fb50abf.zip
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>
Diffstat (limited to 'LICENSES')
0 files changed, 0 insertions, 0 deletions