eBPF Fundamentals

Sandboxed programs in the kernel — the programmable data plane

What Is eBPF?

eBPF (extended Berkeley Packet Filter) allows you to run sandboxed, event-driven programs inside the Linux kernel without modifying kernel source code or loading kernel modules. Think of it as a safe, programmable virtual machine embedded in the kernel that lets you hook into virtually any kernel event — networking, tracing, security — and run custom logic at native speed.

History: BPF to eBPF

1. BPF (1992)

   Berkeley Packet Filter — tcpdump's engine for filtering packets in the kernel

2. cBPF in Linux

   "Classic" BPF — limited instruction set, packet filtering only

3. eBPF (2014+)

   Extended BPF — general-purpose kernel programmability, 64-bit registers, maps, helpers

4. Modern eBPF

   CO-RE, BTF, bounded loops, BPF LSM, signed programs — production-grade

The Verifier: The Safety Guarantee

The eBPF verifier is a static analysis engine inside the kernel that inspects every eBPF program before it is loaded. If the verifier rejects a program, it never runs. This is the fundamental reason eBPF is safe to run in production kernels — it is mathematically impossible for a verified program to crash the kernel.

1. Write eBPF program

   C or Rust, compiled to eBPF bytecode

2. bpf() syscall

   Userspace requests program load

3. Verifier

   Static analysis — reject or accept

4. JIT Compile

   Bytecode -> native machine code

5. Attach to hook

   XDP, tc, kprobe, tracepoint...

JIT Compilation

After verification, eBPF bytecode is JIT-compiled to native machine instructions (x86_64, ARM64, etc.). This means eBPF programs run at near-native speed — there is no interpreter overhead in the hot path.

    $ sysctl net.core.bpf_jit_enable
    net.core.bpf_jit_enable = 1
    

    $ # Verify JIT is active for loaded programs:
    $ bpftool prog list
    6: xdp  name xdp_drop  tag abc123  gpl  jited 96B  loaded_at 2024-01-15
  

Hook Points: Where eBPF Programs Attach

eBPF programs are event-driven — they execute when a specific kernel event fires. The "hook point" determines when and where your code runs. This is what makes eBPF so versatile: the same technology powers networking, observability, and security.

Packet Path Through the Kernel (with eBPF Hook Points)

1. NIC (Hardware)

   Packet arrives

2. XDP

   Earliest hook. Before sk_buff allocation. Can DROP/PASS/TX/REDIRECT

3. tc ingress

   Traffic control layer. Has full sk_buff metadata. Can classify/redirect

4. Netfilter / iptables

   Traditional firewall chains (PREROUTING, INPUT, FORWARD...)

5. Socket Layer

   cgroup/socket eBPF hooks

6. Application

   Userspace receives data

eBPF Maps: Shared Data Structures

eBPF maps are kernel-resident data structures that serve as the primary communication channel between eBPF programs (kernel space) and userspace applications. Maps persist across program invocations — they're how you maintain state, share configuration, and export telemetry.

Map Lifecycle

1. Create — bpf(BPF_MAP_CREATE, ...) at program load time (usually via libbpf)
2. Pin — optionally pin to /sys/fs/bpf/ so maps persist beyond process lifetime
3. Use — eBPF programs call bpf_map_lookup_elem(), bpf_map_update_elem(), bpf_map_delete_elem()
4. Read from userspace — control plane reads/writes maps via bpf() syscall or bpftool map dump
5. Cleanup — maps are reference-counted; destroyed when no programs or file descriptors reference them

Helper Functions

eBPF programs cannot call arbitrary kernel functions. Instead, the kernel exposes a curated set of helper functions that eBPF programs can invoke. The verifier ensures only valid helpers are called for the given program type.

// Lookup a value by key
void *bpf_map_lookup_elem(&map, &key);

// Insert or update
int bpf_map_update_elem(&map, &key, &val, flags);

// Delete an entry
int bpf_map_delete_elem(&map, &key);

// Redirect packet to another interface
int bpf_redirect(ifindex, flags);

// Modify packet bytes
int bpf_skb_store_bytes(skb, off, &data, len, flags);

// Adjust packet headroom
int bpf_xdp_adjust_head(xdp_md, delta);

// Get current PID and TID
u64 bpf_get_current_pid_tgid();

// Safely read kernel memory
int bpf_probe_read(&dst, size, &src);

// Get current timestamp (ns)
u64 bpf_ktime_get_ns();

// Send event to ring buffer
int bpf_ringbuf_output(&ringbuf, &data, size, flags);

// Print to trace pipe (debug only)
int bpf_trace_printk(fmt, fmt_size, ...);

// Get current cgroup id
u64 bpf_get_current_cgroup_id();

eBPF Program Types

Each eBPF program has a type that determines which hook points it can attach to, which helpers it can call, and what context (input data) it receives. The verifier enforces these constraints.

eBPF Architecture Summary

    $ # List all loaded eBPF programs
    $ bpftool prog list
    6: xdp  name xdp_firewall  tag a1b2c3d4  gpl  jited 208B
    12: sched_cls  name tc_policy  tag e5f6a7b8  gpl  jited 384B
    

    $ # Dump a map's contents
    $ bpftool map dump id 4
    key: 0a 00 01 01  value: 00 00 00 42
    key: 0a 00 01 02  value: 00 00 01 a3
    

    $ # One-liner: count syscalls by process
    $ bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'
    Attaching 1 probe...
    @[kubelet]: 4521
    @[containerd]: 3102
    @[cilium-agent]: 1847