History

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.

Tycho Andersen committed 6 years ago

Commit 51891491 parent 11a48a54 files · +86 −6Browse files

Showing the changes to include/uapi/linux (1 of 4 files). Show all

Unified · Split

include/uapi/linux/seccomp.h+1−0
@@ -22,6 +22,7 @@ · 21 unmodified lines
2222 #define SECCOMP_FILTER_FLAG_LOG (1UL << 1)
2323 #define SECCOMP_FILTER_FLAG_SPEC_ALLOW (1UL << 2)
2424 #define SECCOMP_FILTER_FLAG_NEW_LISTENER (1UL << 3)
25+#define SECCOMP_FILTER_FLAG_TSYNC_ESRCH (1UL << 4)
2526
2627 /*
2728 * All BPF programs must return a 32-bit value.