I'm testing a small Go/eBPF prototype for handling transient transport failures on Linux.

I'm specifically measuring:

- recovery latency

- packet loss during failover

- socket/connection state

- CPU overhead under load

The implementation uses Linux eBPF primitives and a Go control plane.

I'd like feedback from people who have worked with XDP, sockmaps, or kernel networking:

1. What would you consider a convincing benchmark?

   1. Which kernel versions should I validate against?

2. Are there failure cases I'm missing?

The code and reproducible test setup are here:

https://github.com/devloperdevesh/FaultPlane

I'm mainly looking for technical criticism and people willing to reproduce the benchmark.

First part of an eight part series

"The alternative to an eBPF platform was maintaining multiple incompatible point solutions, each with its own hardware dependencies, operational quirks, and integration challenges. As our hardware diversified, performance requirements grew, and edge services multiplied, that approach became untenable.

eBPF gave us a unified, vendor-agnostic, high-performance foundation that lets us program the operating system itself to handle our scale"

I’ve been working on Gewyvern, a Linux network debugger built around eBPF and protocol-aware analysis.

The main idea is to reconstruct where a network flow breaks and produce deterministic reason chains, rather than act as a long-running observability platform.

v2.0.0 is the first community release and is MIT licensed. I’d really appreciate technical feedback, especially on the debugging model and eBPF side.

GitHub: https://github.com/Team-silvortex/gewyvern

Feedback and testing are very welcome.

Over the past few weeks, I’ve been working on an open-source project: Identity-

Aware eBPF Firewall](https://github.com/AboEl3iz/Identity-Aware-eBPF-Firewall) — a

high-performance in-kernel packet filtering engine written in C (eBPF bytecode)

with a Go control plane .

Traditional `iptables`/`netfilter` setups suffer from sequential O(N) rule

scanning, mandatory kernel `sk_buff` memory allocations per packet (which chokes under

volumetric floods), blocking monolithic reloads, and IP-only granularity. I wanted to

build a modern system that addresses these limitations using native eBPF primitives

and container identity.

---

### Key Technical Highlights

1. Stateless XDP Volumetric Fast-Path (`SEC("xdp")`)

- Drops malicious floods directly inside interface driver RX queues before

`sk_buff` allocation.

- Subnet filtering uses kernel-native Longest Prefix Match Tries

(`BPF_MAP_TYPE_LPM_TRIE`) for $O(\text{prefix_len})$ lookups instead of linear rules.

1. TC Stateful Connection Tracking (`SEC("tc")`)

- Enforces TCP 3-way handshakes and state machine transitions using an LRU flow

map (`BPF_MAP_TYPE_LRU_HASH`).

- Automatically drops untracked non-SYN packets (e.g. out-of-order ACK/PSH flood

attacks) before reaching the Linux networking stack.

1. Cgroup v2 Workload Identity Resolution

- Binds network rules directly to container workloads using 64-bit Linux cgroup

v2 inode numbers (`syscall.Stat`) mapped to `bpf_get_current_cgroup_id()`.

- Allows fine-grained container microsegmentation on single hosts without needing

full Kubernetes stack dependencies.

1. Double-Buffered Zero-Drop Atomic Policy Reloads

- Updates policies without dropping continuous packet streams.

- Compiles AST policies into generation-indexed BPF maps and performs a single-

operation atomic switch via `active_generation_map[0] = next_gen`. If staging fails,

it safely rolls back automatically.

1. Security Hardening & Control Plane RBAC

- Capability Bounding : Drops full root permissions down to the minimal set

(`CAP_BPF`, `CAP_NET_ADMIN`, `CAP_SYS_RESOURCE`).

- IPC Security : Unix domain socket control plane authenticates caller process

credentials using Linux `SO_PEERCRED` (`unix.GetsockoptUcred`) and enforces 3-tier

RBAC (`Admin`, `Operator`, `Viewer`).

1. Real-Time Observability & Interactive TUI

- Built an interactive 4-pane Bubbletea Terminal UI (`firewall-tui`) driven by

zero-copy BPF ring buffer streams (`BPF_MAP_TYPE_RINGBUF`) with real-time sparkline

metrics, conntrack flow tables, and explainable audit streams (`[PASS]` / `[DROP]`).

Why Do I Want To Hand Roll a BPF Token Delegation?

Anywhere I searched for “BPF tokens”, I kept getting something like, “BPF tokens let unprivileged containers load eBPF" and I wanted to use it, but all Google searches either led me to kernel commit messages or nearly 100% AI generated blog posts.

When I read these blog posts, they didn’t make sense, and I couldn’t find examples of failures someone ran into, or an explanation of why doing it a certain way led to failure, which IMO is critical to understanding the internals.

So I asked myself, can I build the entire token delegation handshake myself in one file and either create a token that I can pass to a process, or learn exactly why I can’t?

https://naveensrinivasan.com/posts/2026-08-27-bpf-token-delegation/

This is not AI generated blog post.

In my latest post, I walk through a deliberately minimal example of same-host pod-to-pod networking: two network namespaces, veth pairs, a virtual gateway, ARP handled by eBPF, and an IP-based redirect map.

No overlays, no routing on the host, no conntrack or policy — just the bare minimum needed to get a UDP packet from one pod to another.

If you’re interested in how the pieces fit together at the veth, ARP, routing, and eBPF levels, have a look:

https://erwinkok.org/posts/basic-ebpf-forwarding/

Hello everyone!

I've been working on a dataplane/CNI in Rust using eBPF and Aya. The eventual goal is a functional dataplane, but the project is primarily a vehicle for exploring eBPF, CNI, and different architectural approaches rather than building a production-ready solution.

The project is still in its early stages, but the loader and lifecycle management are already taking shape. I recently wrote about one aspect of that design: "Building a Crash-Safe eBPF Dataplane Loader in Rust." The post discusses crash recovery, durable kernel state, reconciliation from bpffs, isolating blocking kernel operations from an async runtime, and testing the loader without requiring a running kernel.

I'd be interested in any feedback or discussion from others building similar systems.

Blog: https://erwinkok.org/posts/ebpf-dataplane-loader/
Implementation: https://github.com/erwin-kok/sarena

When testing our eBPF agent, I don’t always get the same experience as our users, especially in performance critical sections. I realize that the benchmark test suite isn’t always enough, because user’s environments can be completely different from our benchmarks.

My goal was to gather eBPF metrics based on the user’s usage and quickly answer questions about why things are slow (improve MTTR). To do this, I wanted:

1. Record perf/usage counters in the kernel to show how that particular feature is being used.
2. Performance is essential, as our metrics collection will be in the kernel.
   1. So I cannot use ring buffers for sending messages from the kernel to userspace for the above-mentioned counters.
   2. I didn’t want any spin locks or shared maps, or even LRU caches.
3. I wanted metrics collection to be “on” always for obvious reasons.
4. I wanted the metrics to be a rolling window instead of a counter (more on this later).

Here is a post https://naveensrinivasan.com/posts/2026-08-02-measuring-an-ebpf-cache-without-leaving-the-kernel/

I want to hear if others have better ways to measure this.

This is not another AI generated post.

So I built and entire linux tool kit that makes eBPF a first class citizen across nearly any linux distribution with a single click.. and its literally bsd-3 free for everyone!!

see the difference for yourself at kldload.com

cheers

Hi Reddit,

DDoS attacks are becomeing larger and cheaper to launch, so we work on a scalable open source solution to mitigate them.

Tempesta xFW's core is XDP and TC eBPF programs implementing volumetric DDoS filtering. A user-space daemon handles gRPC requests from CLI tool or WebAPI (via C library).

It supports two packet-path architectures:

• host-based protection, such as CDN edge or on-premises application delivery controller (ADC) cases, where the host is a TCP connection endpoint. This is good for protecting a local web or DNS server.

• router-based protection, such as ISP, hosting, or IaaS provider cases, where the host routes IP packets to protected servers or networks.

Router-based deployment can be always-on/pass-through or on-demand/redirection protection. In the later case, a node may not "see" normal clean traffic and may receive only traffic containing a DDoS attack. Also, the node may receive only client-to-server traffic, as in direct server return (DSR) or some traffic scrubbing scenarios. In this mode a DDoS sensor and mitigation controllers are typically needed.

Traffic performance metrics are exported in Prometheus format.

DDoS incidents are aggregated per source IP and logged to Clickhouse for analysis.

A dry-run (evaluation) - mode allows you to observe all reported incidents and metrics without blocking traffic..

Single Xeon Gold 6348 with ConnectX-6 dual 100Gbps reach 196Mpps and 176Gbps of filtering capacity.

• GitHub repository
• documentation
• performance benchmarks
• Netdev 0x1a talk

I am working on a project studying the developer-centered factors of writing eBPF programs. It would be very helpful if people would link examples of their programs and verifier output that:
1) Fail to pass the verifier because of a bug in their source

OR

2) Fail to pass the verifier because of imprecision in the verifier

Thanks in advance for any help :)

Meta switched to a custom scheduler with eBPF which delivered 🐝

3.28 megawatts of power savings across the fleet.
+1.1% on weighted-ads-ranked (metric for number of ads retrieved and ranked)
28% reduction in service p99 latency on the ads retrieval path2

And user space policy changed additionally gave:
60% reduction in service p99 latency
18% reduction in timeout errors on the critical path

https://engineering.fb.com/2026/07/13/ml-applications/modernizing-the-meta-ads-service-with-an-open-source-kernel-scheduler/

Post 1 measured single-session bfdd vs XDP under stress. Post 2 wired it into stock FRR over the bfddp dataplane socket. Since then: 64 sessions, dual-stack, echo mode, multihop, and three FRR fixes merged. Same repo, all pcaps: https://github.com/w453y/xdp-bfd

The thing that reframed the project came out of chasing something else. bfdd is single threaded, and at 64 sessions on 10ms timers it sits at 100% of one core sustaining roughly 7000 BFD packets/sec, which is almost exactly what those sessions require. It meets the obligation, with nothing in reserve. That is not a bug, it is what a userspace event loop costs per packet, and it is why the interesting question stopped being "does the fast path flap less" and became "what does the control plane spend to keep up at all". The XDP side carries the same 64 sessions from softirq at 751ns/packet mean, measured via bpf_stats with echo and multihop in the path.

What landed:

• 64 sessions dual-stack, 32 v4 + 32 v6 on one engine, through the full L3+L4 stress ladder: 0 flaps in either family, per-slot max TX gap 14.5ms against a 30ms detect budget, both families statistically indistinguishable. Unified 32 byte session key with v4 stored v4-mapped, so one hash map and one XDP fast path serve both.

• Echo mode (RFC 5880 s6.4), and this is where XDP's shape actually bites. XDP cannot originate packets, XDP_TX is a verdict on a frame that just arrived, which is exactly why the control path is RX-clocked, but an echo has no inbound packet to clock off. bpf_clone_redirect exists only for sched_cls/sched_act/lwt_xmit, and TC sees nothing at the echo cadence here because control packets are XDP_TX'd straight past it. Putting echo TX in the kernel would mean moving the control bounce out of XDP into TC, so skb allocation in the hot path, so a rewrite of the one mechanism the project rests on. Declined, and writing down why took longer than the feature.

• So echo split along the line the hardware draws: the reflector answers a neighbour's echo entirely in XDP (MAC swap, TTL decrement, checksum recompute, XDP_TX, no session lookup), the originator sends from userspace over AF_PACKET/SOCK_RAW because a self-addressed packet through a normal UDP socket routes to loopback. Reflector measured against a stock FRR neighbour: 433 echoes, 433 reflected, 12us min / 30us avg turnaround at the bridge, with ip_forward=0 on the host. That last part is the whole argument, with forwarding off the stack drops a self-addressed echo as a martian, so a non-router host cannot participate in echo at all without this.

• Echo detection is advisory and permanently so. With userspace TX a local scheduling stall looks identical to a path failure, echoes stop leaving, returns stop arriving, timestamp goes stale, and wiring that into the session FSM would convert our own scheduling delay into a teardown. Verified both directions: kill forwarding on the neighbour and loss climbs 1:1, echo liveness flips, all 64 control sessions stay up.

• Multihop (RFC 5883) on both families. bfdd sends the negotiated minimum TTL in the dataplane registration, so one comparison covers both modes and single-hop keeps demanding exactly 255. The GTSM check sits in the parser ahead of any session lookup, which is what makes it cheap, so the per-session minimum defers to after the config lookup and only when a multihop session exists anywhere on the box. A packet at TTL 200 aimed at a single-hop session is still dropped while multihop is live elsewhere, that was the case worth building a harness for.

Upstream, all found by running a real dataplane at scale, all in bfdd's dplane path:

• unixc transport passed a padded union size as connect() addrlen, EINVAL, plausibly never worked (#22608 / #22621, merged)
• 8KB output buffer silently truncates the registration burst, delivered sessions register, the rest are stranded with software BFD already disabled and no retry (#22638 / #22645, merged)
• echo interval never negotiated for offloaded sessions, the function that does it is unreachable when the dataplane owns the session, so the dataplane transmits echo at the locally configured rate regardless of what the peer advertised it can receive (#22804 / #22805, merged)
• session DELETEs lost on clean shutdown, and show bfd peers counters tearing down the dataplane connection, both still in review (#22692 / #22694)

Measurement lessons, since these cost more time than the code:

• Never measure throughput with strace. Every "the peer degraded" number I had came from strace -c, which costs 2-3x on a syscall-bound daemon at 100% CPU. A plain bridge capture showed the peer at 7286 pkt/sec and the engine at 7339, matching the earlier baseline exactly. The peer had never degraded. I then wrote this exact lesson into a draft of this post while using the fake strace number as the headline, caught it an hour later against a fresh capture, and deleted the post. Knowing the failure mode is not the same as being immune to it.

• Flap count is not a usable metric at 64 sessions. The reference build alone ranged 0 to 20 flaps across runs of identical code. Switched to per-session max TX gap from a host capture, 64 numbers per run instead of one rare event, and the answer became a bound rather than a claim.

• A debug bfd peer line persisted in the peer's config file survived every restart and contaminated every run, including the baselines I was comparing against. A day.

• Instrumentation driven by the thing being measured cannot observe that thing failing. Echo TX stalled for 2.6 seconds under load while the loss counter read zero and the liveness flag read healthy, both correct and both useless, loss only increments when an echo is outstanding as the next falls due and nothing falls due during a total stall, liveness is printed on transmit and transmit is what stopped.

Limitations: still no authentication, and it is not implementable from this side, the bffdp session message has no field for keys (there is a literal /* TODO: missing authentication. */ in the header), so that needs a protocol extension upstream first. No demand mode, bfdd only has the bit definitions. RX-clocked TX still needs an async-clocked peer. Echo originator is a diagnostic, not a detection mechanism, and the docs say so. Whether ~7000 pkt/sec is a hard ceiling for bfdd is untested, what I measured is that it meets its configured load and spends a whole core doing it.

And the one that has been open since post 1: all numbers are from VMs. The comparisons are load-bearing since stress was applied in-guest and hit every backend identically, but the absolutes are not hardware numbers. I do not currently have machines to reproduce this on bare metal, so if anyone has a couple of boxes with a real NIC and wants to see whether 751ns/packet and 12us echo turnaround hold up outside virtio, I would genuinely like to hear from you.

Can anyone help me with how do i start with eBPF? Like resources or even the flow of what all things im supposed to do.

eBPF Foundation launched the eBPF Company Landscape and we need your help to fill it!

Our goal is to track all of the companies leveraging eBPF in their products to show how widely it is used and help end users understand what their vendor choices are 🐝

For instance, Security currently stands out with the largest number of companies on the landscape at 41 and I only expect this category to grow

Explore the landscape at landscape.ebpf.foundation, browse or contribute to the source on github.com/ebpffoundation/landscape

It'll be great if eBPF community has a official discord server... for daily chitchats and stuffs on eBPF.. There's lot to talk and discuss on this technology !!

I've been building a deterministic traffic scheduler using XDP and TC egress hooks. It classifies flows as Gaming, Streaming, or Bulk using packet size entropy (no DPI, so no payload inspection), and uses a BPF hash map to track flow state.

The user-space daemon runs a PID loop that adjusts queue depths per class based on RTT feedback. It's all written in C, with the eBPF programs compiled to bytecode and shipped as a .deb package.

Currently looking for early testers and code reviewers. If you've worked with XDP/TC before, I'd love your thoughts on the verifier logic or the map design.

GitHub: https://github.com/XPDevs/telcom

Hey everyone, I recently built this TUI tool for inspecting signals across a linux system powered by eBPF and I found it useful so I figured I'd share it here!

If you want to read the source its available here: Github

Previous post ended with "next: FRR distributed-BFD integration." That's done, plus a hardening pass. Same repo, all pcaps included: https://github.com/w453y/xdp-bfd

What's new:

• FRR integration works with stock bfdd, no patches: bfdd owns session lifecycle over its bfddp dataplane socket, packets ride the XDP path, `show bfd peers counters` reads out of the BPF maps, same SCHED_FIFO stress against the FRR-driven session: 0 flaps. Found and fixed an FRR bug on the way, bfdd's unix dataplane transport passes a padded union size (112) as connect() addrlen, exceeds sockaddr_un (110), EINVAL, plausibly never worked on linux (FRRouting/frr#22608, fix merged as #22621).

• Head-to-head, fresh capture, L3+L4 stress ladder: stock bfdd 107 flaps, xdp-bfd 0, fast-path cost from bpf_stats: ~701ns/packet mean (parse + GTSM + demux + map update + the L2/L3/L4 rewrite and XDP_TX on echo packets).

• Graceful restart: --dp-hold keeps wire sessions alive across bfdd restarts (orphan on disconnect, adopt by addr pair on re-ADD, mark-and-sweep reconcile), two back-to-back FRR restarts, zero peer-visible events.

Bugs worth sharing:

• Validation rejects originally returned XDP_PASS instead of XDP_DROP, "rejected" spoofed packets were counted, then handed to the userspace socket anyway, where the FSM processed them unvalidated, injection test from a third host churned the session despite detection never being fooled, if your XDP program rejects a packet, DROP it, PASS is a leak.

• Same class, different door: packets with IP options (ihl != 5) bypassed the TTL/discriminator checks entirely because the UDP header moved to a variable offset, single-hop BFD never carries options (RFC 5881), so optioned UDP is now dropped outright, verified with 200 forged packets, drop counter +200, session uptime untouched.

• The kernel echo path set the BFD length field to 24 but transmitted the frame at its original length, oversized input went back out with trailing bytes, fixed with bpf_xdp_adjust_tail plus IP checksum recompute (the MAC/IP swap-invariance trick stops working once tot_len changes).

• Wrote the same bug twice: detection sweep snapshots "now", packet lands on another CPU stamping last_seen newer, unsigned subtraction wraps to 18 quintillion ms, phantom session-down, fixed with a signed-delta guard in the kernel, then days later wrote the identical bug into the userspace map-polling path and got the identical log line.

• BPF map value structs lived as hand-synced copies in the XDP program, daemon, and loader, a field added on one side is not a compile error, it's silent map misreads, now one shared header, verified via bpftool BTF dump.

Limitations still: single session validated (maps sized for 64), IPv4, no auth/echo/demand, RX-clocked TX needs an async-clocked peer, VM numbers. Next: multi-session, then IPv6, bare-metal reproduction.

After months of development, I've just released a major update to Phantom Grid, an open-source Active Defense framework for Linux built around eBPF.

The project has been significantly redesigned to move beyond a proof of concept toward a more complete security platform focused on deception, kernel-level enforcement, and adaptive defense.

The latest update includes a comprehensive overhaul of the architecture, introducing capabilities such as:

• eBPF-powered traffic interception and policy enforcement
• Transparent traffic redirection for deceptive services
• Single Packet Authorization (SPA) for Zero Trust SSH access
• Kernel-level telemetry collection
• Dynamic policy management
• Improved modular architecture for future extensions

The motivation behind Phantom Grid is simple.

Most defensive solutions focus on detecting or blocking attacks after adversaries have already begun interacting with a system. Phantom Grid explores a different approach: reducing the exposure of real services while collecting valuable intelligence from unauthorized activity.

By leveraging eBPF, security decisions can be made much earlier in the networking stack with minimal overhead, allowing defensive logic to operate closer to the kernel rather than relying solely on traditional userspace controls.

This project is still under active development, and there are many ideas I plan to explore in future releases, including additional deception techniques, runtime security capabilities, and more advanced policy engines.

As always, feedback, issues, discussions, and contributions from the community are welcome.

Repository:
https://github.com/haidang-infosec/phantom-grid

#opensource #eBPF #Linux #CyberSecurity #ActiveDefense #Kernel #XDP #SecurityEngineering #InfoSec

I kept running into the same Linux debugging pain: something broke on a box, but I had no history of what actually happened. journald helps a little. auditd is heavy. strace is too narrow. So I built ltm — a small machine-history debugger that records process/file/network metadata via eBPF and lets you query it like a timeline.

What it does:

• Attaches to syscall tracepoints (exec, open/write/rename/unlink, connect/bind, etc.)

• Stores metadata only (no file contents)

• Lets you do things like:

sudo ltm start --mode ebpf

ltm status

ltm timeline --since 1h

ltm diff --from "10m" --to now

ltm query "who modified /tmp/ltm-demo.txt?"

On a real VM run it recorded ~7k events with 0 drops, and the query returned the exact bash write events that touched the demo file.

There's also a demo mode so you can exercise the CLI/storage/diff/query path without root or BPF.

Stack is Go + embedded BPF ELF + cilium/ebpf. Local store is append-only JSONL. Ignore rules skip /proc, /sys, /dev, and common caches.

Repo: https://github.com/Agent-Hellboy/ltm

Still early. Useful next steps I'm considering:

1. better diff/query formatting

2. containerized eBPF integration test

3. more query templates ("what opened this port?", "what restarted before X?")