The inherent fragility of seccomp()
The inherent fragility of seccomp()
Posted Nov 10, 2017 22:41 UTC (Fri) by arnd (subscriber, #8866)In reply to: The inherent fragility of seccomp() by luto
Parent article: The inherent fragility of seccomp()
glibc has the concept of a minimum kernel version, currently linux-3.2 IIRC. If a system call was available on all architectures in that version, the glibc policy is to assume it works. Removing backwards compatibility fallbacks is generally considered a good thing here, but that is what caused the issue.
Part of the problem is that we have reduced the set of available syscalls on modern architectures, anything that uses include/uapi/asm-generic/unistd.h for instance intentionally offer only openat() but not open(). When glibc can reasonably assume that openat() is available on all architectures, the logical next step is to always call that to reduce the differences between architectures.