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.

In Practice: Navigating Nuances for Non-Native Speakers

eBPF (extended Berkeley Packet Filter) is rapidly becoming a cornerstone of modern Linux observability. But the terminology can be dense, filled with precise phrasing that’s crucial for effective communication within development teams and during deployments. For developers whose first language isn’t English, particularly when dealing with technical concepts, understanding these nuances is paramount. It’s not just about translating words; it’s about grasping how they are typically used in professional contexts – the subtle implications of choice that can impact a code review, a deployment strategy, or even a security policy.

Let’s consider a common scenario: you’re reviewing a pull request submitted by a colleague. The PR description reads, “This probe collects trace data for HTTP requests exceeding 1KB in size, utilizing a map to filter out known internal traffic.” A non-native speaker might struggle with the layered meaning. “Probe” isn’t just any monitoring tool; it’s a specifically designed piece of eBPF code that actively observes and records events. “Trace data” signifies detailed information about those events – timestamps, arguments, return values – all crucial for debugging performance issues or identifying bottlenecks. The use of “utilizing a map to filter out known internal traffic” highlights the importance of efficiency; maps are key-value stores within eBPF that allow you to quickly identify and discard irrelevant data, preventing your probes from overwhelming your system. It’s about understanding not just what is being done, but why it’s been chosen this way – a deliberate optimization for performance and accuracy. Similarly, when discussing security policies, phrases like “deny traffic based on source IP address” require careful consideration of the implications of blocking access versus allowing it.

Another example might appear in a Slack conversation: “Hey team, can someone investigate why we’re seeing high latency spikes? Let’s focus on the eBPF probes monitoring network packet processing – specifically, the one related to TCP congestion control.” The phrasing here is deliberately technical and assumes shared understanding of eBPF’s role. “Latency spikes” immediately points to a performance issue needing immediate attention. The instruction to “focus” implies a prioritization of investigations, and specifying the relevant probe helps narrow down the scope. It’s not simply about reporting; it’s about directing efforts toward a specific area of concern.

Finally, when writing PR descriptions or documentation, always aim for clarity and precision. Avoid jargon unless absolutely necessary, and when you do use technical terms, provide brief explanations to ensure everyone on the team is on the same page. Remember that effective communication is as important as the eBPF code itself; it’s what allows you to collaborate effectively and build robust, observable systems.

# Example of creating a simple eBPF map using bpftool
bpftool maps create my_http_request_map TYPE hash SIZE 1024 KEY name VALUE http_url