A system call (syscall) is the formal interface through which a user-space process asks the kernel to perform a privileged operation on its behalf — opening a file, allocating memory, creating a process, establishing a network connection, sending a signal, or any other action that requires kernel mediation. User-space code runs at CPU privilege level 3 (ring 3) and cannot directly access hardware, manipulate kernel data structures, or perform I/O; the kernel runs at ring 0 with unrestricted access. A syscall is the crossing point: the process places its request in a defined register convention and issues a syscall instruction (on x86-64) that atomically switches the CPU to ring 0 and transfers control to the kernel’s syscall dispatch table. The kernel validates the request, performs the operation if permitted by standard Unix permissions and any active LSM hooks, and returns the result. From a security perspective, the syscall boundary is the complete list of what a process can ask the kernel to do — and therefore the complete list of operations that security controls like seccomp and BPF LSM can police.
Linux currently has roughly 350 syscalls on x86-64 (the exact count varies by architecture and kernel version), ranging from mundane operations (read, write, open, close, mmap) to powerful but narrow ones (ptrace, mount, kexec_load, perf_event_open, bpf) to obsolete or rarely used ones (uselib, sysfs, nfsservctl). Architecture matters: a 64-bit kernel also handles 32-bit compatibility calls through a separate dispatch table, which is why seccomp profiles must account for both x86_64 and x32 or i386 syscall numbers when running on a host that allows 32-bit binaries — a frequent source of container escape bugs when legacy compat syscalls are left unfiltered. Each syscall is identified by a number and a name; the kernel exposes its current syscall table via /proc/kallsyms and ausyscall --dump. The security relevance of the syscall boundary is that it is the only way for a process to interact with the kernel: a container that is denied network access via network namespace isolation but can call socket() and finds a namespace escape vulnerability is still constrained by whether seccomp blocks socket() outright — defence in depth at the syscall layer provides a fallback when higher-level isolation is bypassed.
Syscalls are the foundation on which the other entries in this section compose. seccomp filters the allowed set of syscalls a process may invoke. cgroups intercept at the scheduling and resource accounting layer triggered by kernel paths that syscalls enter. eBPF programs attach to kprobes and tracepoints at individual syscall entry and exit points, giving observability and policy enforcement with per-argument visibility. LSM hooks fire from within syscall implementation paths — security_file_open() fires from openat(), security_socket_connect() from connect() — allowing MAC decisions based on the full semantic context of the operation rather than just the syscall number. In confidential computing, the guest kernel’s syscall interface is what KubeVirt and Kata Containers isolate behind a VM boundary: a kernel exploit that would normally give a container an escape to the host is contained within the guest kernel, because the host’s kernel is only reachable through the hypervisor interface, not through the guest syscall table.