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.
Showing the changes to include/linux (1 of 4 files). Show all
Unified · Split
| @@ -7,7 +7,8 @@ · 6 unmodified lines | |||
| 7 | #define SECCOMP_FILTER_FLAG_MASK (SECCOMP_FILTER_FLAG_TSYNC | \ | 7 | #define SECCOMP_FILTER_FLAG_MASK (SECCOMP_FILTER_FLAG_TSYNC | \ |
| 8 | SECCOMP_FILTER_FLAG_LOG | \ | 8 | SECCOMP_FILTER_FLAG_LOG | \ |
| 9 | SECCOMP_FILTER_FLAG_SPEC_ALLOW | \ | 9 | SECCOMP_FILTER_FLAG_SPEC_ALLOW | \ |
| 10 | SECCOMP_FILTER_FLAG_NEW_LISTENER) | 10 | SECCOMP_FILTER_FLAG_NEW_LISTENER | \ |
| 11 | SECCOMP_FILTER_FLAG_TSYNC_ESRCH) | ||
| 11 | 12 | ||
| 12 | #ifdef CONFIG_SECCOMP | 13 | #ifdef CONFIG_SECCOMP |
| 13 | 14 | ||