On Tue, Jun 29, 2021 at 05:54:24PM -0500, Eric W. Biederman wrote: > > I am the process of cleaning up the process exit path in the kernel, and > as part of that I am looking at the callers of do_exit. A very > interesting one is __seccure_computing_strict. > > Looking at the code is very clear that if a system call is attempted > that is not in the table the thread attempting to execute that system > call is terminated. > > Reading the man page for seccomp it says that the process is delivered > SIGKILL. > > The practical difference is what happens for multi-threaded > applications. > > What are the desired semantics for a multi-threaded application if one > thread attempts to use a unsupported system call? Should the thread be > terminated or the entire application? > > Do we need to fix the kernel, or do we need to fix the manpages? I don't know of anyone actually using SECCOMP_MODE_STRICT, but the original implementation was (perhaps accidentally) thread-killing. It turns out this is not a particularly desirable situation, and when SECCOMP_MODE_FILTER was created, it continued with that semantic, but later grew a process-killing flags, as that's what most programs actually wanted. It's likely the manpage needs fixing (we had to make similar updates for SECCOMP_MODE_FILTER), since some of the early examples of using SECCOMP_MODE_STRICT were basically "fork, calculate, write result to fd, exit". FWIW the seccomp selftests don't even check for the thread-vs-process SIGKILL of SECCOMP_MODE_STRICT. :) -- Kees Cook
