eBPF
/ EE-bee-pee-EFF /
Suppose you want to ask the operating system kernel a question it was never designed to answer — 'how long does every disk write take, grouped by process?' Normally you cannot, because the kernel is a sealed, privileged program and you cannot just edit it while it runs. eBPF is the surprising answer: it lets you load a tiny, safety-checked program of your own INTO the running kernel, attach it to an event of interest, and have the kernel run it whenever that event happens — without rebooting, recompiling the kernel, or risking a crash.
Concretely, eBPF is a small virtual machine built into the Linux kernel: it has its own simple instruction set (registers, a tiny stack, and a fixed set of allowed helper calls). You write a program in a restricted subset of C (or in a higher-level tool's language), compile it to eBPF bytecode, and the kernel loads it. Before the kernel will run it, a component called the verifier statically proves the program is safe and always terminates (see the eBPF verifier); only then is it accepted and just-in-time compiled to native machine code for speed. The program is attached to a hook — a point in the kernel where it should fire, such as a network packet arriving, a system call entry, a kprobe on an arbitrary kernel function, or a tracepoint. When the hook fires, your program runs in kernel context, can read the relevant data, and stashes results into a BPF map — a key-value store shared between the kernel-side program and a user-space tool that reads the results.
It matters because it turned the kernel from a black box into something you can safely instrument and extend live — it powers a generation of production tools for tracing, networking, and security. Two honest cautions belong here. First, eBPF is NOT general kernel programming: the verifier's safety constraints are strict, so there are many things ordinary C can do that an eBPF program simply may not (no unbounded loops historically, limited stack, only approved helpers). Second, this field uses eBPF for observability and tracing; eBPF is ALSO used for syscall filtering and security enforcement, but that security side is covered elsewhere — here it is a read-mostly lens for seeing inside a live system.
# count read() syscalls per process, live, with the bpftrace front-end: $ bpftrace -e 'tracepoint:syscalls:sys_enter_read { @[comm] = count(); }' # @[bash]: 12 @[nginx]: 8841 @[postgres]: 412 # the one-liner compiles to eBPF bytecode, the verifier checks it, the kernel runs it on every read()
An eBPF program attached to the read() tracepoint tallies calls per command into a map — no kernel rebuild, observed on a live system.
The name is historical: BPF began as the Berkeley Packet Filter for capturing network packets; 'extended BPF' generalised that little in-kernel machine to events all over the kernel, so the 'packet filter' name no longer describes most of what it does.