BPF in the agentic era [LWN.net]
LWN<br>.net<br>News from the source
Content Weekly Edition<br>Archives<br>Search<br>Kernel<br>Security<br>Events calendar<br>Unread comments
LWN FAQ<br>Write for us
Edition Return to the Front page
User:<br>Password: |
Log in /<br>Subscribe /<br>Register
BPF in the agentic era
LWN.net needs you!
Without subscribers, LWN would simply not exist. Please consider<br>signing up for a subscription and helping<br>to keep LWN publishing.
By Daroc Alden<br>June 3, 2026
LSFMM+BPF
Alexei Starovoitov gave "less of a presentation, more of a scream of<br>realization" at the BPF track of the 2026
Linux Storage, Filesystem,<br>Memory-Management, and BPF Summit. He shared a set of ideas for how BPF could<br>change to avoid being swept away by the sea-change in programming represented by modern<br>large language models (LLMs) and the coding agents based on them.<br>In a follow-up session, the discussion covered<br>more problems with how coding agents use tools like bpftrace, and the current deluge of<br>patches in need of review in the BPF subsystem.
He wanted to be clear that these ideas were not something he was unilaterally<br>deciding on, they were "just looking at how the world has to be". Coding agents do<br>their best work when given tight feedback loops, he said. They write code, see<br>errors, and make fixes. This makes them good at handling tedious jobs such as<br>large refactoring operations. That feedback loop doesn't work well in the BPF ecosystem,<br>especially when one has to boot a virtual machine in order to properly test a<br>change.
Even when a BPF programmer has attempted to load their program into the kernel, errors<br>from the verifier "are insane" — huge dumps of data that obscure the<br>actual source of the problem. In Starovoitov's experience, writing BPF code is the<br>only case he has observed where LLMs will give up rather than producing<br>something.
BPF can never crash the kernel. "That's what BPF stands<br>for." That is the one thing that makes the ecosystem unique. So, the BPF<br>verifier isn't going away, and it needs to run in the kernel because user space<br>is untrustworthy. This adds a certain amount of unavoidable latency and<br>complexity between writing a BPF program and getting feedback on it.<br>Given that constraint, how can BPF developers shorten the<br>feedback loops between writing a BPF program and getting a useful error message?
Right now, the verifier essentially has two roles: finding places where the<br>programmer made a mistake, and acting as a security boundary. The first part<br>doesn't need to be done in the kernel; languages such as Rust do a<br>great job of confronting programmers with their mistakes in user space. The BPF<br>developers should be working to make BPF easy to use with Rust, so that simple mistakes<br>can be caught quickly, Starovoitov said. Any program that does pass the Rust compiler — and<br>doesn't do anything obnoxious with unsafe code or inline assembly — should pass<br>the verifier as well. Obviously programmers will still be able to cause verifier<br>errors if they try, but well-intentioned, normal BPF programs written in Rust<br>should not cause verifier errors, he said.
Making this happen may require further work on the verifier, or the careful<br>addition of run-time checks to BPF. But it's a goal that Starovoitov believes is<br>possible and worthwhile. There are other ways to shorten the feedback loop for<br>BPF programmers, of course. If BPF could be made to work in
user-mode Linux,<br>for example, there would be no more need to test BPF code in virtual machines.
This confused one member of the audience, who objected that Starovoitov had<br>previously soundly rejected the idea of moving the BPF verifier to user space.<br>The real kernel can't trust user space, Starovoitov said, but it should be<br>possible to run the verifier in user-mode Linux in order to shorten the time it<br>takes to receive a verifier error if one is forthcoming.
All of these changes are coming quickly. In a few months, "there will be no<br>fighting the verifier anymore," Starovoitov promised, as long as one writes<br>BPF programs in Rust. The verifier will use run-time<br>checks where necessary to make everything work. José Marchesi asked whether that<br>change was currently in development. Starovoitov confirmed that it was.
Daniel<br>Borkmann asked how the output from the verifier would change.<br>Current verifier errors are far too opaque, Starovoitov said. They say<br>things like "register is not init" — what is a programmer supposed to do with<br>that? The verifier needs error messages that say what happened and how to fix<br>it. This is another area where Starovoitov wants to take inspiration from Rust,<br>and, in particular, the formatting of its error messages. "You guys are all<br>dinosaurs; Rust won as a language," he said, at least in part because of the<br>quality of its error messages.
In the end, he wants there to be almost no verifier errors. The ones that remain<br>should include details about what went wrong and how to fix it. This change<br>isn't going to happen overnight, he said, but "it is where...