Speakers
Description
eBPF users pay for verified safety with performance. Across 27 microbenchmarks, we find that eBPF code runs 1.7–2.1x slower than the same code compiled natively. Most of the time is lost in the JIT, which translates one instruction at a time and leaves many hardware features unused. The JIT also does not adapt to the workload, such as stable map entries or branches. This is by design: the eBPF instruction set is designed for verification, not execution, and the kernel must trust the JIT and keeps it simple to keep the trusted computing base (TCB) small, so optimizing it is harder than optimizing a userspace JIT. We ask: how can we get the speed back without growing the TCB much?
We start with the hardware. We propose verified inline kfuncs (kinsn), which are kfuncs that BPF programs use like instructions, and can be verified and inlined by the JIT. Each carries a short eBPF body that the verifier checks at every call, while the JIT inlines native code in its place. We can also formally verify the eBPF and the native code is same. Seven such operations speed up microbenchmarks by up to 24% and Cilium and Katran by up to 12%.
kinsn fixes one operation at a time, but registers, branches and calls still slow down the whole program. What if the kernel just accepted native code? Then we propose kprog: it runs the whole program as native code, and the verifier checks an eBPF simulator of the native code, instead of JIT-compiling the eBPF into native code. You can then use any language or any compiler to compile your kernel extensions. A simulator is far easier and simpler to prove than an optimizing JIT, and applications run up to 1.83x faster.
Many workload patterns appear only at run time. To use them, we also propose Speculative ReJIT, which rewrites an unmodified application's bytecode in userspace and resubmits it to the existing verifier, so correctness stays in userspace and safety stays in the kernel.
We would like feedback on the kinsn interface, on when an operation should be applied at all, and on whether kprog and Speculative ReJIT are worth pursuing.