What is eBPF?

01 Why this matters to you

You're an app developer. When something is slow, flaky, or weird in production, your usual move is: add log lines, redeploy, and hope you logged the right thing. eBPF flips that around.

With eBPF you can ask the already-running system a precise question — "which files is this process opening?", "what's making this syscall?", "where is the latency?" — and get an answer in seconds. No code change. No restart. No guessing.

02 The wall between you and the interesting stuff

Your program runs in user space. But almost everything you'd want to observe — opening files, sending packets, scheduling threads, disk I/O — actually happens down in kernel space, on the other side of the system-call boundary. From user space you can see that you called open(), but not what the kernel did underneath.

Historically you had only two ways to run your own code inside the kernel to look — both bad for a casual observer:

03 The analogy: JavaScript, but for the kernel

This is the mental model the eBPF community itself reaches for. A web browser lets pages run little sandboxed JavaScript programs on events (a click, a page load). The browser guarantees that script can't crash your computer, and a JIT compiler makes it run fast.

eBPF does the same thing for the Linux kernel. The kernel is the "browser." Your eBPF program is the "JavaScript." Kernel events (a syscall, a function call, a network packet) are the "click handlers." A built-in safety checker plus a JIT make it safe and fast.

Analogy from ebpf.io — "What is eBPF?", the canonical introduction.

04 What an eBPF observability session looks like

Here's the shape of every tracing session you'll do. An event in the kernel triggers your program; your program records something into a map (a shared table); your user-space tool reads the map and prints it to you.

The four moving parts

• Event / hook — the "when." A syscall, a kernel or user-space function, a tracepoint, a network packet. Your program is glued to one of these.
• The eBPF program — the "what to do." Tiny, runs in the kernel, fires every time the event happens.
• The verifier (+ JIT) — the safety gate. Before your program is allowed to run, the kernel proves it can't hang or read bad memory, then compiles it to fast native code.
• The map — the "how data gets out." A shared data structure (hash table, histogram, ring buffer…) that both the kernel program and your user-space tool can touch.

Lifecycle & components per ebpf.io and Brendan Gregg, Linux eBPF Tracing Tools.

05 Why it won't crash your machine: the verifier

This is the part that makes eBPF usable in production — and the reason it's not just "kernel modules with a nicer name." When you load an eBPF program, the kernel's verifier statically analyzes it before a single instruction runs and rejects it unless it can prove:

• it always terminates (no infinite loops),
• it never reads uninitialized or out-of-bounds memory,
• it stays within size and complexity limits, and
• it only touches kernel data through safe, stable helper functions — not arbitrary memory.

If the proof fails, the program simply doesn't load — you get an error, the kernel keeps running. If it passes, a JIT compiler turns the bytecode into native machine code so it runs at roughly the speed of compiled-in kernel code. Loading generally requires root or the CAP_BPF capability.

Verifier behavior & safety guarantees: ebpf.io — What is eBPF?

06 A glimpse of what you'll actually type

You won't write kernel C to start — you'll write bpftrace, a high-level tracing language where everything from the diagram above is handled for you. Here's a real one-liner. Don't worry about the syntax yet; just see the shape:

# prints every file every program opens, system-wide
bpftrace -e 'tracepoint:syscalls:sys_enter_openat {
              printf("%s opened %s\n", comm, str(args->filename));
            }'

Read it as WHEN ... DO ...:

• WHEN tracepoint:syscalls:sys_enter_openat — every time any process enters the openat syscall (the event / hook).
• DO printf(...) — print the process name (comm) and the filename argument (args->filename).

That one line is an eBPF program: bpftrace compiles it, the verifier checks it, the kernel attaches it to that syscall, and the output streams back to your terminal. You'll learn to read and write every piece of this in Lesson 3.

Style from the official bpftrace One-Liner Tutorial.

07 eBPF vs. the old way, at a glance

08 Clear up four myths before we go on

09 Check yourself

Pick an answer — you'll get instant feedback. No grading, just a tight feedback loop.

10 Flashcards

Click to reveal. Come back to these later for quick review.