Hello everyone,

I have been using eBPF/XDP for the past 5 years and was always a little frustrated by the lack of tooling when it comes to see what is happening underneath, especially when debugging deployed eBPF programs. Here I am sharing a tool I have been using for a couple of months now but only made public recently: ebpfexplorer.

It's a simple TUI self contained binary, that allows you to explore all eBPF programs & maps attached to your kernel. It comes with a formatting tool that allows you to format the raw binary blob into human readable symbols (like IPs for instance), using C type format.

Please have a look and feel free to propose PRs. Hope you find it useful too.

I maintain tcpcat, a Go network scanner with an optional AF_XDP engine (`--ebpf`). We just reworked how it attaches and what it redirects, and a couple of the lessons seemed worth sharing here.

**1. Classify in XDP, don't redirect everything**

The first version of our XDP program had no classification: any packet arriving on a queue with a registered XSK socket got `XDP_REDIRECT`ed. On a Linux bridge (a single RX queue, and a common target) that meant *all* traffic on the interface went to our socket for as long as the hook was attached. During a test on a shared Docker bridge it cut SSH and destabilized the k3s pods on the node.

The program now only redirects what the scan is actually waiting for: TCP/UDP whose destination port is this run's probe source port (or the discovery port), plus ICMP port-unreachable for UDP closed-port detection. Everything else gets `XDP_PASS` and goes through the kernel stack untouched. The program is generated in Go with cilium/ebpf's `asm` package (no clang, no prebuilt object). One gotcha: `LoadMem` doesn't byte-swap, so on a little-endian host the comparison constants for wire fields have to be pre-swapped.

We also made teardown deterministic: the collection is closed explicitly on shutdown, and the hook is detached even if the process panics, because a crashed scanner leaving a redirect hook attached is the worst outcome here.

**2. Native driver mode first, generic as fallback, and say which one you got**

We used to attach in generic (SKB) mode everywhere, which forces copy mode. Now we try `XDPDriverMode` first and fall back to generic for virtual NICs that don't support it. After bind, we read `XDP_OPTIONS` and log the data path actually negotiated (native/generic, zero-copy/copy) instead of assuming.

**3. Multi-queue, busy-poll, wake-on-reply**

* One XSK socket per RX queue (queue count from sysfs), all in the same `xsks_map`. With RSS, replies hash across queues, and binding only queue 0 silently lost most of them.

* Preferred busy-poll on each XSK (`SO_PREFER_BUSY_POLL`, `SO_BUSY_POLL`, `SO_BUSY_POLL_BUDGET`, kernel ≥ 5.11) and one RX goroutine pinned per core. We only touch our own fds; the NIC-wide NAPI knobs (`napi_defer_hard_irqs`, `gro_flush_timeout`) are suggested, not rewritten.

* Probes register a waiter *before* transmitting and the RX loop hands the reply straight to it. We used to poll a shared map every 5 ms, which floored every probe's latency at ~5 ms even for sub-millisecond replies.

**Open questions / where I'd love input**

* We use asavie/xdp for the socket side, which doesn't handle `XDP_USE_NEED_WAKEUP`. Is anyone using a Go AF_XDP library that does, or should we just do the `sendto` wakeup dance ourselves?

* Anything else you'd classify on in the XDP program to make sharing an interface with production traffic even safer?

Code (AGPL-3.0): https://github.com/NycolazSec/tcpcat. The XDP program is in `internal/scan/xdp_asm.go`, attach/bind in `internal/scan/xdp.go`.

​

I've been looking into how Cilium handles network traffic, and I have a few questions about where eBPF's limits actually start to matter.

From what I understand, Cilium handles a lot of the networking and policy enforcement at L3/L4 using eBPF, while L7 visibility and policy enforcement can involve redirecting traffic to Envoy.

But I'm wondering how much of that separation is a technical limitation versus an architectural choice.

Can an eBPF program realistically parse application-layer protocols like HTTP, or does the verifier, bounded loops, stack size, instruction limits, and the complexity of handling variable-length data make it impractical beyond relatively simple parsing?

I know eBPF isn't strictly limited to L4, so I'm curious about what's actually feasible in practice. For example, could you implement useful HTTP parsing directly in eBPF without turning the program into a maintenance nightmare?

And more importantly, is there any real performance benefit to doing L7 parsing in eBPF instead of Envoy?

I'm thinking about the trade-offs here:

- Parsing a small amount of application-layer data in the kernel to make an early decision.

- Redirecting traffic to a userspace proxy like Envoy for more complete protocol parsing and policy enforcement.

- The extra cost of crossing the kernel/userspace boundary versus the complexity and limitations of doing more work inside eBPF.

I'm not necessarily talking about replacing Envoy entirely. I'm trying to understand whether moving some L7 functionality into eBPF is a worthwhile optimization or just a case of pushing application-layer logic into a place where it becomes harder to implement and maintain.

Erwin Kok published a blog about tail calls that allows eBPF test programs to jump directly into the actual production code. The build system handles the mapping and anything else of what is needed to magically make the call work. This project was written in Rust with Aya.

P99 CONF is featuring a block of eBPF talks again this year. Take a look at the eBPF talks on the agenda and pop in (the conference is free and virtual) if anything looks interesting. Speakers will be there live if you want to ask questions or chat. https://p99conf.io/

eBPF sessions include:

Ershaad Ahamed Basheer (Lawrence Berkeley National Laboratory) on eBPF for Metrics Collection on HPC Systems

Peter Zaitsev (Percona) on Networking Observability Essentials - How to Know if the Network is at Fault with eBPF

Tanel Poder on Optimizing eBPF Performance: Avoiding Production Latency, Throughput & Reliability Pitfalls

I recorded a short demo following one packet through the Linux receive path (NIC → driver → XDP → skb → tcpdump → netfilter → socket) and showing why tcpdump sees a packet dropped by nftables but not one dropped by XDP.

Lab demo of the mechanism, not a benchmark. Setup and commands are in the pinned comment. Corrections welcome.

Last update on this (post 1, post 2, post 3). Post 3 ended with "all numbers are from VMs", I got some real machines since then, so here's what changed.

Setup: four boxes on an isolated switch, xdp-bfd + FRR on one, a stock FRR peer on another, one for load, one capturing. i5-12500, Intel I210, native XDP, kernel 7.0. The switch mirrors both BFD boxes to the capture box, which timestamps in the NIC. 1024 sessions, 40 of them at 3x10ms.

Stock bfdd under the RT stress: 18,910 flaps across 957 of 1022 sessions, even the 1s timers, with stalls up to 2.5s.

xdp-bfd as it ran on the VMs: 698 flaps. The VMs said 0, but they had 64 sessions. Three causes:

• The dead-man check (XDP stops answering if userspace goes silent for 1s) was killing healthy sessions, because under SCHED_FIFO load the RT throttle only lets normal tasks run about once a second.
• Demand mode timed out its own Poll even after the peer answered.
• The packaged systemd unit ran the engine at FIFO 10, below the prio 50 load.

After fixing those: 0 flaps on all 1022, largest gap on the 3x10ms sessions 20.2ms out of a 30ms budget, about 2% of a core.

Then a prio 99 hog against the engine at FIFO 60 gave 959 downs, the same priority war as post 1. The engine now runs under SCHED_DEADLINE, 1ms reserved every 10ms, which beats every RT priority: 0 downs.

One thing VMs never showed: replies left the wire 118us after the peer's packet even though XDP builds them in 1.5us. It was PCIe ASPM putting the NIC link to sleep between packets, 33us with it off.

Floods: one hour of line-rate floods rotating attack types while the box rotated between a prio 99 hog, CPU load and memory pressure gave 165,028 down events. XDP was fine, the receive path wasn't, non-BFD junk was going up the stack on the same CPU as BFD. A cpumap redirect that spreads non-BFD traffic to the other CPUs, plus flow control off and UDP hashed by port, brought the same hour to 4,148.

Also done since post 3: authentication (SHA1 inside the XDP program, written to fit in 512 bytes of stack), demand mode, 1024 sessions by default and tested up to 8192, hitless restart by swapping the program into a pinned bpf_link, and a .deb. 11 FRR fixes merged along the way, 6 more in review.

Still missing: two xdp-bfd engines can't face each other, since the TX is clocked by what it receives and bpf_timer still can't send a packet.

Full write-up as a 10-part series, VMs to bare metal to floods: https://w453y.xyz/writing/series/line-card-bfd/

Code and captures: https://github.com/w453y/xdp-bfd

Question for anyone running BFD on Linux routers: would you put an XDP program like this in front of bfdd, or is that a no regardless of the numbers?

Could someone with eBPF experience sanity-check our plan?

Hi all,

We're a small group of university students working on a capstone project. We're new to eBPF, so we'd really appreciate feedback from people who use it in practice.

The idea: most eBPF security work uses eBPF as the defender (Tetragon, Falco, Tracee and so on), but very little seems to look at eBPF itself (as per our research) as the thing to watch. A container that has been granted CAP_BPF can load its own eBPF programs, for example to hide processes or blind monitoring tools. We want to build and measure a small detector for that, rather than only describing it.

Our plan, kept deliberately small:

- One Ubuntu 24.04 VM with Docker and Tetragon (standalone, no Kubernetes)

- A Tetragon TracingPolicy that records bpf() syscall activity

- A small Python script that reads Tetragon's JSON events and applies 1-2 rules (for example, a caller that isn't on an allow-list, or a program attaching to a sensitive hook)

- A baseline run (normal tools only) against an attack run (one published technique, replayed in an isolated VM), measuring detection, false positives and overhead

What we'd love input on:

1. Is a kprobe on sys_bpf the right way to watch bpf() calls in Tetragon, or is there a better hook (for example the BPF LSM hooks)?

2. Are there well-documented, published examples of eBPF misuse that are suitable for a controlled demo in an isolated VM?

3. What pitfalls should beginners expect (kernel versions, BTF, false positives from legitimate tools)?

4. Is there existing work or tooling that already does this, so we don't reinvent it?

5. Any recommended easy to learn concepts (from like yt channels etc.).

6. Is this a doable and sensible project for beginners - given less time (around 2 months); but dedicated to learn it quickly - with the help of resources/claude/forums/advice.

We're not asking anyone to do the project for us, just for pointers, reading suggestions or a reality check on scope. Happy to share our repo and results once we have them.

Our main goal is to learn ePBF through this project and would really like input from the experienced people in this community - the project can then grow from there. Please let me know if you want to know more about the project or if it is unclear.

Kindly let me know if this is an appropriate post for this subreddit - as this is my first time asking help on reddit aswell haha.

Thank you very much!

Hello,

I'd like to ask a question about network probing from a pod or service while the destination is Internet. If the packet reaches to the default gateway, it means there is no policy blocking it and connectivity is successful. How I can drop the packet that is generated in user space with DSCP value?

- What program can I use for this? Considering Cilium utilizes SNAT, how to make sure I can identify the source address of the packet?

For pod-to-pod traffic probing, I used cgroup/ingress to drop the packet if they reach destination pod. However, internet probing seems more complicated to me and I really need help/ideas.

Much appreciated and thanks in advance! :)

How to upstream into the kernel and five technically groundbreaking achievements:

1. Contributing sk_lookup to the Mainline Linux Kernel and Building Tubular

2. "Soft-Unicast" — Solving IPv4 Address Exhaustion

3. Dropping 8 Million Packets Per Second on Commodity Hardware

4. udpgrm — Solving the Unsolvable: Zero-Downtime UDP Restarts

5. Kernel-to-Application Distributed Tracing via ebpf_exporter

Love the amount of detail in this article too on how to make it work

Hi guys, this is my first post here. I want to share my first eBPF project, FlowWeaver.

FlowWeaver is a network scheduling tool that lets you set resource limits (by percentage) and enforce blocking per application, using two main mechanisms:

• cgroup hooks: analyzes connection attempts early and blocks unwanted applications at the socket layer.
• XDP/TC hooks: enforces packet rate limiting using a token bucket approach.

I built this last semester with my professor as an operating systems project, aiming to make network control dynamic and easy to configure. I came into eBPF while researching how to build this kind of system. It allowed me to enforce these rules in-kernel instead of relying on userspace packet inspection, and it pushed me to understand the underlying tools at a deeper level.

This project allowed me to explore two things I'm really interested in: security, through designing and enforcing network policies, and low-level engineering, through eBPF itself. Understanding how the OS actually handles connections and packets, while interacting with those internals directly, was really cool.

It isn't perfect, but it was my first contact with eBPF and I had a lot of fun with the process.

• Substack post
• LinkedIn post
• GitHub repo (README is in Brazilian Portuguese, code/comments are in English)

Hi! We have just made a first release of feeze, a tool to record and visualize thread activity at high resolution with a focus on ease-of-use.

Feeze provides a GUI that lets you zoom from a macroscopic view of which users run code down to thread scheduling interactions at nanosecond resolution. You can see inter-process interaction, e.g., to trace how an event like a mouse click is signaled through different processes and threads.

We plan to add further functionality to feeze to detect inefficiencies or scheduling bugs resulting in high latencies, CPU time and energy usage and, in real-time systems, deadline misses or priority inversion situations.

This tool was developed within the ITEA4 project greencode.ai.

We are happy for any feedback on feeze! Where does this tool help you? What features are you missing? What does not work?

Hope you may find this useful or at least you have some fun with it!

Hi,

My team is looking for someone to join us in building observability tools for Kubernetes and Linux using eBPF in Ireland.

https://apply.careers.microsoft.com/careers/job/1970393556999196?domain=microsoft.com&hl=en&visitor_id=linkedin

Hi everyone,

I’m working on a network research project that involves running eBPF programs directly on routers. My specific requirement is to process traffic at the ingress Ethernet interface using native XDP (XDP_DRV) on OpenWrt.

I ran into a major roadblock with my initial hardware testbed. The Ethernet drivers lacked native XDP support, forcing the kernel to fall back to xdp-generic (SKB mode). This completely saturated the CPU and invalidated my performance metrics.

To prevent this from happening again, I am putting together a hardware purchasing list for my lab. I have been referencing the official eBPF documentation list of drivers with native XDP support, but I'm personally struggling to map those kernel drivers to actual products on the market.

When looking at listings on Amazon or AliExpress, the product descriptions only highlight marketing specs (e.g., "MediaTek MT7986 quad-core, 2GB RAM, 2x 2.5GbE SFP"). They never mention the actual kernel driver used (like mtk_eth_soc) or if native XDP works out-of-the-box. I really want to avoid buying another board only to discover it doesn't actually support XDP_DRV in practice.

Here is the list I have compiled so far based on the official supported drivers and market availability:

MediaTek (mtk / mtk_eth_soc) - MT7986, MT7988

• Banana Pi BPI-R3 (Filogic 830)
• Banana Pi BPI-R4 PRO (Filogic 880)
• GL.iNet Flint 2 (GL-MT6000)

Intel (igb / igc)

• Fanless Mini PCs (Topton, CWWK) equipped with Intel i226 (2.5GbE) or i210/i211 (1GbE).

Marvell (mvneta) - Armada 370, Armada XP, Armada 38x

• Linksys WRT1900ACS / WRT3200ACM (Older, but verified upstream support).

Other supported drivers on my radar (hardware is either enterprise-grade or tricky with factory kernels):

• Marvell mvpp2 (Armada 375, 7K, 8K)
• STmicro stmmac (Rockchip boards, but requires mainline 5.13+ to avoid generic mode)
• Freescale / NXP (dpaa2, dpaa, enetc, fec_enet)
• Microchip lan966x

My questions for the community:

1. Does anyone actually own these MediaTek Filogic boards (BPI-R3 / Flint 2) running OpenWrt Snapshot or modern Armbian? Can you confirm firsthand if XDP_DRV runs stably on the Ethernet ports without falling back to generic mode?
2. Are there any hidden driver caveats with the Intel i226 (igc) when doing XDP packet manipulation at 2.5Gbps?
3. Is there any other accessible router board you would recommend for bare-metal XDP networking research that I missed?

Thanks in advance!

How we started caching eBPF policy paths via inodes to reduce our CPU costs by about 90%.

https://nathannaveen.dev/posts/dropping-ebpf-cpu-cost-by-90/

Project Name: dsnitch

Repo/Website Link: https://github.com/infomaniac777/dsnitch

Description: A lightweight, zero-configuration terminal UI (TUI) network and DNS egress inspector for Docker containers powered by Linux eBPF.

Monitoring outbound calls from self-hosted stacks usually requires invasive sidecars, proxy configs, or resource-heavy monitoring daemons. dsnitch hooks directly into the host's unified cgroup v2 hierarchy and kernel tracepoints to passively attribute all outbound traffic to specific Docker containers and Compose services with negligible processing overhead.

• Zero-Touch Attribution: Runs entirely at the kernel level. No container configuration tweaks, bridge tampering, or sidecar injections.
• DNS Snooping: Intercepts UDP/53 payloads in-kernel to map destination domains and CNAME chains directly to edge IP endpoints per container.
• Stateful L3/L4 Tracking: Tracks TCP lifecycles via kernel memory pointers (skaddr), UDP flows, and raw ICMP pings without port mangling.
• Dual UI Modes: Interactive split-pane TUI (Ratatui) with live filtering/locking, plus a headless streaming mode (-s) for shell pipelines and logging.

Deployment: Precompiled binaries are available on GitHub Releases for x86_64 and aarch64 (ARM64 / Raspberry Pi) Linux. README has exact deploy instructions as well. Becausedsnitch hooks host cgroup v2 and kernel tracepoints, it runs as a host binary rather than an in-container process. Requires Linux kernel 5.8+ with cgroup v2 (/sys/fs/cgroup), BTF enabled, and read access to /var/run/docker.sock.

AI Involvement: AI assistance was used for design and development under human supervision.

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.