The Bouncer That Reads Your Code
One of the most common objections to running custom code inside the kernel is safety. A bug in kernel code can crash the entire system. This is why eBPF programs go through a verifier before they are allowed to run.
The eBPF verifier is a static analysis engine built into the Linux kernel. When you load an eBPF program via the bpf() system call, the verifier performs an exhaustive analysis of every possible execution path through your code. It rejects programs that:
- Access memory out of bounds — Every pointer dereference must be preceded by a bounds check against
data_end. The verifier tracks this statically. - Contain unbounded loops — Infinite loops would freeze the CPU. The verifier requires that all loops have a provable upper bound (or uses loop unrolling).
- Call arbitrary kernel functions — eBPF programs can only call a whitelist of approved BPF helper functions (e.g.,
bpf_map_lookup_elem,bpf_redirect,bpf_ktime_get_ns). - Have unreachable instructions — Dead code is rejected.
- Exceed complexity limits — Programs are limited to 1 million verified instructions (as of Linux 5.2+).
What this means in practice: If you write an XDP program that forgets a bounds check, the kernel will refuse to load it — and the rejection is precise, naming the exact instruction that failed and why (e.g., an access into the packet context at an offset the verifier can't prove is in bounds). This is fundamentally different from a kernel module, where a bad pointer dereference causes an immediate kernel panic.
The verifier is what makes XDP deployable in production environments where DPDK's "trust the developer completely" model is unacceptable. It's the reason cloud providers like AWS and Google can allow customers to run eBPF programs on shared infrastructure.