eBPF
eBPF (extended Berkeley Packet Filter) runs sandboxed programs inside the Linux kernel to observe system calls, process behaviour, and network activity with near-zero overhead. Learn how it works and why it matters for security.
What is eBPF?
eBPF, short for extended Berkeley Packet Filter, is a Linux kernel technology that allows sandboxed programs to run directly inside the kernel. These programs can observe system calls, process activity, file access, and network connections in real time, without modifying the kernel source code, loading kernel modules, or incurring significant performance overhead.
That combination: kernel-level visibility, no kernel modifications, minimal overhead, is what makes eBPF architecturally significant for both observability and security.
How eBPF works
The Linux kernel is where everything actually happens. System calls, process scheduling, file I/O, network packet handling: the kernel mediates all of it. An eBPF program attached to a kernel hook can observe these events exactly as they occur, at their source.
The original BPF (Berkeley Packet Filter) was designed for network packet filtering in the early 1990s. It let user-space programs define filters that the kernel would apply to network traffic, avoiding unnecessary copy operations to user space. Fast, efficient, purpose-built for packet selection.
eBPF extended that model far beyond network filtering. An eBPF program can attach to any kernel hook: system call entry and exit points, tracepoints, kprobes (dynamic kernel instrumentation points), uprobes (user-space probes), network sockets, and more. The program runs in a sandboxed environment inside the kernel, verified by the eBPF verifier before loading to ensure it can't crash the kernel, enter infinite loops, or access arbitrary memory.
That sandbox is critical. Kernel modules have historically been dangerous precisely because a bug in a module can crash the entire system. eBPF programs are verified before execution. They can observe and filter, but they run in a controlled environment that the kernel verifier guarantees is safe.
eBPF vs traditional monitoring approaches
Dimension | Traditional Agent/Log-Based | eBPF |
|---|---|---|
Observation point | User space, above kernel | Inside kernel, at event origin |
Kernel modification | Often requires modules | No kernel modification needed |
Coverage | What generates logs | All kernel events, including those that don't log |
Performance overhead | Moderate to high | Near-zero |
Tamper resistance | Logs can be manipulated | Kernel-level events observed before logging |
Bypass risk | User-space agents can be circumvented | Kernel-level, harder to evade |
The traditional approach observes events after they've been recorded: reading log files, parsing audit logs, consuming kernel module outputs. eBPF programs observe events as they happen, inside the kernel, before they're written anywhere.
That distinction matters for security specifically. An attacker who manipulates log files hasn't removed their activity from eBPF telemetry, because eBPF observed the system calls directly. A process that performs file access without generating a log entry still generates eBPF events. Coverage is at the kernel level, not at the logging level.
Why eBPF matters for endpoint security
Endpoints are where data is created, staged, and exfiltrated. An employee downloads a database export, stages it in a local folder, compresses it, and uploads it to a cloud storage service. Each step happens on the endpoint. Each step involves specific processes making specific system calls: file read, file write, compression utility invocation, network socket connection to a specific destination IP, bytes transferred.
eBPF can capture the entire chain at the kernel level: which process accessed which file, what network connection it opened, how many bytes it transferred, to which destination, with what timing. That's the process-to-file-to-destination chain that cloud-side monitoring cannot reconstruct after the fact.
Cloud monitoring sees that a file appeared in a cloud storage bucket. It doesn't see that it was compressed by a specific utility run by a specific user at a specific time from a file that originated in a specific directory. eBPF telemetry from the endpoint sees exactly that.
That's the "endpoint ground truth" concept in data security: the kernel-level factual record that ties data movement to specific processes, specific identities, and specific destinations with verifiable, non-inferential evidence.
A single large file upload to cloud storage at 2am is visible in cloud logs. A process that accesses a sensitive customer database, writes the results to a compressed archive, and uploads that archive to cloud storage at 2am from an employee laptop: that sequence is visible in eBPF telemetry. The difference is attribution and intent context. One is an event. The other is evidence.
eBPF in practice: what it can observe
An eBPF program attached to the appropriate kernel hooks can observe the following categories of events, among others.
System calls: Every file open, read, write, and close. Every process created, every executable invoked. Every network socket created, connected, and closed. System calls are the interface between user space and the kernel, and eBPF can observe all of them.
Network events: Packet-level visibility at ingress and egress. Connection establishment and teardown with associated process context. Byte counts per connection, per process.
File system events: Which process accessed which file, with what permissions, at what time. File creation, deletion, modification, and rename operations. Directory traversal.
Process behaviour: Which processes are running, what arguments they were invoked with, what files and network resources they're accessing, how they're using memory.
That breadth of coverage, combined with the ability to correlate events across categories — this process opened this file, then opened this network connection, and transferred this many bytes — is what makes eBPF telemetry qualitatively different from log-based monitoring.
eBPF and data security
eBPF's relevance to data security is specific and practical. Data loss doesn't happen in cloud dashboards. It happens on endpoints, in the process-level sequences that precede the point where cloud monitoring can see anything.
A data exfiltration sequence typically involves local file access, staging, transformation, and outbound transfer. All four happen on the endpoint, below the visibility horizon of tools that only observe network egress or cloud-side events. eBPF-based telemetry observes all four, attributing them to the specific process and identity responsible, with byte-level precision on what moved and where.
That telemetry feeds the "egress truth" question that security teams and regulators ask after an incident: what data actually left, how much of it, through which channel, attributable to which identity? eBPF answers that question with kernel-level evidence, not log-based inference.