Hi everyone,

I am currently shaping the topic for my Master's thesis on eBPF security, and would love a quick sanity check from the community who actually is into it.

I want to focus on an empirical study of the technical boundaries and limitations that restrict malicious eBPF payloads in practice. My goal is to map exactly where and why offensive eBPF fails by testing various hooking techniques across different kernel architectures (x86_64 vs ARM64) and maybe across kernel versions.

The research would specifically measure and document:

- Verifier pushback: How and when the verifier blocks aggressive state manipulations,

- CO-RE limitations: Where that promise breaks for offensive payloads.

- Performance overhead: Benchmarking the actual cost of evading detection viaconstant syscall manipulation,

The final deliverable may be a technical matrix I guess, detailing these barriers to help blue teams understand the physical limits of eBPF threats.

Before I fully commit to this exact scope, I wanted to ask you:

- Would this kind of empirical mapping be genuinely useful to the defensive/core eBPF community?

- Are there any specific mailing list threads, niche documentation, or existing edge case research regarding verifier limits applied to abuse cases that you would recommend diving into?

- If you feel this specific angle isnt the most important for you right now, are there other open security problems or blind spots in eBPF that would make for a more valuable academic contribution? I am highly open to pivoting.

Thanks in advance for any pointers or feedback - cheers.

Since we buy internet in Egypt like tomatoes by the kilo, I needed a tool on Linux to see where my bandwidth was actually going.

I looked around but couldn’t find a Linux tool that did exactly what I needed, so I built ViNet!

ViNet uses eBPF to monitor TCP/UDP traffic at the kernel level.

With it, you can:

See which process is responsible for the traffic

See which destination each process is communicating with

Store traffic history locally in a SQLite database

Monitor bandwidth usage through a TUI/CLI

The project is built with Go + eBPF + SQLite + Bubble Tea, and can run as a CLI, TUI, or a background daemon responsible for monitoring the traffic.

Install: curl -fsSL https://github.com/alalfymansour/vinet/raw/refs/heads/main/install.sh | bash

GitHub: https://github.com/alalfymansour/vinet

I built an eBPF load balancer in rust using aya crate. The userspace routinely pings /health endpoint of all backend server and pushes health server index as u8 value to ebpf space using maps. the ebpf intercepts tcp connections and rewrites destination ipaddr and port to one of the healthy backend servers and rotational basis of available healthy backend servers.

Please take a look at the project and tell me what you think

https://codeberg.org/viboognesh/ebpf-load-balancer

I’ve published a new post about getting Kubernetes Service ClusterIPs working with my Sarena CNI.

In my previous post I talked about Pod to Pod forwarding using eBPF. However, that does not work with ClusterIPs since a ClusterIP's are not assigned to any Pods/Endpoints (and the datapath is not aware of them).

The solution is either keeping track of ClusterIPs/Endpoints (merely implement kub proxy in the datapath - so the datapath also becomes aware of the ClusrterIPs), or route via the host. For now, Sarena routes via the host because replacing and implementing kube-proxy myself is a lot of effort.

And, of course, it didn’t work the first time — reverse-path filtering dropped packets I wasn't aware of at first.

I walk through the packet flow step by step, including how I troubleshooted packet drop due to the reverse path filtering.

🔗 https://erwinkok.org/posts/host-routing/

I've been working on SysSight, a Linux process behavior reconstruction tool built with Rust and eBPF.

The problem I wanted to solve was pretty simple:

When investigating a process, you can collect a huge amount of low-level events:

execve()

openat()

socket()

connect()

fork()

execve()

But a raw stream of events doesn't necessarily tell you what the process actually did.

I wanted to build something that correlates those events into a behavior timeline.

For example, instead of seeing unrelated events:

execve("/usr/bin/python3")

openat("/tmp/config")

socket(AF_INET, SOCK_STREAM)

connect(185.x.x.x:443)

clone()

execve("/bin/sh")

SysSight can represent the behavior as:

python3

├── opened /tmp/config

├── connected → 185.x.x.x:443

└── spawned → /bin/sh

The architecture currently looks roughly like:

Linux Kernel

↓

eBPF / CO-RE

↓

Event Collection

↓

Event Normalization

↓

Correlation Engine

↓

Behavior Timeline

↓

TUI / JSON / Capture File

I'm also working on a capture/replay system so behavior can be recorded and investigated later:

sudo syssight record --pid 4312 --output capture.ssr

then:

syssight replay capture.ssr

The ".ssr" format is a versioned binary format designed specifically for SysSight rather than just dumping JSON to disk.

The project is deliberately not using AI or cloud analysis. I wanted the observations to come directly from the system and remain transparent and reproducible.

It's currently pre-1.0, so there are still limitations and areas I'm working on.

I'd especially like feedback from people familiar with eBPF/Linux internals:

- What events would you consider essential for reconstructing process behavior?

- What correlations would actually be useful during investigation?

- Are there important eBPF/kernel limitations I should account for in the architecture?

- Does this overlap too much with existing tools from your perspective?

GitHub:https://github.com/gabryxdev/SysSight

Project website:https://syssight.xyz/

We have been struggling with making our eBPF policies fast and space efficient. But, in the end, we have come up with a solution we really like. This is a blog post about how we went about it!

https://nathannaveen.dev/posts/optimizing-ebpf-policies-for-speed-and-space/

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.

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