CONCEPT Cited by 2 sources
In-kernel filtering¶
In-kernel filtering is the architectural move of evaluating per-event match/drop decisions inside the kernel (via systems/ebpf), before events are handed off to user-space consumers. The goal: keep the ring buffer from becoming the bottleneck when kernel-event production outpaces user-space processing.
Shape:
- A control plane in user-space compiles rules/policies into eBPF maps (hash for approvers, LRU for discarders, etc.).
- eBPF programs on the kernel hook path consult those maps per event, with O(1) lookup.
- Only events that survive the kernel filter cross the ring buffer.
The kernel is constrained (eBPF verifier: no unbounded loops, bounded instruction count, tighter on older kernels) — so the split is intentional:
- Kernel side: cheap, stateless, O(1) per event. Answers "could this event possibly matter?"
- User-space side: full rule engine with correlations, state, cross-event logic. Answers "does it actually matter, and what do we do about it?"
This is a specialization of patterns/two-stage-evaluation where the fast path lives below the user/kernel boundary.
Why it wins at scale¶
Without in-kernel filtering, the ring buffer carries every candidate event. At Datadog FIM scale (~5K security-relevant syscalls/sec on sensitive hosts, ~10B events/min fleet-wide), the user-space Agent can't keep up — ring-buffer overrun means dropped events = security blind spots.
With in-kernel filtering, ~94% of events are dropped before emit — the ring buffer carries only plausible matches, and the Agent has CPU headroom for the richer second-stage evaluation.
Relationship to edge filtering¶
concepts/edge-filtering is the network-level sibling: drop noise at the producer (host) rather than the consumer (backend). In-kernel filtering is edge filtering pushed one layer further down — drop noise at the producer inside the producer, before it ever reaches the user-space edge agent. The two compose: kernel → Agent → backend, each stage cuts the volume.
Constraints¶
- eBPF verifier limits — especially on older kernels, the complexity of per-event logic that fits in-kernel is small. Sophisticated evaluation (wildcards, cross-field correlations, stateful patterns) typically must stay in user-space.
- Correctness of the filter is a policy invariant. A buggy filter that drops a would-match event is an observability / security gap — the filter has to be provably conservative against the active ruleset (see patterns/approver-discarder-filter for one design).
- Map memory is bounded — LRU eviction for dynamic filter sets introduces a tradeoff between coverage and RAM.
Seen in¶
- sources/2025-11-18-datadog-ebpf-fim-filtering — Datadog's File Integrity Monitoring uses eBPF maps (approvers + discarders) to filter ~94% of file-event syscalls in-kernel, reducing a ~10B events/min stream to ~1M events/min forwarded to user-space and eventually to the backend.
- sources/2026-04-16-github-ebpf-deployment-safety — GitHub
uses a cGroup-scoped variant:
CGROUP_SKB+CGROUP_SOCK_ADDRprograms drop/rewrite egress traffic from a dedicated deploy-script cGroup based on policy compiled from a userspace DNS proxy's blocklist. Same architecture (control plane compiles policy into maps; kernel-resident programs enforce per-event) but the filter scope is a process set, not a syscall class.