eBPF: Building High-Performance Kernel Plugins for Linux Security and Observability

eBPF has become one of the most unlikely success stories in systems programming. A technology that lets you write small programs that run inside the Linux kernel—traditionally the domain of dangerous, crash-prone kernel modules—now has a foundation, an academic workshop, a documentary, and the backing of companies like Google, Meta, Cloudflare, and Netflix. The reason for this strange popularity is simple: eBPF lets you do things that matter, in places where they matter most, without the risk that comes with traditional kernel development.

The appeal lies in what eBPF can reach. A program running in kernel space can hook into critical system events—network packets arriving at the NIC driver, system calls being made, process scheduling decisions—and intercept or manipulate them before they propagate further. You can drop a packet before it even enters the kernel's network stack. You can trace every directory removal across the entire system. You can participate in process scheduling. None of this is possible from user space. But here is the catch: eBPF programs are not free to do whatever they want. The kernel enforces strict restrictions. They cannot contain infinite loops. They cannot perform illegal operations. This sounds limiting, but it is actually the source of eBPF's power. A buggy eBPF program cannot crash the kernel—unless there is a bug in the kernel itself. This makes extending the kernel a fearless activity, something that cannot be said of traditional kernel modules, which have the full power of the kernel and can destroy it just as easily.

The practical impact is already visible in production systems. Cilium, a networking layer for Kubernetes, uses eBPF to replace the traditional kube-proxy and iptables workflow, eliminating significant overhead by doing load balancing and routing at the lowest level possible. bpfilter is a firewall solution that translates network filtering rules into eBPF programs automatically, serving as a drop-in replacement for iptables. You can use its command-line tool, bfcli, to load filtering chains and attach them to network interfaces. For example, you can block all ICMP packets—effectively disabling ping—by loading a chain that drops traffic matching the rule, then attaching it to a specific network interface by its index. XDP, the eXpress Data Path, is an eBPF-based feature that filters packets at the NIC driver level, making it the tool of choice for DDoS mitigation because filtering happens before packets enter the kernel network stack.

For observability, bpftrace offers a simpler entry point. It accepts programs written in an AWK-like language and converts them to eBPF internally, inspired by the D language used in DTrace. A single command can log every time a process removes a directory: you write a one-liner that hooks into the rmdir system call tracepoint, and it prints the process name whenever that call is made. You can test it by creating and deleting a directory in another terminal and watching the logs appear in real time.

Understanding how eBPF works requires understanding the pipeline. An eBPF program is an ELF binary containing eBPF bytecode instead of machine code. You write it in C or Assembly, compile it with Clang, and send it to the kernel via a bpf() system call using a user-space loader program. Once the kernel receives it, the eBPF verifier inspects the program to ensure it is free of infinite loops and illegal operations. If it passes, a JIT compiler translates the bytecode to native machine code for the current architecture—x86_64, ARM, and others. Then the program is ready to run. Execution is event-driven: the program runs when the hook it is attached to fires, whether that is a network packet arriving, a system call being made, or a timer expiring. eBPF programs communicate with their user-space loaders through maps—data structures like arrays, hash tables, and queues that bridge kernel and user space.

Writing eBPF programs from scratch requires building both the kernel-space program and the user-space loader, which is tedious without a framework. libbpf-bootstrap is a collection of sample programs with all the boilerplate and build configuration already in place, licensed under BSD 3-Clause. The minimal example demonstrates the pattern: the eBPF program hooks into the write() system call and prints a message whenever it fires, while the loader program prints a dot every second, triggering the eBPF program repeatedly. You can clone the repository, run make minimal, and then sudo ./minimal to start the loader. In another terminal, reading from /sys/kernel/debug/tracing/trace_pipe shows the output from the eBPF program. Modifying the example to hook into rmdir() instead and removing the process filter allows you to trace directory deletions across the entire system—something that would require significantly more code in user space or a full kernel module.

The ecosystem continues to grow. Tools like bpftop provide a real-time view of running eBPF programs similar to top or htop. bpftool lets you inspect and manipulate eBPF programs and maps. llvm-objdump can disassemble eBPF bytecode so you can see the actual instructions. The verifier remains an active area of research and improvement—it is the gatekeeper that makes eBPF safe, but it can also be overly strict, making development frustrating. As eBPF adoption spreads to Windows and hardware SmartNICs, and as more companies build production systems on top of it, the technology that started as an extension of Berkeley Packet Filter has become something far larger: a new way to extend operating systems safely, dynamically, and at scale.