The Hard Kernel Problem
Before eBPF existed, adding security monitoring to the Linux kernel meant choosing between two genuinely terrible options:
- Change Kernel Source: Write a patch, submit it upstream, and wait — sometimes years — for it to be accepted and shipped in a stable release. Even then, you'd need to wait for distributions to adopt it.
- Load a Kernel Module: Write a C module and load it at runtime. If your code has a single null-pointer dereference or off-by-one error, the entire server crashes with a kernel panic. No warning. No recovery. Just a dead machine.
Neither option is acceptable for production security tooling that needs to evolve quickly.
The Solution: eBPF
eBPF (Extended Berkeley Packet Filter) is a technology built into the Linux kernel that lets you run sandboxed programs inside the operating system kernel — safely, without modifying kernel source code and without the risk of crashing the system.
The name is historical baggage: the original BPF was a simple packet filter from 1992. "Extended" BPF, introduced around Linux 3.18 (2014) and matured significantly by Linux 4.x–5.x, is a completely different beast — a general-purpose in-kernel execution environment.
Think of it like JavaScript for the kernel. A web browser lets you run JavaScript to inspect and modify a webpage's behavior without recompiling the browser itself. eBPF lets you run programs that inspect and modify kernel behavior without recompiling the kernel. The browser's JavaScript engine enforces safety (no direct memory access, sandboxed execution); the kernel's eBPF verifier does the same thing — it statically analyzes every eBPF program before loading it to prove it cannot crash the kernel, loop infinitely, or access arbitrary memory.
How eBPF Programs Actually Run
When you load an eBPF program, the kernel's verifier performs a static analysis pass — checking all possible execution paths, bounding loops, validating memory accesses. If the program passes verification, it is JIT-compiled (Just-In-Time) into native machine code and attached to a hook point. Hook points exist throughout the kernel: system call entry/exit, network packet ingress/egress, function entry/return for any kernel or user-space function, tracepoints, and more.
When the hooked event occurs, the kernel executes your eBPF program inline — no context switch, no user-space round-trip. The program can read kernel data structures, record events into eBPF maps (shared memory structures accessible from user space), and in some hook types, make enforcement decisions (allow or deny).
Key Point: The eBPF verifier is not optional and cannot be bypassed. This is what makes eBPF fundamentally different from kernel modules — safety is enforced by construction, not by trust. However, the verifier itself has had CVEs (e.g., incorrect bounds checking leading to privilege escalation). Running eBPF programs requires CAP_BPF or CAP_SYS_ADMIN privileges, so the attack surface is the verifier code itself, not the eBPF programs you load. This is a known, bounded risk — far smaller than the risk of arbitrary kernel module execution.