In Linux eBPF, at what point does the kernel's verifier examine your program, and what happens to a program that fails verification?

## The one-sentence model eBPF lets you run your own code inside the kernel. The reason that is not insane is the **verifier**: a static analyser inside the kernel that must prove your program is safe *before* the kernel will accept it. Verification happens once, at load; after that the program runs at native speed with no runtime supervisor watching it. ## Where in the lifecycle it sits An eBPF program's life has four distinct stages, and people routinely blur the middle two: 1. **Compile** — clang compiles C to eBPF bytecode in an ELF object (`clang -target bpf`). No kernel involvement; clang will happily produce bytecode the kernel will refuse. 2. **Load** — a loader (libbpf, bcc, `bpftool prog load`, a Go or Rust library) calls the `bpf()` syscall with the `BPF_PROG_LOAD` command, passing the instructions, the program type, and a log buffer. **This is where the verifier runs.** On success the kernel returns a file descriptor for the program and JIT-compiles it to native instructions. 3. **Attach** — the program fd is wired to a hook (a tracepoint, a kprobe, a network interface, a cgroup). Attachment can fail on its own — wrong program type for the hook, a missing symbol, insufficient privilege — and that is *not* a verifier failure. 4. **Run** — the hook fires and the JIT-compiled code executes in kernel context. So "it didn't load" and "it didn't attach" are different bugs with different error text, and saying which one you hit is the first thing an interviewer listens for. ## What failure looks like The `bpf()` syscall returns `-1` and sets `errno`; a verifier rejection is usually `EACCES` (other load problems, like a malformed instruction stream or a bad argument, come back as `EINVAL`). The interesting part is the **verifier log**: the caller passes a buffer and a log level, and the kernel writes a trace of the paths it explored, the register state at each step, and a final line naming the instruction it could not accept — for example an invalid memory access, an unreachable instruction, or an unbounded loop. That log is written to your buffer, not to `dmesg`. libbpf prints it to stderr when a load fails; if it is truncated, you raise the log level and enlarge the buffer. Reading the log is the actual skill here — the last few lines usually name the register and the instruction index, and mapping that index back to your C is the debugging loop. ## Why it is all-or-nothing A kernel that ran unproven code and caught mistakes at runtime would need bounds checks, fault handling and a scheduler for your code — in other words, a sandbox with a runtime cost on every hook, in paths that fire millions of times a second. eBPF instead pays the cost **once**, at load, and then runs unguarded native code. The consequence is that the guarantee has to be total: a program that might be unsafe on one path out of a thousand is rejected outright, because at runtime nobody is checking. The corollary that catches people: a program the verifier accepts is safe in the memory-and-termination sense, not *correct*. It cannot crash the kernel, but it can still count the wrong thing, drop the wrong packet, or be far too expensive to run in a hot path. ## The practical consequences - **Verification is per-load, not per-attach.** Attaching the same program fd to a second hook does not re-verify it. Loading the same object file again does. - **The verifier is conservative.** Rejection means "I could not prove this safe", not "this is definitely broken". Perfectly correct programs get rejected, and the fix is to restructure the code so the proof becomes easy. - **Results vary by kernel.** The verifier improves release to release, so an object that loads on a 6.x kernel may be rejected on an older one. "Works on my laptop, rejected on the fleet's older kernel" is a real and common failure. - **Privilege matters.** Loading normally requires root or `CAP_BPF` (plus `CAP_PERFMON` for tracing, `CAP_NET_ADMIN` for networking hooks); unprivileged loading is disabled on most distributions, and unprivileged programs face extra restrictions on top of the ordinary ones.