INFRA Signal 157
BPF Capsule runs DOOM inside unmodified Linux kernel eBPF
↗
Illustration only Photo by Vishnu Mohanan on Unsplash
A new BPF Capsule toolchain compiles and executes the DOOM engine as a single eBPF program on stock Linux kernels, showing that complex applications can run inside the kernel without patches.
Running a full game engine inside eBPF proves that the verifier can accept large, non-trivial programs, expanding the kinds of logic that can be placed directly in the kernel. This opens the door for sophisticated in-kernel processing such as deep packet inspection or on-the-fly statistics without writing kernel modules. However, the approach still inherits eBPF's strict safety checks, so developers must understand the associated constraints and performance trade-offs.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
BPF Capsule compiles C, C++, and no_std Rust code into eBPF that passes the stock verifier on kernels as old as Linux 5.15.
The DOOM demo runs initialization, game logic, and rendering in a single BPF invocation, with userspace supplying the WAD and input and receiving a framebuffer pointer.
Other workloads such as Lua, QuickJS, SQLite, wasm3, llama2.c, and CPython have also been run on the same scheme, providing runtime cost measurements.
THE READ
What the cluster adds up to.
The change introduced by BPF Capsule is the ability to load and execute large, complex programs inside the Linux kernel using the existing eBPF infrastructure. The author succeeded in getting an unmodified kernel to accept a DOOM binary after the stock verifier approved it, and the kernel JIT then executed the game tick in one BPF call. This demonstrates that the verifier’s safety model can be satisfied by non-trivial code without any kernel patches or separate virtual machines.
Adopting this technique requires a supported kernel (minimum profile Linux 5.15), the Nix package manager, and a valid DOOM WAD file. Developers must compile their source with clang targeting the bpf architecture, then load the resulting object via the bpf(2) system call. The compilation pipeline also includes transformations that reshape loops, pointer usage, and call graphs to meet verifier expectations, which adds engineering effort beyond a normal userspace build.
Despite the success, eBPF’s inherent limits still apply: a 512-byte stack per call chain, a bounded call depth, a maximum of 256 BPF functions per program, and a requirement that all loops be provably finite. Recursion is forbidden, and the verifier must prove termination for every execution path, meaning that some algorithms may need to be rewritten or emulated with a custom virtual machine inside eBPF. Consequently, programs that exceed these limits will be rejected or will need to be restructured, limiting the approach to workloads that can be expressed within these constraints.
The broader implication is that complex in-kernel logic, such as packet parsing, live statistics, or even embedded scripting, can now be prototyped without writing kernel modules, but developers must weigh the verification overhead and potential performance penalties against the convenience of staying inside the kernel. The article’s measurements of DOOM and other workloads provide early data on runtime costs, indicating feasibility while also highlighting that the approach remains experimental and best suited for cases where the benefits of kernel-resident execution outweigh the engineering complexity.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER