eBPF

The operating system kernel has absolute control over the hardware, CPU schedules, memory maps, and network routing. Traditionally, modifying kernel behavior required writing a kernel module.

However, kernel modules are highly risky: a single memory error or null-pointer dereference will crash the entire operating system (triggering a kernel panic). Furthermore, kernel modules are tightly coupled to specific kernel versions, requiring constant maintenance and recompilation.

Traditional Kernel Module:
[Code] ---> [Loaded directly into Kernel Space] === (Crash in Code = Kernel Panic!)

eBPF Sandboxed Code:
[Code] ---> [Verifier Checks Safety] ---> [JIT compiler] ---> [Executed in Sandbox]

eBPF (Extended Berkeley Packet Filter) solves this problem by providing a secure, sandboxed virtual machine inside the kernel. It allows developers to run custom bytecode at helper hook points in the kernel without restarting the server or loading unstable modules.

The eBPF runtime ensures that programs cannot crash the system, read invalid memory, or execute infinite loops, providing a safe bridge between user space applications and kernel-level performance.

The eBPF VM runs as a software-defined execution engine directly within the operating system kernel:

• Registers: Features eleven 64-bit registers: R0 (return value register), R1 to R5 (argument registers), R6 to R9 (callee-saved registers), and R10 (a read-only frame pointer to access the stack).
• Stack Space: Provides a small 512-byte stack frame. For larger storage allocations, programs must utilize external structures called eBPF Maps.
• Helper Functions: eBPF bytecode is restricted from calling arbitrary kernel routines. Instead, it interacts with the OS via restricted helper functions (e.g., retrieving the current PID via bpf_get_current_pid_tgid()).

Before an eBPF program can be loaded, it must pass through the Verifier. The verifier performs static analysis to ensure execution safety before the code is compiled to native instructions:

1. Control Flow Analysis: The verifier constructs a Directed Acyclic Graph (DAG) of all possible execution branches. It rejects any programs containing infinite loops or unreachable states.
2. Memory Safety: Checks every read and write instruction to ensure the program only accesses memory on the stack or within validated maps. Pointers must be checked for NULL before dereferencing.
3. Complexity Bounds: Limits the number of instructions checked (historically 1 million instructions) to ensure verification terminates quickly.

Once verified, the JIT (Just-In-Time) Compiler translates the generic eBPF bytecode into native x86-64 or ARM assembly instructions, allowing the program to execute at native kernel speeds.

eBPF programs are event-driven. They compile, register with the kernel, and wait for specific events to trigger execution at designated attachment points:

• Kprobes & Kretprobes: Dynamic probes attached to the entry (kprobe) or return (kretprobe) of any kernel function.
• Uprobes & Uretprobes: User-space equivalent of kprobes. They hook functions within user-space applications (e.g. tracking when a Go HTTP server calls a database driver).
• Tracepoints: Static trace structures compiled directly into the kernel source by kernel developers. They are more stable than kprobes, which can change between kernel versions.
• XDP (eXpress Data Path): A high-performance hook located directly in the network driver layer, immediately after packet reception. XDP allows eBPF programs to inspect, modify, or drop packets before they are parsed by the kernel's TCP/IP stack.

Because eBPF programs run in sandboxed kernel memory, they cannot write directly to user-space memory. To share state, they use eBPF Maps:

Maps are key-value structures initialized in kernel space. They can be read or written by both eBPF kernel programs and user-space controllers. Common map formats include:

• Hash Tables: Dynamic key-value pairs, ideal for matching processes to state tags.
• Ring Buffers: High-throughput queues designed to stream structured event sequences from the kernel to user space.
• Arrays: Fixed-size tables, useful for accumulating counters and metrics.

eBPF has revolutionized backend systems engineering by changing how observability and networking are implemented:

Low-Overhead Observability

Traditional monitoring agents poll log files or intercept system calls by wrapping user commands. This introduces significant CPU overhead. eBPF hooks directly into kernel tracepoints, aggregating system statistics (such as execution times or disk latency distributions) inside local kernel maps. The user-space metrics collector only reads from these maps periodically, minimizing context-switching overhead.

High-Performance Networking (XDP)

In traditional networking, every packet travels up the network driver, through the IP routing tables, through firewalls (like iptables), and up to the TCP socket buffer.

Using eBPF with XDP, you can drop DDoS packets or route incoming queries at the network card driver level. This bypasses the TCP/IP stack entirely, enabling servers to process millions of packets per second with minimal CPU load.

• eBPF Document Portal — Foundational resources, code directories, and community projects using eBPF
• Learning eBPF — Liz Rice's textbook explaining raw eBPF assembly, BCC, and Go-BPF loaders
• Linux Kernel BPF Documentation — Official specifications of the eBPF VM, register rules, and verifier safety structures