eBPF: The X-Ray Machine Inside Your Kernel

The Packet That Needed Filtering

In nineteen ninety-two, at the Lawrence Berkeley Laboratory in California, two researchers named Steven McCanne and Van Jacobson had a problem that sounds mundane but turned out to be foundational. They needed to capture network packets efficiently. The tool they were building, tcpdump, had to inspect every packet flowing through a network interface and decide which ones matched a filter. The trouble was that copying every single packet from the kernel into user space, just to throw most of them away, was devastatingly slow.

Their solution was elegant. Instead of copying packets out of the kernel for filtering, they put the filter inside the kernel. They designed a tiny virtual machine, a miniature computer inside the computer, that could run small filtering programs directly in kernel space. The user would write a rule like "show me only TCP packets on port eighty," and the system would compile that into bytecode that this virtual machine could execute. The virtual machine was deliberately limited. It could not loop forever. It could not access arbitrary memory. It could only look at packet data and make a yes-or-no decision: does this packet match the filter?

They called it the Berkeley Packet Filter, or BPF, and for over two decades, that is all it did. It filtered packets. It did this one job extremely well, and nobody thought much about whether it could do anything else.

The Kernel's Locked Door

To understand why eBPF matters, you need to understand a fundamental tension in operating system design. The Linux kernel is the software that sits between your applications and your hardware. Every network packet, every file operation, every process launch, every disk write passes through the kernel. If you could observe and act on those events, you would have total visibility into everything happening on your machine.

But the kernel is also the most dangerous place to put custom code. A bug in a normal application crashes the application. A bug in the kernel crashes the entire machine. For decades, if you wanted to add functionality to the Linux kernel, you had two options. You could submit a patch to the kernel source code, convince the maintainers to accept it, and then wait years for it to reach the distributions people actually run. Or you could write a kernel module, a piece of code that gets loaded into the kernel at runtime. Kernel modules are powerful but fragile. They run with no safety net. A single bad memory access can take down the whole system. And every new kernel version can break your module, because the internal APIs are not guaranteed to stay the same.

So most developers stayed in user space, the safe zone outside the kernel, and accepted that they could not see everything happening underneath. Monitoring tools worked by polling, sampling, or reading from special files that the kernel exposed. They were always a step removed from the action, looking through a foggy window instead of being in the room.

The Extension That Changed Everything

In twenty fourteen, a developer named Alexei Starovoitov submitted patches to the Linux kernel that took the old Berkeley Packet Filter and transformed it into something unrecognisable. Where classic BPF had two thirty-two-bit registers, extended BPF had ten sixty-four-bit registers. Where classic BPF could only filter packets, extended BPF could attach to almost any event in the kernel. Where classic BPF was a simple filter, extended BPF was a general-purpose programming environment running inside the kernel itself.

The key to making this safe was a component called the verifier. Before any eBPF program is allowed to run, the kernel puts it through rigorous static analysis. The verifier walks through every possible execution path and checks that the program cannot crash the kernel, cannot loop infinitely, cannot access memory it should not touch, and will always terminate. If the program passes verification, it is compiled to native machine code by a just-in-time compiler and attached to a kernel hook point. From that moment, every time that event fires, your program runs at near-zero cost, right there in the kernel.

Think about that for a moment. You can write a program that runs every time a TCP connection is established. Or every time a file is opened. Or every time a specific system call is made. Or every time a disk write completes. Your program runs in the most privileged context your computer has, at the speed of native code, with safety guarantees that prevent it from causing harm. Brendan Gregg, the performance engineer at Netflix who invented flame graphs, found a phrase for this.

eBPF does to Linux what JavaScript did to HTML. It turns a fixed system into a programmable platform.

That analogy is worth sitting with. Before JavaScript, a web page was a static document. The browser displayed it, and that was that. JavaScript turned the browser into a platform where you could run arbitrary programs, and the entire modern web was born. eBPF does the same thing to the kernel. The kernel was a fixed system. Now it is a platform where you can dynamically load programs to observe, filter, and act on any event happening in the most fundamental layer of your computer.

What Facebook, Netflix, and Apple Use It For

eBPF is not theoretical. It is not a research project. It is running in production at the companies that handle the highest volumes of traffic on the planet.

At Meta, every single network packet entering their data centres passes through eBPF programs that handle load balancing. They replaced their old load balancers with eBPF programs running inside the kernel, and the performance improvement was dramatic because the packets never leave kernel space. There is no copying to user space, no context switching, no overhead.

At Netflix, Brendan Gregg and his team use eBPF-based tools to trace performance issues across their massive infrastructure. If a streaming service is slow, they can attach an eBPF program to trace exactly which kernel functions are taking the longest, which files are being accessed, and which network paths are bottlenecked. This is not sampling. This is complete, real-time visibility into every operation the kernel performs, with almost no performance impact.

Apple uses eBPF for kernel security monitoring. DoorDash uses it for application monitoring. Digital Ocean and Cruise use it for GPU performance tracking. The eBPF Foundation, backed by the Linux Foundation with members including Meta, Google, Microsoft, Netflix, and Isovalent, is driving standardisation and even porting the technology to Windows.

Your Personal Superpowers

Now here is where this gets interesting for someone running a small infrastructure with a VPS and a pinkserver. eBPF is not just for companies with ten thousand servers. The same tools work on a single machine, and they give you visibility that was simply impossible before.

There is a tool called bpftrace that lets you write one-line eBPF programs from the command line. Want to see every file your FastAPI application opens in real time? One line. Want to count how many times each system call is made per second? One line. Want to trace how long your PostgreSQL queries take at the kernel level, not at the application level, but the actual time the kernel spends doing the disk reads and network sends? A few lines.

Another tool called bcc, the BPF Compiler Collection, provides dozens of ready-made tools for common tasks. You can see which processes are using the most disk bandwidth. You can trace DNS lookups. You can monitor TCP connection latency. You can watch which files are being cached and which are being evicted from the cache. Each of these tools is a small eBPF program that attaches to the relevant kernel events and reports back.

For your ÅrebladetLive dashboard, or for monitoring your PärCel shop performance, or for understanding why your Popcorn Photobooth workers sometimes stall, eBPF gives you the ability to look inside the kernel and see exactly what is happening. Not guessing from logs, not inferring from metrics, but watching the actual system calls, the actual network packets, the actual disk operations as they happen.

The Programmable Future

The original Berkeley Packet Filter was a two-register virtual machine that could say yes or no to a network packet. Thirty years later, its descendant is a general-purpose computation engine inside the Linux kernel, used by the largest technology companies on earth and available to anyone running a modern Linux distribution. The transformation happened gradually, patch by patch, over a decade of careful engineering, each step verified by a safety system that ensures the kernel cannot be harmed.

There is a documentary about the history of eBPF, featuring the developers who built it and the engineers who deployed it at scale. It tells the story of how a small community of kernel developers, working mostly at companies like Meta, Google, and a startup called Isovalent, turned a packet filter into a revolution. The documentary is free to watch, and if you have any curiosity about what runs beneath the software you build, it is worth your time.

eBPF represents a philosophical shift in how we think about operating systems. The kernel is no longer a black box that applications interact with through a fixed set of system calls. It is a programmable layer that you can extend, observe, and customise without recompiling, without rebooting, and without risk. Your pinkserver and your VPS both have this capability built in, right now, waiting to be used. All you need is a modern kernel and the curiosity to look inside.

In the final episode of this series, we climb back up from the kernel to the application layer, but this time we are looking at something much stranger than network protocols or service managers. We are going to look at what happens when you type ollama run in your terminal. What is in that GGUF file? How does a seventy-billion-parameter neural network get squeezed down to fit in the memory of a laptop? The answer involves a Bulgarian developer, a C library inspired by a French genius, and a mathematical trick called quantization that trades precision for possibility.