There is a program that runs inside the Linux kernel, the core of the operating system, without needing to reboot the server or touch the kernel’s own source code. It is called eBPF (extended Berkeley Packet Filter) and, although it was born as a tool for filtering network packets, it has become the technology behind the observability, security and performance of the internet’s largest services.
The problem it solves
The kernel is the software that manages a system’s memory, processes, disks and network. For decades, changing its behaviour required one of two things: recompiling the kernel and rebooting the machine, or loading a kernel module, a piece of code that runs with full privileges and, if it fails, can bring down the whole system. Neither option is comfortable in production, where a reboot costs money and a faulty module costs an outage.
eBPF offers a third path: running small, verified programs inside the kernel, in real time, without rebooting and without the risk of a crash. It is like being able to put a probe into a car engine while it is running without turning it off.
From packet filter to virtual machine in the kernel
The origin lies in classic BPF (cBPF), a packet-filtering language that tcpdump has used since the 1990s. In 2014, engineer Alexei Starovoitov redesigned it completely and turned it into eBPF: a much richer instruction set, with registers, jumps and calls to kernel functions, capable of doing far more than filtering traffic.
Today, eBPF works like a small virtual machine inside the kernel. An eBPF program is usually written in C, compiled to bytecode (the intermediate code the virtual machine executes) and loaded into the kernel, where a component called the verifier inspects it before letting it run.
The verifier: the guardian of safety
The key to eBPF being safe is the verifier, a static analyser that walks the bytecode and checks, instruction by instruction, that the program cannot do anything dangerous. It verifies that it does not access memory outside its bounds, that there are no infinite loops (loops must be bounded), that it cannot read arbitrary kernel memory, and that calls to functions are legitimate.
If the verifier finds any violation, it rejects the program and it never runs. That guarantee is what makes it possible to load code into the kernel without the fear that accompanies a traditional module.
JIT and performance
Once verified, the bytecode is translated into native machine code by a JIT (Just-In-Time) compiler, the same kind of compilation Java or JavaScript use to speed up execution. The result is that an eBPF program runs almost as fast as native kernel code, with minimal overhead. That is why it is used in extremely high-performance network paths, where every microsecond counts.
The hooks: where it attaches
An eBPF program does not run on its own: it attaches to specific points in the kernel called hooks. The most important are:
- kprobes and tracepoints: instrumentation points that let you observe kernel function calls and system events.
- XDP (eXpress Data Path): an entry point of the network stack that processes packets as soon as they arrive at the network card, before the kernel handles them, allowing traffic to be dropped or redirected at maximum speed.
- tc (traffic control): another point in the network stack where traffic policies can be applied.
- Network and socket tracepoints: to observe connections, DNS and application traffic.
The maps: shared memory
To communicate with the rest of the system, eBPF programs use data structures called maps: key-value tables that live in the kernel and that both the eBPF program and user-space processes can read and write. A map can hold counters, statistics, connection tables or configuration. It is the bridge that lets a user tool display on a dashboard what the eBPF program is observing inside the kernel.
What it is used for today
eBPF is at the heart of several technologies you probably already use without knowing it:
- Observability: tools such as Cilium, Pixie or Falco generate metrics, traces and logs of everything happening in the system without instrumenting each application.
- Networking and service meshes: Cilium, the CNI (Container Network Interface) that manages Kubernetes networking, uses eBPF to route traffic between containers with fewer hops and better performance than classic iptables-based solutions.
- Security: Falco and Tetragon detect anomalous behaviour, such as a process trying to open a suspicious file or an unexpected connection, by observing system calls in real time.
- Performance: companies such as Meta and Netflix use eBPF to debug latency problems and optimise their infrastructure without touching the kernel.
The ecosystem
A complete ecosystem has grown around eBPF. libbpf is the reference library for loading programs, bcc (BPF Compiler Collection) offers ready-to-use tools, and the eBPF Foundation, created in 2021, coordinates the project’s development under the Linux Foundation umbrella. Major companies such as Google, Meta, Netflix and Microsoft contribute actively.
Why it matters
eBPF has changed the way systems are operated: it allows you to observe and modify kernel behaviour in production, safely and without reboots. It is the reason it is now possible to have such fine-grained visibility into what is happening in a Kubernetes cluster or to detect an attack in milliseconds. And it all started with a packet filter that only wanted to decide which traffic to let through.
