CoursesAdvanced Linux securityDetection engineering

eBPF tracing fundamentals

Probes, maps, and the verifier.

Advanced14 min · lesson 11 of 17

eBPF is the technology that lets you run small, sandboxed programs inside the Linux kernel to observe (and sometimes act on) events as they happen — syscalls, network packets, file access, process execution — with very low overhead and without kernel modules. For security it is transformative: instead of polling state after the fact (like osquery) or parsing logs, an eBPF probe sees the event at the moment it occurs, in the kernel, where it is hardest for userland tricks to hide it. It is the engine under modern Linux runtime security tools.

Why eBPF is safe to run in the kernel
the safety model
verifier
proves the program is bounded + memory-safe BEFORE load
no loops/crashes
cannot hang or panic the kernel
maps
share data with userspace safely
The in-kernel verifier is why you can run untrusted-ish observation code in the kernel without the risk of a kernel module.

The verifier: safety before power

The reason you can load a program into the kernel without the danger of a kernel module is the verifier: before an eBPF program is allowed to run, the kernel statically proves it is safe — it terminates (bounded loops, no infinite loops), it only accesses memory it is allowed to, and it cannot crash the kernel. Only a program that passes runs. This is what makes eBPF observation fundamentally safer than a kernel module: the module has the run of the kernel and can be a rootkit, while an eBPF program is constrained by the kernel itself before it ever executes.

From raw eBPF to security tools

You rarely write raw eBPF for security; you use tools built on it. The bcc and bpftrace projects let you write probes quickly (bpftrace is a one-line tracing language); Tetragon and Falco use eBPF to enforce and detect security policy; and observability platforms use it to trace everything a process does. The concept to carry forward is that eBPF gives you real-time, in-kernel, low-overhead event visibility — process executions, network connections, file opens — which is precisely the raw material the detection lessons turn into alerts.

terminal
# bpftrace: a one-liner that watches every process execution live (via an eBPF probe)
$ sudo bpftrace -e 'tracepoint:syscalls:sys_enter_execve { printf("%s -> %s\n", comm, str(args->filename)); }'
nginx -> /bin/sh # a web server spawning a shell — exactly what you want to catch
# security tools (Falco, Tetragon) build on this to turn events into detections
eBPF sees the event; you still must decide what matters
eBPF gives you a firehose of ground-truth kernel events at low cost, but raw visibility is not detection — a stream of every execve and connect is noise until you key on the behaviors that matter (a shell from a service, a connection to an unexpected destination). The value is that the data is real-time and hard to hide from; the work is the same as always: turn high-signal behavior into alerts and tune out the rest. The next lessons are about doing exactly that.