Why You Should Pay Attention to eBPF

While it’s far from a mainstream subject, we’ve been hearing a fair amount of chatter from smart people we follow about eBPF. At RedMonk we’ve learned to pay attention when up and coming technologies garner interest from people we respect, as historically speaking this pattern tends to signal relevance and suggest the potential for future importance. The fact that in this case the fact that the tech in question is related to DTrace only raises more flags for us.

Here’s a quick, non-comprehensive eBPF primer for the curious:

• eBPF stands for nothing. It used to be an acronym for Extended Berkeley Packet Filter, but per the docs it is “no longer an acronym for anything.”

• eBPF allows you to run event-driven programs inside the Linux kernel. Programmers can run custom bytecode inside a sandboxed kernel environment without directly modifying the kernel source code itself.

• eBPF is considered more secure than Linux Loadable Kernel Modules (LKM) because there are additional safety checks and verifications that must pass before the code executes.

• Events can be driven off a variety of kernel hooks. Common kernel hooks that trigger eBPF programs include system calls, network events (like a network package arriving), calls to particular functions in the kernel, and tracepoints getting hit.

• People generally don’t write the bytecode by hand, typically it’s compiled from C or Rust. eBPF programs are then JIT compiled to machine code after they are triggered.

• eBPF is related to DTrace.

Correction: This post previously said that eBPF was inspired by DTrace, but Brendan Gregg kindly provided the following correction after I published. His comments are greatly appreciated, and I’m sharing them here to provide this context for others:

eBPF was not inspired by DTrace; its origin is software defined networking (and before that, BPF itself was for packet filtering). Early on the co-creator of eBPF (Alexei Starovoitov, then working at the SDN startup PLUMgrid) realized it could be used to implement more than just SDNs, and I got involved to reimplement my DTrace tools using eBPF. We do have a DTrace-inspired frontend called bpftrace, but that came years later. Put differently, DTrace can be implemented as an eBPF program, but eBPF itself is far bigger. eBPF isn’t a tracer — it’s a kernel execution environment.

• The primary use cases of eBPF fall into three overarching buckets: networking, observability, and security.

eBPF is definitely a technology we’ll continue to watch closely. Especially with the introduction of technologies like Istio Ambient Mesh, eBPF is poised to play a growing role in the ecosystem.

Additional Resources:

• Corey Quinn did a fantastic interview with Liz Rice discussing eBPF and Cilium
• eBPF docs
• A guide from Tigera: eBPF Explained
• InfoQ: A Gentle Introduction to eBPF
• Brendan Gregg’s tweets, which are generally full of eBPF goodness