eBPF programs run up to twice as slow as natively compiled code, according to the authors' characterization of the kernel's current JIT. That single-pass translation, one bytecode instruction at a time, keeps the trusted computing base small but leaves performance on the table.
The Single-Pass Bottleneck
The in-kernel JIT is deliberately simple. Each bytecode instruction becomes exactly one native instruction, and the verifier guarantees safety before the JIT touches anything. This trust model works, but it means no optimization across instructions. Hardware idioms like rotate, conditional select, or carry-less multiply take multiple eBPF instructions, each dispatched separately.
Adding custom optimizations to the kernel JIT means upstream acceptance, a long release cycle, and bloated per-architecture code. That's a non-starter for any production team that needs a specific CPU feature tomorrow, not next year.
Kops: A Safe Extension Interface
Kops defines an extension interface that lets userspace compilers and kernel modules introduce new operations without touching the core kernel. Each operation has two forms: a proof sequence of vanilla eBPF instructions that the existing verifier already checks, and a native emit that the JIT compiles directly. The verifier sees only the proof sequence, so the native emit is the only per-operation addition to the trusted computing base.
Lean 4 proofs in the paper show that each native emit produces exactly the same result as its proof sequence. No new verifier logic, no new safety holes - just a direct mapping from a verified eBPF sequence to a hardware instruction.
EInsn: Seven Hardware Idioms on x86-64 and ARM64
Using Kops, the authors built EInsn: seven operations including rotate, conditional select, and popcount that CPUs execute as single instructions. On x86-64 and ARM64 microbenchmarks, EInsn speeds up eBPF by up to 24%. Production applications like XDP and tc filters get up to 12% speedup.
More aggressive whole-program native replacement reaches 2.358x speedup, though that comes with a larger TCB. The tradeoff is explicit: you choose how much of the kernel's trusted code you replace.
What This Enables
Kops opens the door to CPU-specific eBPF optimizations without waiting for kernel releases. Teams shipping on ARM64 can use SVE instructions today; x86 folks can grab AVX-512. The interface is general enough to support future ISAs or even custom accelerators. Next time you see a 2x gap between eBPF and native, you'll know exactly where to look: Kops makes that gap optional.
Source: Kops: Safely Extending the eBPF Compilation Pipeline with Native Operations
Domain: arxiv.org
Comments load interactively on the live page.