Video summary

eBPF - Rethinking the Linux Kernel

Main summary

Key takeaways

Technology

Summary of Technological Concepts and Features (eBPF / Rethinking the Linux Kernel)

Why Web “Took Over” (Programmability)

Web evolved from mostly static pages (HTML) to programmable browser applications, enabled largely by JavaScript frameworks. This evolution required three “programmability essentials”:

  1. Safety / sandboxing for untrusted code
  2. Continuous delivery / seamless updates (no reinstall needed for every change)
  3. Performance close to native, often via JIT compilation (e.g., JavaScript JIT; also an earlier Java performance cost)

Linux Kernel Architecture (Quick 101)

The typical kernel layout is:

  • User space above the kernel
  • Hardware below the kernel
  • The kernel provides the abstractions that connect them

Common kernel abstractions include:

  • Drivers: hardware abstraction
  • System calls: the API boundary to user space; stable and backwards compatible
  • Middleware layers: e.g., VFS, scheduler, networking stack components, firewalling, etc.
  • Configuration / automation APIs, such as:
    • sysfs, procfs, netlink, and related interfaces
  • Kernel module loading/mounting and firewall configuration

Kernel Extension Options and Their Problems

Upstream changes

To add functionality upstream:

  • modify the kernel source
  • submit to the mailing list
  • convince maintainers and the community

This process can take years for adoption.

Kernel modules

Kernel modules are loadable plugins, but they face major challenges:

  • No stable internal kernel APIs for modules → modules may break each kernel release
  • Bugs in modules can crash the kernel, causing downtime and security risk
  • Operational overhead: module builds must match each kernel version

How eBPF Is Positioned as the Solution (“JavaScript-like” Programmability)

Instead of writing fragile kernel modules, eBPF runs small programs at defined hook points (e.g., system call entry/exit, networking events).

Example: Attaching to execve

An eBPF program can attach to execve to extract metadata (like binary name) and export it via eBPF maps for tracing/auditing.

eBPF Runtime, Verification, and Compilation

Loading as bytecode + verification

  • eBPF programs are loaded as eBPF bytecode
  • The verifier ensures safety by:
    • preventing kernel crashes from buggy programs
    • enforcing privilege checks
    • disallowing arbitrary kernel memory access / unsafe interactions

JIT compilation for near-native performance

After verification, eBPF uses a JIT compiler to translate portable bytecode into native CPU instructions, enabling near-native performance.

Seamless Live Updates

eBPF programs can be replaced atomically on a running system without breaking application behavior. For example: one packet might see the old program, while the next packet sees the new one.

Hook Flexibility

eBPF can attach to many kinds of events, including:

  • System calls
  • Networking stack events
  • Device-level events
  • Uprobes (user-space function instrumentation)
  • Tracepoints (stable function identifiers)
  • kprobes / fentry / fexit-style function instrumentation

Conceptually, programmable NIC support (hardware offload) was also mentioned.

State Management via eBPF Maps

  • eBPF programs are “instructions only”
  • Stateful data lives in maps, such as:
    • hash tables
    • ring buffers
    • LRU hash tables
    • stacks

Maps can persist across program replacements, enabling upgrades without losing metrics/state. Maps are accessible both to eBPF programs and to user space tooling/CLIs.

Stable Interaction via eBPF Helpers

Instead of calling unstable internal kernel functions, eBPF uses eBPF helpers that are maintained stable over time.

Benefits called out:

  • Portability across kernel versions
  • A shared set of supported operations (e.g., random/time, packet redirects, map operations)

Composability: Tail Calls and Function Calls

Rather than one monolithic program:

  • Tail calls: chain multiple programs at runtime (similar conceptually to “exec”)
    • limited and verifier-checked context passing
  • Function calls: mainly used to reduce program size or structure logic

Tooling Ecosystems and Learning Resources

BCC (BPF Compiler Collection)

  • Developers write Python controllers that:
    • load eBPF programs
    • read metrics/events from maps
  • Includes many pre-cooked tracing/profiling examples (e.g., TCP top-style tools)

bpftrace

  • Described as “DTrace for Linux”
  • Provides a higher-level tracing syntax
  • Example mentioned: attach to do_sys_open and print file-open arguments

Getting started / guides

  • A “getting started guide” for eBPF (language spec + how to write eBPF programs)
  • Slide links provided for bcc and bpftrace

eBPF Go Library and Building Custom Programs

  • Use clang to compile C-like code to eBPF bytecode
  • A Go controller library:
    • loads bytecode into the kernel
    • handles verifier/JIT
    • attaches to hooks

Other languages may work if they can output bpf bytecode via:

  • clang/LLVM backend, or
  • gcc backend support (as mentioned)

Product / Project: Cilium (eBPF-powered Networking)

Goal

Bring eBPF power to Kubernetes without requiring users to understand eBPF directly.

Operating Modes

  • Runs as a CNI plugin (and also in a daemonset-style deployment)
  • AWS EKS compatibility:
    • native AWS mode (compatible with the standard EKS CNI model)
    • chaining mode (runs on top of other CNIs like AWS CNI / GCP CNI)
    • Recommendation: use native mode for large deployments

Key Capabilities

Networking

  • overlays, native routing, multi-cluster routing
  • IPv4/IPv6 support
  • Service load balancing, replacing kube-proxy (“get rid of iptables” on Kubernetes nodes)
  • direct server return concept

Security

  • identity-based security (not IP/port firewall rules)
  • API-aware visibility (Layer 7 concepts)
  • DNS-aware policies (allow by domain patterns instead of hard-coded IPs)
  • transparent encryption / SSL data visibility mentioned

Observability (Hubble)

Recent “hubble” open source capabilities include:

  • service map (which services talk to which)
  • layer 7 visibility (e.g., HTTP calls)
  • metrics and flow logs (“flow logs” concept)

eBPF (Cilium) vs Service Meshes (Istio / Envoy)

  • Cilium is framed as fully transparent (no sidecar injection required) for observability
  • Observability overhead is described as lower because of eBPF
  • Cilium focuses on visibility + operational metrics, not the full mesh feature set (e.g., no circuit breaking/retries/load balancing like Istio)
  • Mesh coexistence:
    • Cilium can be used alongside service meshes
    • used as a “ground layer” by platform/security teams

Verification / Safety Q&A

A question was raised about whether two individually “safe” eBPF programs could become unsafe when combined. Response: unsafe combinations should not happen because tail calls/function chaining have limited, well-defined context, and the verifier validates safety across possible combinations of inputs/context during chaining.

Main Speakers / Sources (End of Video)

  • Thomas Groff Long-time Linux kernel developer; co-founded Isovalent and created Cilium

Mentioned maintainers / key sources

  • Daniel Borkmann (Facebook, co-maintainer of eBPF)
  • Alexis Daravoyta (Facebook)

Projects / tools referenced

  • eBPF framework/runtime concepts
  • BCC (iovisor.org)
  • bpftrace (iovisor.org)
  • Cilium and Hubble
  • Falco (Sysdig; CNCF project)

Original video