eBPF English: Linux Kernel Observability Vocabulary

Introduction

eBPF (extended Berkeley Packet Filter) is one of the most exciting technologies in modern Linux systems programming. It allows you to run sandboxed programs in the kernel without modifying kernel source code or loading kernel modules. Tools like Cilium, Falco, Tetragon, and bpftrace are built on eBPF, and they come with a rich vocabulary. Whether you are writing eBPF programs, using eBPF-based observability tools, or just discussing them in architecture reviews, this vocabulary is essential.

eBPF Programs and the Verifier

An eBPF program is a small piece of code that runs inside the Linux kernel. Before running, every eBPF program passes through the verifier — a kernel component that checks the program for safety. Engineers describe this as:

• “The verifier rejects unsafe programs” — programs with out-of-bounds memory access, infinite loops, or use of prohibited functions are rejected
• “We write the program in restricted C and compile to BPF bytecode” — the typical development workflow
• “The program must terminate” — the verifier enforces that all code paths have a bounded execution time
• “The program is JIT-compiled” — after verification, the kernel translates BPF bytecode to native machine code for performance

The phrase “pass the verifier” is used like passing a test: “Our first version of the program failed the verifier because of an unbounded loop — we had to restructure the logic.”

eBPF maps are data structures shared between the eBPF program and user-space code. Engineers say “we use a hash map to track per-connection state” or “we read the counters from the map in user space.” Common map types include hash maps, arrays, ring buffers, and LRU maps.

Attachment Points and Probes

eBPF programs are attached to specific hook points in the kernel or user space. The vocabulary for these attachment points is important:

• kprobe — attach to a kernel function entry; “we attach a kprobe to tcp_sendmsg to trace all TCP sends”
• kretprobe — attach to a kernel function return; “we use a kretprobe to capture the return value”
• tracepoint — a stable, documented hook point in the kernel; “we prefer tracepoints over kprobes because they are stable across kernel versions”
• uprobe — attach to a user-space function; “we use a uprobe to trace calls into the OpenSSL library without modifying it”
• XDP (eXpress Data Path) — attach at the network driver level; “we use XDP for high-performance packet filtering before the kernel networking stack”
• tc (traffic control) — attach to the network stack at the traffic control layer; “we use tc hooks for pod-level network policy in Cilium”

Engineers frequently say “we attach the program to a tracepoint” rather than “we install” or “we deploy.” The word attach is the correct verb in eBPF context.

Observability with bpftrace and BCC

Two common tools for eBPF-based observability are bpftrace and BCC (BPF Compiler Collection). Their vocabulary:

• one-liner — a short bpftrace script that traces a specific behaviour; “this bpftrace one-liner traces all open syscalls”
• probe — the specification of what to attach to and what to do; in bpftrace, probes are written as tracepoint:syscalls:sys_enter_open
• “We aggregate in-kernel” — collecting statistics inside the eBPF program rather than sending every event to user space; critical for performance
• flamegraph — a visualisation of call stacks; “we generate flamegraphs from perf data collected with eBPF”

Security and Policy

eBPF is used for security enforcement in tools like Falco and Tetragon:

• LSM hook (Linux Security Module) — an attachment point for security policy enforcement; “we use LSM hooks to enforce file access policy”
• policy enforcement — blocking or alerting on policy violations; “the Tetragon policy enforces that no process can open a shell after the container starts”
• “Observe, audit, enforce” — the three stages of security posture; “we start with observe mode to understand normal behaviour before enabling enforcement”

Key Vocabulary

Term	Definition
eBPF program	A sandboxed program that runs inside the Linux kernel
verifier	The kernel component that checks eBPF programs for safety before execution
eBPF map	A data structure shared between kernel eBPF programs and user-space code
kprobe	Dynamic attachment point at a kernel function entry
tracepoint	A stable, documented kernel hook point preferred over kprobes
uprobe	Attachment point at a user-space function entry
XDP	eXpress Data Path — the fastest eBPF attachment point for network packet processing
JIT-compiled	eBPF bytecode translated to native machine code by the kernel
aggregate in-kernel	Collect statistics inside the eBPF program to reduce user-space overhead
LSM hook	Linux Security Module hook point for enforcing security policy

Practice Tips

1. Run bpftrace one-liners on a test system. Even simple commands like tracing open syscalls give you practical experience with eBPF vocabulary. Write a sentence in English explaining what each one-liner does before running it.

2. Read Brendan Gregg’s blog and book. Brendan Gregg is the leading author on Linux performance and eBPF. His writing is technically excellent and uses consistent, precise English vocabulary. His blog posts are excellent reading practice.

3. Practise the verifier failure conversation. When an eBPF program fails the verifier, you need to explain why. Practise: “The verifier rejected the program because the loop iteration count is not bounded — we need to limit it with a known maximum value.”

4. Use “attach” not “deploy” or “install.” In eBPF discussions, the correct verb is “attach” when connecting a program to a hook point. Using the right word signals expertise.

Conclusion

eBPF vocabulary — verifier, maps, kprobes, tracepoints, XDP, and aggregate in-kernel — is precise and specific to kernel-level programming. As eBPF-based tools become standard in cloud-native observability and security, understanding this vocabulary will help you evaluate tools, contribute to architecture discussions, and write clear documentation. The technology is powerful but complex, and precise language is essential for discussing it effectively with teammates.