Handling New Syscalls in Seccomp Filters

### Overview In this talk, libseccomp maintainer Tom Hromatka (joined by co-maintainer Paul Moore) presents a proposed patch set designed to handle newly introduced Linux system calls in seccomp filters. When kernel updates introduce unfamiliar syscalls, static allow lists or deny lists can lead to unexpected security holes or broken applications. The proposed feature introduces kernel version awareness into libseccomp, allowing developers to define a target maximum kernel version and specify dedicated actions for any syscall introduced after that version.

### Key Topics - **Allow Lists vs. Deny Lists**: Seccomp filters typically use either deny lists (blocking specific calls and allowing the rest, common in containers like Docker) or allow lists (blocking by default). With deny lists, kernel updates may unintentionally permit brand-new, potentially vulnerable syscalls; with allow lists, new syscalls needed by updated libraries (such as glibc) are blocked, causing container and application failures. - **Upgrade Hesitancy**: Administrators and container operators frequently delay kernel and user-space updates out of fear that new syscall additions will break production workloads. - **Proposed Filter Attributes**: The patch set introduces two new opt-in libseccomp filter attribute enumerations. These enable users to define the maximum kernel version their filter was validated against (with logic going back as far as Linux 3.0) and choose an explicit fallback action (such as returning `ENOSYS`) for any syscall introduced in subsequent kernel releases. - **Filter Size and Generation Challenges**: Because Linux syscall numbers have historically not been assigned strictly sequentially across architectures and distributions often backport calls irregularly, libseccomp currently generates checks on a per-syscall basis rather than simple numeric ranges, impacting the resulting classic BPF filter size.

### Technical Details - **BPF Generation & Data Structures**: libseccomp maintains a two-dimensional in-memory table mapping architectures, syscalls, and the Linux kernel version in which each syscall was introduced. When compiling into classic BPF (or pseudo filter code / PFC for human inspection), it evaluates whether a syscall matches explicitly handled rules, falls back to default actions for known calls, or triggers the new-syscall action for calls newer than the configured kernel version. - **Sequential vs. Enumerated Matching**: While tools like runc have implemented range checks assuming syscall numbers greater than a certain threshold are new, libseccomp takes a cautious approach by enumerating syscalls individually to account for irregular numbering across 20+ architectures. To mitigate performance overhead from hundreds of instructions, libseccomp employs optimizations such as binary search trees. - **Action Choices**: Returning `ENOSYS` is recommended for unsupported new syscalls, as user-space runtimes and libraries often cleanly fall back to older syscall interfaces (e.g., falling back to earlier `openat` variants). However, some enterprise environments have hard requirements such as killing the process immediately.

### Takeaways - The proposed kernel-version-aware handling is an entirely opt-in mechanism configured via libseccomp filter attributes. - Setting the default action for unknown/new syscalls to `ENOSYS` solves compatibility issues for the majority of users, though documentation and education remain crucial. - Maintainers are gathering community feedback on the API design, table accuracy, and potential hybrid approaches (such as combining strict per-syscall lookups with range checks) before merging.