Understanding eBPF: Architecture Evolution, Tracing, and Container Security

1. Introduction

BPF (Berkeley Packet Filter) is a revolutionary technology that can attach safely and efficiently to various kernel events without recompiling the kernel or loading kernel modules, enabling monitoring, tracing, and observability of kernel activity.

2. From Packet Filtering to eBPF

2.1 eBPF Overview

After a 20‑year silence, Alexei Starovoitov rewrote BPF in 2013, creating "extended BPF" (eBPF) with ten 64‑bit registers, richer helper functions, and a JIT compiler that makes eBPF programs up to four times faster than classic BPF.

eBPF was merged into the Linux kernel in 2014, adding support for kprobes, uprobes, tracepoints, and perf events, and eventually becoming a top‑level kernel subsystem.

2.2 eBPF Architecture Evolution

eBPF works as a generic execution engine similar to a JVM: C code is compiled to BPF bytecode by LLVM, verified by the BPF verifier, and JIT‑compiled to native instructions. Programs are attached to kernel events such as tracepoints, kprobes, or network packets.

The architecture includes BPF maps for bidirectional data sharing between kernel and user space, supporting arrays, hash maps, and custom structures.

2.3 Comparison with Traditional Kernel Modules

Unlike kernel modules, BPF programs do not require kernel recompilation, are verified for safety, have a stable ABI, and can be upgraded atomically without disrupting running workloads.

Dimension

Linux Kernel Module

BPF

Safety

May cause kernel panic

Verified, safe execution

Compilation

Requires kernel rebuild

No kernel recompilation needed

Entry point

Direct kernel function calls

Helper functions via bpf_call

Upgrade

Unload/load, possible downtime

Atomic replacement, no downtime

3. BPF Tracing – The First Citizen of eBPF

BPF tracing (kprobes, uprobes, tracepoints, USDT, perf_events) provides a powerful, low‑overhead observability layer for Linux, allowing developers to attach small programs to a wide range of kernel and user‑space events.

4. Container Security Challenges

4.1 New Threats Introduced by Containers

Containers share the host kernel, have weaker isolation, and can be compromised through privileged containers, dangerous capabilities, mounted Docker sockets, or vulnerable runtimes (e.g., CVE‑2019‑5736).

4.2 Demonstration of Container Escape

Example commands that mount the Docker socket inside a container and then launch a second container with the host filesystem mounted, illustrating a typical escape path.

# docker run -itd --name with_docker_sock -v /var/run/docker.sock:/var/run/docker.sock dockertest
# docker exec -it <CONTAINER_ID> /bin/bash
# docker run -it -v /:/host dockertest /bin/bash

5. Container Security Control Engine

5.1 Detecting Anomalous Host and Container Activity

Key practices include running containers with minimal privileges, enforcing proper user permissions, and using eBPF‑based tracing to automatically generate access‑control policies that monitor file accesses, system calls, network activity, and suspicious processes.

5.2 Isolating Problematic Containers and Nodes

When a compromised container is detected, it can be isolated by setting the node to maintenance mode, applying network policies, scaling deployments to zero, or using side‑car WAFs for virtual patching.

5.3 Cloud‑Native Security Engine for Large‑Scale Platforms

Example architecture of a cloud provider’s security engine: a sidecar WAF protects pods, a daemonset‑deployed security agent collects events, and a central engine processes events, isolates faulty workloads, and forwards alerts to a SIEM.

6. References

Container Escape Overview

GKE Security using Falco, Pub/Sub, Cloud Functions | Sysdig

Kubernetes Security monitoring at scale with Sysdig Falco

Enterprise Falco Open‑Source Cloud‑Native Security Project | Sysdig

Container Escape: From CTF to CVE‑2019‑5736