This class of problem for seccomp has been known for ages. This makes it quasi-unusable IMO (or reserved for full-contained binaries, maybe in some JIT scenario

This class of problem for seccomp has been known for ages. This makes it quasi-unusable IMO (or reserved for full-contained binaries, maybe in some JIT scenario but probably not a lot else), and even quasi in self-contradiction with the kernel non-regression rules (because by design seccomp can not achieve that in the general case -- at least when you consider the bigger picture that is a classic userspace design and ecosystem, like in a mainstream standard distro). To detail more: under this "standard" model the applications do not often do syscalls themselves, but use intermediate libraries (ex: glibc) that provide (quasi)-Posix and reserve some of the syscalls or even provide syscall like functions that actually use others -- or just start to use new syscalls in new versions to provide higher levels of abstraction. But they do not provide another abstraction to obtain a seccomp-like services suitable for this model. So seccomp is basically unusable in this context, which is one of the most important. Now the kernel itself made the mistake, proving that the whole idea was not practical; it breaks too easily, and it breaks even when used in most restricted ways or when the whole (non-kernel provided) userspace has been designed for it (which was not a practical condition at all, to begin with). IMO seccomp should be phased out entirely and eventually replaced by something else. Trying to "fix" it will yield nowhere: it is broken by design, since forever.