Overview
eBPF — Extended Berkeley Packet Filter
eBPF is a technology that allows sandboxed programs to run inside the Linux kernel without changing kernel source code or loading kernel modules. Originally designed for packet filtering, it has evolved into a general-purpose in-kernel virtual machine used for networking, security, and observability.
Why eBPF Matters for Observability
Traditional observability requires instrumenting application code — adding SDKs, sidecars, or agents. eBPF changes this by collecting telemetry directly from the kernel:
- No code changes — works with any language, any framework
- Negligible overhead — programs run in kernel space with JIT compilation
- Deep visibility — access to syscalls, network packets, file I/O, CPU scheduling
- Production-safe — the eBPF verifier guarantees programs cannot crash the kernel
How eBPF Works
┌──────────────────────────────────────────────────────────┐
│ User Space │
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ eBPF Program │ │ User-space │ │
│ │ (C, Rust) │ │ Agent │◄── reads maps, │
│ └──────┬───────┘ └──────▲───────┘ perf buffers │
│ │ compile │ │
│ ▼ │ │
│ ┌──────────────┐ │ │
│ │ BPF Bytecode│ │ │
│ └──────┬───────┘ │ │
│ │ load │ │
├─────────┼────────────────────┼───────────────────────────┤
│ ▼ │ Kernel Space │
│ ┌──────────────┐ ┌──────┴───────┐ │
│ │ Verifier │───►│ JIT Compiler│ │
│ │ (safety │ │ (native │ │
│ │ checks) │ │ machine │ │
│ └──────────────┘ │ code) │ │
│ └──────┬───────┘ │
│ ▼ │
│ ┌───────────────────────────────────────────────────┐ │
│ │ Attach Points (hooks) │ │
│ │ │ │
│ │ • kprobes — kernel function entry/exit │ │
│ │ • uprobes — user-space function entry/exit │ │
│ │ • tracepoints — static kernel instrumentation │ │
│ │ • perf events — CPU sampling, HW counters │ │
│ │ • XDP — network packet processing │ │
│ │ • TC — traffic control hooks │ │
│ │ • cgroup — resource control hooks │ │
│ └───────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌───────────────────────────────────────────────────┐ │
│ │ Data Structures │ │
│ │ │ │
│ │ • BPF Maps — key-value stores (hash, array) │ │
│ │ • Ring Buffers — efficient event streaming │ │
│ │ • Perf Buffers — per-CPU event output │ │
│ └───────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────┘
Lifecycle of an eBPF Program
- Write — eBPF program is written in C or Rust (restricted subset)
- Compile — compiled to BPF bytecode (using LLVM/Clang)
- Verify — the kernel verifier checks safety: no infinite loops, no invalid memory access, bounded execution
- JIT compile — bytecode is compiled to native machine code for near-native performance
- Attach — program is attached to a hook point (syscall, function, tracepoint)
- Execute — runs every time the hook fires; writes results to BPF maps or ring buffers
- Read — user-space agent reads collected data for processing and export
Probe Types
| Probe Type | What It Hooks Into | Use Cases |
|---|---|---|
| kprobes / kretprobes | Any kernel function entry/return | Syscall tracing, I/O monitoring, network events |
| uprobes / uretprobes | Any user-space function entry/return | Application-level tracing, TLS interception |
| tracepoints | Static kernel instrumentation points | Scheduler events, block I/O, memory allocation |
| perf events | CPU performance counters, sampling | CPU profiling, cache miss analysis |
| XDP | Network device driver (before stack) | Packet filtering, DDoS mitigation, load balancing |
| TC (Traffic Control) | Network stack (ingress/egress) | Traffic shaping, policy enforcement |
| LSM hooks | Linux Security Module hooks | Security policy enforcement |
| fentry / fexit | Kernel function (newer, faster than kprobes) | Low-overhead kernel tracing |
The Verifier — Safety Guarantees
The eBPF verifier is what makes it safe to run arbitrary programs in the kernel:
- Bounded execution — no infinite loops, programs must terminate
- Memory safety — all memory accesses are bounds-checked
- Valid helpers only — programs can only call approved kernel helper functions
- Stack size limit — 512 bytes max stack per program
- Program size — limited instruction count (1M instructions since Linux 5.2)
If a program fails verification, it is rejected before loading — it never runs.
Adoption
eBPF has moved from a niche Linux networking feature to a foundational technology adopted across the industry:
| Year | Milestone |
|---|---|
| 2014 | Alexei Starovoitov introduces extended BPF in Linux 3.18 (evolved from classic BPF, 1992) |
| 2016 | Netflix begins using eBPF for performance analysis (Brendan Gregg’s BCC toolkit) |
| 2017 | Facebook deploys Katran (eBPF-based L4 load balancer) handling all external traffic |
| 2018 | Cilium 1.0 released — first eBPF-based Kubernetes CNI; Cloudflare adopts eBPF for DDoS mitigation |
| 2019 | Google adopts eBPF in GKE Dataplane V2 (Cilium-based) |
| 2020 | Microsoft adds eBPF support to Windows Android integrates eBPF for network monitoring |
| 2021 | eBPF Foundation established (Linux Foundation) — founding members: Google, Meta, Microsoft, Netflix, Isovalent |
| 2022 | Cilium becomes a CNCF Graduated project; Grafana Phlare/Pyroscope uses eBPF for continuous profiling |
| 2023 | Isovalent (Cilium creators) acquired by Cisco Istio introduces Ambient Mesh — replacing sidecar proxies with eBPF-based L4 traffic capture eBPF becomes the default dataplane for major cloud providers |
| 2024 | Tetragon (eBPF security observability) reaches CNCF Sandbox eBPF used in production by most large-scale cloud platforms |
Who Uses It in Production
| Company | Use Case |
|---|---|
| Meta (Facebook) | Katran (load balancing), network monitoring, security enforcement — all external traffic goes through eBPF |
| GKE Dataplane V2 (Cilium), kernel-level security monitoring | |
| Netflix | Performance analysis, FlameScope, network tracing at scale |
| Cloudflare | DDoS mitigation, packet filtering — processes millions of packets/sec per server |
| Microsoft | Azure CNI (Cilium), Windows eBPF runtime |
| Network observability and infrastructure monitoring | |
| Alibaba | Cloud infrastructure networking and security |
| Grafana Labs | Alloy eBPF-based profiling (Pyroscope), auto-instrumentation without code changes |
| Datadog | eBPF-based network performance monitoring and security |
eBPF has essentially become the standard mechanism for kernel-level observability and networking in modern Linux infrastructure. If you’re running Kubernetes in a major cloud, you’re likely already running eBPF — even if you don’t know it.
Requirements
| Requirement | Minimum | Recommended |
|---|---|---|
| Linux kernel | 4.15+ | 5.8+ (full feature set) |
| BTF support | 5.2+ | Required for CO-RE (Compile Once, Run Everywhere) |
| Privileges | CAP_BPF + CAP_PERFMON |
Or run as privileged container |
| Architecture | x86_64, ARM64 | — |
⚠️ Kubernetes note: eBPF-based tools typically require privileged DaemonSets or specific capabilities (
SYS_ADMIN,BPF,PERFMON) on each node. This is a security consideration when deploying in production clusters.