eBPF

extended Berkeley Packet Filter — safe, sandboxed programs that run inside the Linux kernel at hooks (network ingress/egress, syscalls, tracepoints) without writing kernel modules. The capability split that matters: observe (per-packet/per-syscall telemetry at native speed) and enforce (drop, redirect, or allow traffic/executions before they complete). XDP (eXpress Data Path) is the earliest-network hook — packet decisions at the driver, before the stack.

Where the vault already touches it

• Aegis-BPF (OSS) — the enforcement end: eBPF-LSM hooks returning -EPERM on file/network ops before syscalls complete; positioning paper against detect-first Falco/Tracee and general-purpose Tetragon; IMA-backed exec identity, cgroup-scoped policy.
• ttl (OSS) / picosnitch (OSS) — the observability end: per-hop path stats, and per-executable traffic accounting (the question firewalls never answer), via clippings/docs-checkmk-com-latest-en-clustered-services-html.md’s cousin tools.
• nfSensei (clippings/nfsensei-org.md, see OSS routers) — eBPF/XDP as a swappable data plane for a router/firewall: “driver fast path” between nftables and userspace VPP/DPDK. The pluggable-dataplane thesis rides on eBPF.
• The Networking tools ladder ends here: path → process → name → service → enforcement, and eBPF is the substrate making each rung kernel-true.

The service-topology map family (eBPF discovery tools)

The “live service map from kernel truth” genre — agent per node → eBPF observes connect()/listen() → central backend aggregates → topology map, no application instrumentation:

• Infralens (OSS) (61★, Go, Apache-2.0) — the pure form: eBPF-driven live TCP/UDP service-map + traffic visualization for k8s and bare Linux (zero code changes/sidecars/SDKs; agent→backend HTTP; topology/API/WebSocket out). [Captured 2026-10-02 via K8sArchitect tweet.]
• coroot (OSS) (7.9k★) — the production APM built on the same move: eBPF traces connect()/listen() to construct the inter-service communication map, combined with metrics/logs/traces + AI root-cause analysis. (Its node-agent is the eBPF half.) [Captured 2026-09-30.]
• hubble (OSS) (4.4k★, Cilium) — the famous Kubernetes-native one: eBPF-based service dependency graph, flow visibility, network policy observability — but Cilium/K8s-centric, not plain Linux.
• netobserv-ebpf-agent (OSS) (211★, Red Hat/NetObserv, C) — the flows-focused component: ingress/egress flow collection from Linux hosts; the building block under OpenShift’s Network Observability rather than a standalone map product.

The spectrum: InfraLens = plain-Linux simplicity; Coroot = full APM on the same kernel truth; Hubble = K8s-native depth; NetObserv = component-level flows. All four answer the same question the Networking tools ladder ends with — what is actually talking to what — from inside the kernel, which is the only vantage point that can’t lie.

The pattern: everything the kernel knows (sockets, cgroups, exec, page faults) becomes queryable and decidable — without the kernel ever trusting the program (the verifier JIT-checks safety, loops, and memory access first). “The packets know; now the tools do too.”

Related: Networking tools · OSS routers (XDP data planes) · Performance engineering (kernel-level observation)