— Linux, Kernel, BPF — 3 min read
The eBPF Track starts off on the first day (11th of December) of Linux Plumbers Conference 2025 with topics on BPF verifier, with Ihor and Jordan kick-starting the track with bpfvv, the BPF Verifier Visualizer. One of the difficulties working with BPF is getting a complex program to pass the verifier, which requires you to first understand what the verifier “sees”. The verifier log provides all you need, but in a compact format that outputs only the minimum “diff” required, which can be mind-twisting and error-prone when reconstructing by hand. bpfvv bridges this gap by providing a way to easily inspect the full state that the BPF verifier sees at any point of the program, helping both developers working within the verifier, and developers trying to figure out what may be needed to get their program to verify successfully.
Up next, we have not one, but two talks related to control-flow handling of the BPF verifier. Control-flow constructs (e.g. loop) are notoriously difficult to verify correctly and efficiently, BPF or not. The way it is done is that the BPF verifier follows all possible execution paths (including branching), and iterates until it reaches a virtual machine state that it had seen before, and is known to be safe, when this condition is met, the verifier can assume any possible execution that comes afterwards is still safe, hence further exploration isn’t needed. This is the concept behind state pruning. Based on the title Mahé and Paul’s talk will focus on the state pruning, whereas Eduard (who fixed loop verification issue) will give a broader coverage and perhaps propose possible improvements. I look very much forward to their talks.
After break Yiming will talk about ePass, tackling the challenge of verification of complex BPF programs through an in-kernel LLVM like compiler framework of under 100 lines of code that seems to insert runtime checks in places where BPF verifier’s static approach have difficulty in.
Paul will then return to the stage (just like last year) to talk about fuzzing with a test oracle (i.e. an alarm that can go off when things went wrong on BPF side) so Syzkaller can catch issues beyond use-after-free and the likes. Paul has been doing a lot of work on verifier safety, ranging from fuzzer improvements (topic of his last year’s talk), to formal verification of the BPF verifier (Agni). It will truly be interesting to hear what he has to say, and what is needed to help make checking the BPF verifier easier.
Last BPF core session is about introducing load-acquire and store-release instructions to the current instruction set (published as RFC9669), from Peilin. BPF is mainly used on x86-64, which provides a strong memory ordering guarantee, and the BPF atomic instructions are sufficient, but the same cannot be said for architecture like ARM64, where the memory ordering semantic is much more relaxed.
After lunch, we’ll then move forward to security-related topics.
The first is a discussion on security aspects of BPF itself – BPF signing. BPF signing is difficult because BPF programs are patched at load time by libbpf (e.g. for CO-RE), thus simple bytecodes signing of BPF programs (as is done for kernel modules) wouldn’t work. The BPF signing patchset that was merged instead opted to also sign the loader program, which contains native code and handles patching and loading of the BPF program.
The talks that follow are related security applications of BPF, with BPF LSM now much widely available, it seems security applications of BPF are gaining broader adoption (and is likely the 3rd major application of BPF, after tracing and networking). Liam will be presenting BpfJailer, a eBPF-based Mandatory Access Control (MAC) that secures and sandboxes processes at Meta. Traditionally, MAC is done with kernel modules like SELinux or AppArmor, but they lack the fine-grained control that is needed to narrow down security policies, hence this is another field that can really be helped by the programmability of BPF.
The next is a talk on tracking files with BPF from Carl. File tracking is a difficult task, even the basic operation of identification of a file with path name is not a straightforward field access, this is much unlike other resources that BPF deals with (e.g. process by tid/pid); yet, at the same time, making sure important files isn’t copied or tampered is a fundamental component of security policies.
The last group of sessions on the first day are the high-level networking related sessions.
The first in the group is from Justin, about building DFA-based regex and running them in BPF (presumably this is needed at least for domain name filtering), and ties back to the BpfJailer MAC that was introduced two sessions ago.
Then we continue down this line on domain name, with Hemanth talking about challenges of implementing fully qualified domain name (FQDN) policies. With Linux Kernel having no concept of domain names, unlike IP addresses, hence an additional layer is needed to translate domain name into IP addresses. Right now this translation layer operates in userspace, but Hemanth will explore moving that layer into BPF.
Last but not least of the day, we have Raman talking about implementing a simple local DNS server with BPF. Unlike the previous talk, this focuses on UDP-based DNS only, but must additionally deal with actually responding to requests in BPF, and all its implications.
That’s all we have for day 1 of eBPF Track at Linux Plumbers Conference 2025!