What is eBPF?

eBPF (extended Berkeley Packet Filter) is a technology that lets you run small, safe programs inside the Linux kernel without changing the kernel code. It’s like adding tiny plug-ins that can watch, filter, or modify network traffic and system events on the fly.

Let's break it down

  • eBPF: a modern version of an old packet-filter tool, now a general-purpose way to run code in the kernel.
  • Extended: it can do many more things than just filter packets, such as tracing, security, and performance monitoring.
  • Run inside the kernel: the code executes where the operating system core works, giving it fast access to data.
  • Small, safe programs: the code is limited in size and checked by a verifier so it can’t crash the system.
  • Without changing kernel code: you don’t need to recompile or reboot the OS; you load the program at runtime.

Why does it matter?

Because it gives developers powerful visibility and control over a running Linux system without the risk and hassle of modifying the kernel itself. This means faster debugging, better security, and more efficient networking, all while keeping the system stable.

Where is it used?

  • Network security: tools like Cilium use eBPF to enforce firewalls and micro-segmentation directly in the kernel.
  • Performance monitoring: observability platforms (e.g., bpftrace, Falco) attach eBPF programs to trace system calls and latency.
  • Load balancing: projects such as Katran implement high-speed load balancers that run inside the kernel.
  • Container orchestration: Kubernetes networking plugins leverage eBPF for fast, policy-driven packet handling.

Good things about it

  • Runs at kernel speed with minimal overhead.
  • Safe: the verifier prevents crashes or security breaches.
  • Flexible: can be attached to many hook points (network, tracepoints, syscalls).
  • No kernel recompilation or reboot needed to add new functionality.
  • Open-source and supported by the mainline Linux kernel.

Not-so-good things

  • Writing eBPF programs requires knowledge of C (or restricted languages) and kernel internals, which has a steep learning curve.
  • Limited resources (memory, instruction count) restrict how complex a program can be.
  • Debugging can be tricky because the code runs inside the kernel, not user space.
  • Compatibility issues may arise on older kernels that lack the latest eBPF features.