Tutorial outline
What this tutorial covers, how the chapters are grouped, and the order in which they build on each other.
This tutorial takes a developer who already knows Rust (you have read
The Rust Programming Language) and teaches them to write eBPF
programs in Rust with Aya β from a first
βhello worldβ probe through XDP load balancers, sched_ext
schedulers, LSM security programs, and the newest kernel surfaces
like struct_ops, kfuncs, BPF arenas, and BPF tokens.
It is deliberately structured as a lab. You write code on a
Fedora 44 laptop, but you never load eBPF into your laptopβs
kernel. Instead you deploy each program to a disposable Fedora 44
virtual machine running under KVM/QEMU, so a program that panics the
verifier β or worse, the kernel β costs you a virsh destroy and a
re-provision, not your working machine. Client load comes from
Python 3.14 drivers in Podman, and every programβs output is wired
into Grafana through OpenTelemetry so you can see what your probe
measured.
How the chapters are grouped
The tutorial is organized into parts. The Foundations part (Chapters 0β6) is the setup you do once; everything after it is a self-contained program you build, deploy, and observe. Later parts can be read roughly in order, but each program chapter stands on its own once the lab exists.
| Part | Theme | Chapters |
|---|---|---|
| Foundations | Lab, toolchain, first program | 0β6 |
| Tracing the kernel | kprobes, fentry, tracepoints | 7β12 |
| User-space & language probing | uprobes, USDT, runtimes | 13β20 |
| Performance & resources | scheduling, IRQs, memory, I/O, power | 21β26 |
| Networking | sockets, TC, XDP, L7 | 27β36 |
| Security & LSM | enforcement, offense, defense | 37β42 |
Schedulers (sched_ext) |
writing BPF schedulers | 43β44 |
| Application targets | real workloads | 45β47 |
| Advanced kernel surface | the 2024β2026 BPF feature set | 48β57 |
| Operating eBPF | CO-RE, zero-downtime, offload, power, signal correlation, capstone | 58β63 |
| Field guide (optional) | bpftrace, bpftool, and the BCC tools, driven from Python |
64β66 |
| Retrospective | the whole arc, and where eBPF & Aya go next | 67 |
| Addenda (optional) | HE workload observability; eBPF metrics with Performance Co-Pilot | 68β69 |
The Foundations chapters (do these first, in order)
These six chapters are the floor. Nothing in the later parts works until you have a lab that builds, deploys, and reports.
| Ch | Title | What you get |
|---|---|---|
| 1 | Prerequisites | Hardware floor, Fedora 44, KVM/QEMU/libvirt, what to have installed |
| 2 | Lab setup: the eBPF target VM(s) | A scripted Fedora 44 guest under libvirt; a second guest + the network between them for two-host tests |
| 3 | The observability stack | grafana/otel-lgtm under Podman Compose; a Python 3.14 OTLP client; how Rust user space exports to it |
| 4 | The Rust + Aya toolchain | rustup (Rust 1.96.0), the BPF target, bpf-linker, cargo-generate + aya-template, RustRover, kernel tools from Fedora repos |
| 5 | eBPF concepts and tools | Programs, maps, the verifier, BTF, CO-RE, and how bpftool/bpftrace fit in |
| 6 | Hello, eBPF | A first Aya program (with a short libbpf / libbpf-rs warm-up), deployed to the VM, output in Grafana |
What comes after Foundations
Each later chapter follows the same shape: a short concept section, a
runnable Aya project under examples/, a demo.sh that builds it,
ships it to the target VM, runs it, drives load, and shows where the
output appears in Grafana. The full chapter list β including the
exact programs (opensnoop, execsnoop, tcpconnlat, xdp
load balancer, scx_nest, sslsniff, struct_ops, and the rest) unfolds across the parts ahead.
We start the eBPF work with libbpf and libbpf-rs for a single chapter so the C-and-CO-RE mental model is concrete, then move to Aya as the primary toolkit for everything else.
Conventions used throughout
- All host commands target Fedora 44 with rootless Podman and
libvirt/KVM. Where a command must run inside the target VM
rather than on the laptop, the prose says so explicitly and the
prompt is shown as
[vm]$. - Commands you paste are written as single lines (semicolons and
\continuations rather than multi-line blocks) because multi-line pastes misbehave in zsh with bracketed-paste and autosuggest. Any multi-step procedure ships as a script in the iteration tarball, not as a block to paste by hand. - Test scripts use
127.0.0.1, neverlocalhostβ moderncurlprefers IPv6::1and many runtimes bind IPv4 only. - Bind mounts carry the
:ZSELinux relabel suffix. It is correct on Fedora and a harmless no-op elsewhere. - Container images are UBI-based (
registry.access.redhat.com/ubi9/...) and pull without a Red Hat subscription. - Kernel tooling β
bpftool,bpftrace,bcc,perfβ is installed from Fedora/Red Hat repositories viadnf, never from third-party binaries. - Every technical claim is verified (Fedora 44, kernel 7.1.3): run end-to-end on the real KVM lab and tracked in the reconciliation plan. Your own hardware is the final check. If a chapter hasnβt been verified yet, its claims are marked as such.
Prerequisite knowledge (not taught here)
- Rust at the level of The Rust Programming Language β ownership,
traits,
Result,async/await, Cargo. This is not a Rust course. - Comfort with the Linux command line and a shell (the tutorial assumes zsh, but bash is fine).
- A paragraph-level idea of what the Linux kernel does: syscalls, processes, network packets. eBPF concepts themselves are taught in Chapter 5.
Reference material
The tutorial leans on, and frequently points at, this canonical set:
- Learning eBPF β Liz Rice
- ebpf.io/get-started
- BPF Performance Tools β Brendan Gregg
- The Aya Book and Aya API docs
- Articles by Luca Palmieri and the Zero To Production in Rust book (zero2prod.com) for Rust application and project-structure patterns
- Material from Isovalent/Cilium and the broader Oxidizing eBPF community
A note on sources β We take insight freely from the whole eBPF community, but the code we ship is our own: we donβt copy or port code line-for-line from other repositories, and anything borrowed carries a clearly compatible license. See
CONTRIBUTING.mdfor the full provenance policy.