From Concept to Mechanism
To understand why eBPF profiling is safe and low-overhead, you need to understand what actually happens when an eBPF program runs. This is not magic — it is a well-defined execution model.
Step 1: Write the eBPF program. An eBPF program is written in a restricted subset of C (or higher-level languages that compile to eBPF bytecode). It is small — typically tens to hundreds of lines. It cannot loop infinitely, cannot crash the kernel, and cannot access arbitrary memory.
Step 2: Verify. Before the kernel runs a single instruction of your eBPF program, it passes it through the eBPF Verifier — a static analysis engine built into the kernel. The verifier checks that the program terminates (no infinite loops), accesses only memory it is allowed to access, and does not call unsafe kernel functions. If verification fails, the program is rejected. This is the safety guarantee.
Step 3: JIT Compile. Once verified, the kernel's JIT (Just-In-Time) compiler translates the eBPF bytecode into native machine instructions for your CPU architecture (x86-64, ARM64, etc.). This is why overhead is so low — the eBPF program runs as native code, not interpreted bytecode.
Step 4: Attach to a hook. The compiled program is attached to a kernel hook point — an event that triggers execution. For CPU profiling, the hook is a perf event: a hardware timer interrupt that fires at a fixed frequency (e.g., 99 Hz). Every time the timer fires, the eBPF program runs, reads the current CPU instruction pointer and call stack, and writes it to a BPF map (a shared memory structure between kernel and userspace).
Step 5: Userspace reads the map. The profiling agent (running in userspace) periodically reads the BPF map, collects the raw stack addresses, and ships them to the storage backend.