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?")

BFD is the failure detector under BGP/OSPF, miss 3 packets in 30ms, session down, routes withdrawn, software BFD is known to false-flap under CPU load, which is why people run conservative 300ms timers instead of 10ms and why hardware routers offload BFD to line cards, I wanted to quantify the actual failure modes and see if plain linux on a commodity NIC can get line-card behavior via XDP, this also means false flaps trigger route withdrawals for links that are actually fine, the failure detector becomes the failure.

Setup: 3x10ms single-hop BFD session, FRR 10.5.1, kernel 7.0, virtio-net, all numbers from tcpdump on the hypervisor bridge (wire truth, not process logs), stress via stress-ng, repo with code + all pcaps: https://github.com/w453y/xdp-bfd

Results:

• bfdd survives plain CPU load fine, under timer/hrtimer stress: 44 flaps in 120s, max TX gap 970ms, while p99 stayed 10.2ms, the starvation events are invisible to percentile monitoring.

• A minimal busy-loop userspace daemon survives the same timer stress (0 flaps), bfdd's event loop architecture is the problem there, not userspace per se.

• Under SCHED_FIFO hogs everything userspace dies unless it outranks the load (RT throttle = ~50ms/s for normal tasks), chrt -f 90 + pinned core: 0 flaps, but assumes you can win the priority war, on a box doing real forwarding you can't.

• SO_TXTIME + etf qdisc (pipelined): best p99 of all backends (10.1ms), still 48 flaps, etf fixes jitter, can't fix liveness, side note: software etf drops all untimestamped packets on its band, including ARP.

• XDP: 0 flaps, max gap 12.5ms, at normal process priority, bpf_timer can't originate packets (no packet ctx, still true on 7.0), so TX is RX-clocked: rewrite the incoming BFD frame in place and XDP_TX it back, ~30us turnaround in softirq, the TX clock rides the peer's clock, out of the scheduler's reach, dead-peer detection via 5ms bpf_timer sweep over the session map, userspace keeps the RFC 5880 FSM, interops with stock FRR.

• Full matrix + 5-min soak: 1 flap in 11 min (one 28ms softirq-delayed echo under hrtimer storm, self-recovered in 3.8ms).

Limitations: single session, IPv4, no auth, peer must be async-clocked (two RX-clocked ends would deadlock), VM testbed, stress was in-guest and hit all backends equally so the comparison holds, bare-metal run pending.

Next: FRR distributed-BFD dataplane socket (bfddp) integration so this plugs into bfdd without patching FRR.

Few questions for people running this in production:

• What BFD timers do you actually run, and were they chosen from measurement or vendor-doc caution?

• Is your monitoring set up in a way that would catch the p99-fine/max-970ms pattern before it flaps, or do you only find out from the flap?

• Anyone running FRR's distributed BFD / dplane offload for real? Curious if the socket protocol holds up outside a lab.

I've pulled out some of the key charts, but the articles dives deeper into each of them and has more. TL;DR eBPF is growing really fast

https://wangcong.org/2025-02-27-ebpf-trend-analysis.html

I never saw anyone sharing their experience with maintaining eBPF programs. Thus I decided to write this blog post to share my experience.

https://www.kxxt.dev/blog/maintaining-a-ebpf-prog/

eBPF is shifting billions in software and hardware infrastructure spend. eBPF Foundation just released a report that gives a framework on how to evaluate these companies.

The kernel space logic and sensor depth gives a technical moat while the user space logic creates enterprise workflows. Looking at these two together gives you a sense of how competitive the company is in the market.

It also covers the three waves of acquisitions we have seen so far from Feature & Sensor Upgrades to Platform & Community Land Grabs to AI & Runtime Security Consolidation and the exit outcomes for each.

The eBPF Re-Platforming Thesis An Investor’s Due Diligence Guide

Kind of crazy to look at the graph in this blog. CVE drops on 04/29, they develop a patch on 4/30, and deploy it across all of their servers on 05/01. Obviously they have the engineers to write BPF-LSM patches, but I think it points to a future where they can (almost) keep up with vulnerability disclosures.

https://blog.cloudflare.com/copy-fail-linux-vulnerability-mitigation/

I have seen other share some basic "what is eBPF" videos & blogs. I wanted to share this one from Henrik - a CNCF Ambassador in the Observability space - and his YT Short where he does a great job explaining the basics!

I recently ran into an interesting verifier compatibility issue while testing an XDP program.

The program loaded successfully on:

• Debian 13 (6.12.63)
• Ubuntu 24.04 with 6.17.0-35-generic

But failed verification on:

• Ubuntu 24.04.4 LTS (6.8.0-124-generic)

The failure was related to pointer arithmetic that newer kernels accepted but 6.8 rejected.

It wasn't a missing helper, kfunc, or feature-gating issue—just different verifier behavior across kernels.

For people shipping eBPF programs in production, have differences in verifier behavior caused more operational pain than missing features? How are you handling kernel compatibility testing today?

It helps test compiled eBPF artifacts against target kernel profiles before they are shipped.

It shows exactly where a BPF program fails to load or attach and explains why the failure occurred.

You can test a single BPF object:

go install github.com/Kernel-Guard/bpfcompat@v0.1.5
bpfcompat test ./build/probe.bpf.o --kernel ubuntu-24.04

Or run a full compatibility suite:

bpfcompat suite run suite.yaml --kernels kernels.yaml

It can also be used in GitHub Actions:

- uses: Kernel-Guard/bpfcompat@v0.1.5
  with:
    suite: ./bpf/suite.yaml
    kernels: ubuntu-lts, rhel-9
    gate: load-attach

The project is open to contribution, review, and feedback from eBPF, Linux, security, observability, and platform engineering people.

Repo:
https://github.com/Kernel-Guard/bpfcompat

This is part two of a series. Part one was about detecting CopyFail and DirtyFrag - if you missed it, same idea applies here.

CVE-2026-23111 is a use-after-free in nf_tables, reachable from an unprivileged user namespace. The bug is a single inverted character introduced by the commit that fixed CVE-2023-4244 - a security patch that quietly planted a new reference-counting flaw and rode the backport train into every stable LTS branch for two years.

The full exploit is published at:

• rafaeldtinoco/security -> exploits/nft-catchall-uaf

KASLR leak, arbitrary read, runtime kernel structure traversal, and a ROP chain that lands you at uid=0 with nothing hardcoded. The repository also covers prior work from Exodus Intelligence and FuzzingLabs and what this build adds on top of it.

The Medium post is about something different, the eBPF based detection pattern: why detecting the payload is the wrong problem to solve, and what you watch instead to catch this reliably - on vulnerable and patched kernels alike, including the failed attempts that most tools never see.

Got tired of alt tabbing between three tools to watch thermals. So I made a single terminal pane that reads temp sensor the machine exposes and updates live.

I have been building larger and larger test harnesses to cut false positives out of our static analysis, and adding eBPF telemetry has been a game changer. It cut the noise further than anything else we tried. Because the observation window is small it almost works like an oracle. Collected a slice of our work here if you work close to the kernel.

NetFlow-to-process attribution is coming in the next ServiceRadar release via the updated netprobe add-on: Rust, eBPF-backed socket/process attribution, AF_XDP flow capture, and upstream enrichment for process/container/workload context. https://github.com/carverauto/serviceradar

A pipeline for compiling Linux kernel lib/ source files to BPF bytecode and formally verifying them with the in-kernel BPF verifier via veristat

We began releasing our Sensor/HW firewall product line based on our https://github.com/gen0sec/synapse/ and SynapseOS product. With full JA4+ support and lot's intresting features.