eBPF
Also known as: extended Berkeley Packet Filter, extended BPF
eBPF is a technology that lets developers run small, verified programs inside the Linux kernel without changing kernel code or loading risky modules.
It powers modern networking, security monitoring, and performance tools such as Cilium and Falco. While it sounds like a niche systems topic, eBPF has quietly become one of the most important building blocks of cloud infrastructure, because it gives deep visibility at very low cost.
eBPF, explained at three levels
At home
Think of the kernel, the core of an operating system, as a city's power station. Normally only the station's own engineers can change anything inside. eBPF is like letting you install small, inspected sensors inside the station: before any sensor goes in, an inspector checks it can't cause a blackout. Once approved, it watches and reacts to events, such as network traffic, right where they happen.
At work
eBPF is a Linux technology that lets companies run small programs inside the operating system's kernel without changing kernel code or rebooting. Those programs can watch network traffic, file access, and system activity, or make quick decisions such as dropping malicious packets. Businesses care because many modern security, networking, and monitoring products use eBPF to see everything happening on a server with very little slowdown.
At home
An eBPF program is attached to a hook, a specific point in the kernel such as a network packet arriving, a file being opened, or a function being called. When that event happens, the program runs. Before it's loaded, a verifier checks that it can't crash the system, read memory it shouldn't, or run forever. Programs store results in shared tables called maps, which ordinary apps read to display what was found.
At work
At work, eBPF usually appears inside products rather than as something teams write directly. Cilium uses it to route Kubernetes network traffic and enforce policies without the older iptables rules. Falco and Tetragon use it to detect suspicious behaviour, such as a container launching a shell. Profilers and observability agents, such as Pixie or Grafana Beyla, use it to record performance data without code changes. Because programs load and unload live, visibility can be added without restarts.
At home
An eBPF program is compiled to bytecode for a small virtual machine inside the kernel. The verifier then walks through every possible path, checking memory access and making sure loops end. If it passes, a just-in-time compiler turns it into native machine code. While the verifier's rules make some programs awkward to write, in my view that trade is the clever part: it gives a safety guarantee kernel modules never had.
At work
Production eBPF depends on kernel version, since hooks and helper functions vary between releases; BTF type information and CO-RE, short for compile once, run everywhere, let one binary adapt across kernels. Loading programs requires elevated capabilities such as CAP_BPF or CAP_SYS_ADMIN, and attackers have used eBPF in rootkits, so the sensors themselves need hardening. The eBPF Foundation coordinates the ecosystem, and Microsoft's eBPF for Windows extends the model beyond Linux. Prefer established projects over custom programs.
Real-world examples
At home
Marcus wondered why his home server's disk was so busy. A friend showed him an eBPF-based tool that listed every process opening files in real time. He found a misconfigured backup job within a minute.
At work
Nadia leads security operations at a Vancouver software company. Her team deployed an eBPF-based runtime sensor across its Kubernetes clusters, which flagged a container unexpectedly launching a shell, an early sign of a compromised image.
How it compares
| feature | eBPF | Kernel module |
|---|---|---|
| Safety | Checked by a verifier before running | Can crash or compromise the system |
| Deployment | Load and unload live | Often needs rebuilds for each kernel |
| Flexibility | Limited by verifier rules | Nearly unlimited |
| Typical use | Networking, monitoring, security | Device drivers and deep system changes |
eBPF gives most of a kernel module's reach with far less risk.
For analysts
When vendors say their tool is 'agentless' or 'zero overhead,' eBPF is often why. I'd still ask which kernel versions they support and what privileges their sensor needs, because a tool that sees everything is also a tool worth securing.
History & origin
The original Berkeley Packet Filter was described in a 1992 paper by Steven McCanne and Van Jacobson as a fast way to filter network packets. Around 2014, Alexei Starovoitov and others extended it into 'extended BPF,' a general-purpose virtual machine inside the Linux kernel, first merged in Linux 3.18. Meta, Google, Netflix, and Cloudflare adopted it for networking and profiling. The eBPF Foundation formed under the Linux Foundation in 2021, Microsoft began porting eBPF to Windows, and Cisco acquired Isovalent, the company behind Cilium, in 2024. In my opinion, eBPF is the rare infrastructure technology whose hype undersells it.