Explain how the Linux Kernel eBPF architecture works from start to finish: `bpf()` syscall loading, the Static Verifier (`data_end` pointer tracking &.

A strong answer

Look at how eBPF (Extended Berkeley Packet Filter) turns the Linux kernel into a safe, programmable virtual machine: (1) The eBPF Static Verifier & JIT Compiler: When user space loads an eBPF bytecode program via the bpf(BPF_PROG_LOAD) syscall, the kernel's eBPF Verifier performs an exhaustive static control-flow and abstract-interpretation analysis: it rejects the program unless every code path is guaranteed to terminate (bounded loops / DAG, max 1 million instructions verified), never dereferences an unchecked NULL or out-of-bounds pointer, and never leaks kernel locks! Once verified, the kernel JIT-compiles the eBPF bytecode into native x86_64 or ARM64 machine instructions that execute at native kernel speed (~10–50 ns) and share state with user space via lock-free/per-CPU eBPF Maps! (2) XDP (eXpress Data Path) vs iptables: In Linux networking, iptables only runs after the kernel allocates an sk_buff metadata struct (~256 bytes), parses L2/L3 headers, and enters the Netfilter stack—costing so much CPU per packet that 15M packets/sec melts the CPU before iptables -j DROP even runs! XDP hooks directly inside the NIC device driver's DMA receive ring buffer before sk_buff allocation! Returning XDP_DROP drops a malicious packet in ~25 nanoseconds at 10–20+ million packets/sec per CPU core! (3) Kernel Runtime Security (Cilium Tetragon / BPF LSM / kprobes): User-space agents (LD_PRELOAD or sidecars) can be bypassed by static binaries invoking raw syscall assembly instructions. By attaching eBPF programs to Kernel tracepoints, kprobes, and BPF LSM (Linux Security Module) hooks (e.g., security_bprm_check, security_file_open), Cilium Tetragon inspects process task_struct namespace/cgroup identity + file descriptors inside the kernel and can synchronously send SIGKILL (override_return / send_signal) to an attacker process before the unauthorized execve or read syscall even completes!

No eBPF program can execute in the Linux kernel unless the in-kernel eBPF Verifier statically proves across all possible branch paths that: (1) the instruction count is strictly bounded (guaranteed termination, zero infinite loops), and (2) every pointer dereference is preceded by an explicit non-null and bounds check (ptr + offset <= data_end). The eBPF Verifier explores the Directed Acyclic Graph (and bounded loop iterations) of all instructions, tracking register type and [min_value, max_value] range state. Any instruction that accesses [reg + off] where reg.type != PTR or reg.max_offset + off > packet.data_end fails verification at bpf(BPF_PROG_LOAD) time with EACCES, preventing kernel panics or arbitrary kernel memory reads.

Dropping DDoS packets at the NIC driver via XDP_DROP handles ~20M packets/sec per core (~5x–10x higher than iptables PREROUTING drops because zero sk_buff kernel structs are allocated). In production systems (Cloudflare's L4Drop / Katran (Meta's eBPF XDP L4 load balancer), Cilium & Hubble (eBPF CNI + observability), Cilium Tetragon & Falco (eBPF runtime security), and bpftrace / bcc.), engineers monitor these exact trade-offs to keep p99 latency predictable and prevent resource exhaustion under peak load.

What the interviewer is listening for

• Traces how Linux Kernel eBPF (Verifier, JIT, eBPF Maps), XDP (XDP_DROP / XDP_REDIRECT), and Tetragon Runtime Security (LSM / kprobes) operates in memory step by step rather than giving a vague textbook definition.
• States the core correctness invariant and explains why edge cases do not violate it.
• Quantifies time, space, and hardware costs (iptables PREROUTING -j DROP, eBPF XDP_DROP (NIC Driver Hook)) with concrete numbers.
• Identifies real-world failure modes (Using a single shared BPF_MAP_TYPE_HASH counter updated with __sync_fetch_and_add on every network packet across a 64-core server) and explains how production systems mitigate them.

Common mistakes

• Treating Linux Kernel eBPF (Verifier, JIT, eBPF Maps), XDP (XDP_DROP / XDP_REDIRECT), and Tetragon Runtime Security (LSM / kprobes) as a black box without explaining the underlying memory or state transitions.
• Ignoring worst-case tail latency or memory overhead (Attaching an eBPF uprobe or kprobe to an ultra-high-frequency inner function like malloc() or read() in production without filtering by cgroup/PID in kernel space first).
• Applying the pattern without enforcing explicit capacity bounds or validation (Compiling eBPF programs at runtime inside production containers by mounting /lib/modules and installing clang/llvm (500 MB) in every pod).