eBPF

eBPF enables dynamic, in-kernel programmability without the need to write, compile, and load traditional kernel modules. Programs are written in a restricted C-like language, compiled to eBPF bytecode, and just-in-time (JIT) compiled to native machine code for near-native execution speed. This allows for runtime modification of kernel behavior—such as adding new packet filters, tracing functions, or security policies—with a drastically reduced risk of system crashes or security vulnerabilities compared to kernel modules.

The core security mechanism of eBPF is its in-kernel verifier. Before any eBPF program is loaded, the verifier performs a series of safety checks, including:

• Ensuring the program terminates and does not contain loops without a bounded iteration count (except for loops with statically known trip counts).
• Validating all memory accesses are safe and within bounds (e.g., checking pointers before dereferencing).
• Proving the program's control flow graph is a Directed Acyclic Graph (DAG) or has bounded loops.
• Limiting the total number of instructions (currently 1 million for kernel 5.2+). This sandboxing prevents buggy or malicious programs from crashing the kernel or compromising system stability.

eBPF programs are not continuously running processes. They are event-driven and attached to specific kernel hooks or events. When the hooked event occurs, the kernel executes the attached eBPF program. Common attachment points include:

• kprobes/uprobes: For tracing kernel or user-space function entries/exits.
• Tracepoints: For static kernel trace points.
• Network Events: Such as the arrival of a packet at a specific network interface (XDP), a socket operation, or traffic control (TC) ingress/egress.
• System Calls: Via seccomp or syscall tracepoints.
• Perf Events: For hardware and software performance counters. This model makes eBPF highly efficient, as code only runs in direct response to the events being monitored or manipulated.

eBPF programs use eBPF maps as generic data structures to store and share state between the eBPF program (running in kernel space) and user-space applications, or between multiple eBPF programs. Maps support various data types like hash tables, arrays, LRU caches, and ring buffers. This is crucial for building complex applications:

• A network firewall can store dynamic allow/deny rules in a hash map.
• A performance monitoring tool can aggregate metrics in an array, which a user-space daemon reads to generate reports.
• Programs can use maps as a communication channel, passing data or triggering actions across the kernel/user-space boundary.

eBPF's flexibility powers three primary domains:

• Observability: Provides deep, low-overhead system introspection without instrumenting application code. Tools like BPF Compiler Collection (BCC) and bpftrace use eBPF to trace file I/O, scheduler latency, block device operations, and custom application functions with minimal performance impact (<1% overhead).
• Networking: Enables high-performance, programmable networking in the kernel. eXpress Data Path (XDP) allows packet processing at the earliest possible point in the driver, enabling DDoS mitigation, load balancing, and packet forwarding at line rate (often >10 million packets per second). Cilium uses eBPF for Kubernetes networking, security, and load balancing.
• Security: Enforces runtime security policies. Projects like Falco use eBPF to detect anomalous application behavior by monitoring system calls. It can also implement seccomp-like filtering with more granular, stateful policies.

A mature toolchain supports eBPF development and deployment:

• Compiler: The LLVM compiler suite includes an eBPF backend, allowing programs to be compiled from restricted C/C++.
• Library: libbpf is the preferred user-space library for loading eBPF programs and managing maps, succeeding the older BCC framework for many production use cases due to its simplicity and portability.
• Kernel Helper Functions: eBPF programs interact with the kernel via a stable set of helper functions (e.g., bpf_map_lookup_elem, bpf_trace_printk, bpf_skb_store_bytes). These are the sanctioned API for accessing kernel resources, ensuring safety and forward compatibility.
• Introspection: The kernel exposes eBPF program and map metadata via a bpffs (BPF filesystem), enabling tools to discover and manage running eBPF assets.

A hardware-isolated, trusted execution environment within a processor that protects sensitive code and data from the rest of the system, including the operating system and hypervisor. Unlike eBPF's kernel-level sandboxing, a Secure Enclave provides a hardware-enforced boundary.

• Key Differentiator: Hardware-based isolation vs. eBPF's software-based verifier and runtime.
• Primary Use: Protecting cryptographic keys and biometric data (e.g., Apple's Secure Enclave).
• Contrast with eBPF: eBPF extends kernel functionality; a Secure Enclave isolates code from the kernel itself.

A secure area of a main processor that ensures code and data loaded inside are protected with respect to confidentiality and integrity. TEE is the overarching category for technologies like Intel SGX, AMD SEV, and ARM TrustZone.

• Architectural Role: Provides a secure 'world' for trusted applications.
• Relation to eBPF: eBPF can be used to monitor system calls and network activity to or from a TEE, enhancing overall system observability and security posture.
• Deployment Model: Often used for DRM, secure payments, and confidential computing, whereas eBPF is used for system introspection and networking.

A security mechanism for isolating running programs by restricting an application's access to system resources like the filesystem, network, and other processes. eBPF is a form of in-kernel sandboxing.

• eBPF's Implementation: Uses a verifier to statically analyze programs for safety (no loops, bounded complexity, valid memory accesses) before they are JIT-compiled and executed in the kernel.
• Broader Context: Other sandboxing techniques include seccomp (system call filtering), namespaces, and cgroups (resource limits).
• Key Difference: Traditional sandboxes isolate user-space processes; eBPF sandboxes kernel-level code execution.

Secure computing mode is a Linux kernel security feature that restricts the system calls a process is permitted to make. It is a fundamental sandboxing tool often used in conjunction with eBPF.

• Mechanism: A process can enter a mode where it can only call a predefined, limited set of system calls (e.g., read, write, exit).
• Synergy with eBPF: While seccomp filters which syscalls can be made, eBPF programs (via BPF_PROG_TYPE_TRACEPOINT or BPF_PROG_TYPE_TRACING) can be attached to inspect the arguments and behavior of allowed syscalls for deeper security policy enforcement.
• Common Use: Heavily used in container runtimes (like Docker) to limit the attack surface of containerized applications.

A modular system interface for WebAssembly that provides a sandboxed, capability-based set of APIs for securely accessing operating system features. WASI and eBPF represent different approaches to safe, portable extension points.

• Capability-Based Security: WASI programs must be explicitly granted 'capabilities' (e.g., access to a specific directory).
• Comparison to eBPF: eBPF is deeply integrated into the Linux kernel for performance-critical observability and networking. WASI is designed as a portable, user-space runtime for broader application sandboxing, potentially including AI agent tool execution.
• Emerging Overlap: Projects like wasm-bpf explore using WASI to load and manage eBPF programs, combining portability with kernel-level capabilities.

A framework in the Linux kernel that allows security models like SELinux, AppArmor, and Smack to be implemented as loadable kernel modules to enforce mandatory access control (MAC) policies. eBPF has expanded this model.

• Traditional LSM: Uses hooks for coarse-grained policy decisions (e.g., 'can process X read file Y?').
• eBPF LSM Integration: The BPF_PROG_TYPE_LSM program type allows attaching eBPF programs to LSM hooks, enabling dynamic, programmable security policies without rebooting the kernel.
• Use Case: An eBPF LSM program can implement custom rules for auditing file accesses from AI agent processes or blocking specific network connections in real-time based on a centralized policy.