Runtime security on Linux has historically forced an ugly choice: intrusive instrumentation with heavy overhead, or kernel modules with the power to crash the systems they protect. eBPF dissolved that trade-off by letting verified, sandboxed programs run inside the kernel itself [1], attached to system calls, tracepoints, and security hooks. The result is a generation of detection tools with kernel-level visibility and production-acceptable overhead. This roundup reviews what the tooling ecosystem and the surrounding research have established about eBPF-based defense—what it does well, how it compares to what came before, and where its hard limits sit.
From Packet Filter to Kernel-Wide Sensor
BPF began life as the Berkeley Packet Filter, a small in-kernel virtual machine for deciding which packets tcpdump should capture. Extended BPF generalized the idea into a programmable attachment mechanism for much of the kernel: programs can hook system call entry and exit, scheduler and networking tracepoints, arbitrary kernel functions via kprobes, and—critically for security—the Linux Security Module (LSM) hooks through BPF LSM [2]. Two pieces of infrastructure made this practical at fleet scale. The in-kernel verifier statically checks every program before it loads [3], proving memory safety and bounded execution so a buggy sensor cannot hang or corrupt the kernel. And BTF type information with CO-RE ('compile once, run everywhere') lets a single compiled program adapt to different kernel versions, removing the per-kernel build matrix that made earlier kernel instrumentation operationally painful.
The Defender's Toolkit: Falco, Tetragon, and Tracee
Three open-source projects define the detection space. Falco, a CNCF graduated project originally from Sysdig [4], evaluates a rules language over a stream of system events—its classic architecture collects events in the kernel and evaluates rules in userspace, with a modern eBPF probe as the default driver. Cilium's Tetragon takes a different architectural bet: filtering and even enforcement happen in-kernel [5], so events are selected and reduced before they ever cross into userspace, and a policy can kill a process synchronously at the hook rather than reacting after the fact. Aqua's Tracee occupies similar ground with its own event and signature pipeline [6]. The architectural difference matters more than feature checklists: where filtering happens determines overhead under load and how much event loss you suffer when a noisy workload—or an attacker generating noise deliberately—floods the sensor. All three enrich events with container and Kubernetes context, which is what makes kernel events actionable in an orchestrated environment.
Why Kernel-Level Observability Beats ptrace
The pre-eBPF options for watching a process's system calls illustrate why this shift matters. ptrace—the mechanism behind strace and classic sandboxes—stops the traced process at every syscall entry and exit and context-switches to the tracer, an approach whose overhead is widely acknowledged to be prohibitive for production monitoring of busy workloads; it also requires attaching to specific processes and is trivially detectable by the target. Auditd improves on this but can still generate crushing log volume under syscall-heavy load. eBPF inverts the model: the observation logic runs inside the kernel at the hook point, pays a small in-context cost per event, and can filter, aggregate, and summarize before anything is copied to userspace. No target cooperation is required, nothing needs to be attached per-process, and cgroup and namespace awareness gives per-container attribution essentially for free. The practical consequence is that always-on syscall-level visibility across a production fleet went from unaffordable to routine.
Catching Container Escapes at the Kernel Boundary
Container escapes are a natural fit for kernel-level detection because the kernel is precisely where an escape must act. Whether the vector is a privileged or misconfigured container, a mounted container runtime socket, or an exploited kernel bug, the post-exploitation behavior tends to touch a recognizable set of kernel-visible signals: namespace transitions such as unexpected setns usage, exercise of powerful capabilities like CAP_SYS_ADMIN, writes to sensitive host paths such as core_pattern or release_agent, and processes whose namespace context suddenly stops matching their container of origin. Because these are behavioral signals rather than exploit signatures, an eBPF sensor can flag the escape pattern even when the underlying CVE is unknown. One caveat the research community has documented carefully: sensors that read syscall arguments from user memory at syscall entry are exposed to time-of-check-to-time-of-use games, where a racing thread rewrites the argument between inspection and kernel use. Hooking LSM checkpoints or tracepoints past the point of no return, as newer tooling increasingly does, closes much of that gap.
Know the Limits: The Verifier and the Blind Spots
eBPF's guarantees come from restrictions, and defenders should know them. The verifier enforces memory safety and bounded execution by constraining program size, loop structure, and complexity—which also caps how much detection logic can live in-kernel, pushing sophisticated correlation to userspace where events can be dropped under pressure. Ring buffers between kernel and userspace are finite: a workload that generates enough events, maliciously or otherwise, can cause loss, so monitoring your sensor's drop counters is part of operating it honestly. eBPF is also not a one-way street: offensive research has demonstrated eBPF-based rootkits and data-exfiltration tooling, which is why unprivileged BPF is disabled by default on mainstream distributions and why loading programs should be gated by capabilities, lockdown policy, and audit of who can call bpf() at all. Finally, visibility is not enforcement—observing a malicious action after it happens is not the same as preventing it, and only some tools and hook types support synchronous blocking. Treat eBPF detection as one strong layer in a stack that still includes seccomp profiles, LSM policy, and image and configuration hardening.
Conclusion
The research picture is unusually clear for such a young field: eBPF gives defenders kernel-fidelity telemetry at production-tolerable cost, and tools like Falco and Tetragon have turned that capability into deployable detection and, increasingly, enforcement. It is equally clear that eBPF is infrastructure, not a strategy—verifier limits bound in-kernel logic, event loss is a real failure mode, and the mechanism itself must be locked down because attackers read the same documentation. Teams that pair eBPF-based runtime detection with least-privilege container configuration and policy-based prevention get the durable win: visibility into the layer where escapes and post-exploitation actually happen, without betting the fleet on any single control.
References
- [1]What is eBPF? — eBPF.io (eBPF Foundation)
- [2]LSM BPF Programs — Linux Kernel Documentation
- [3]eBPF verifier — Linux Kernel Documentation
- [4]Cloud Native Computing Foundation Announces Falco Graduation — CNCF
- [5]Tetragon: eBPF-based Security Observability and Runtime Enforcement — Cilium / Tetragon Project
- [6]Tracee: Runtime Security and Observability Tool — Aqua Security