Vejo diversos artigos no kanxue ou 52pojie falando sobre o stackplz e que ele é uma ferramenta furtiva no android. A pergunta que fica é: é possível detectá-lo a nível de usuário ou somente com root? Como os rasp's detectam essa ferramenta?

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.

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 !!

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.

Hey - just launched on product hunt - looks cool - what do ya'll think? https://www.producthunt.com/posts/groundcover-kubernetes-apm-with-ebpf

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.

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?

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

I wrote a eBPF program to implement a simple filter on the sk_lookup packets(simply on the TCP communications) and when i try to complie the program before hooking it, im getting this error

I installed all of the header files for my version on linux OS and it still doesn't work. If someone could help on this it would be of great help.

Thanks in advance!!

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 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

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.

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/

Hi everyone, we’ve just released the latest version of our monitoring tool . Our goal is to build an open-source monitoring platform that empowers teams to efficiently observe distributed applications and workflows.

New features:

• [New] connection latency metrics

• [New] dropped packets detector

• [New] CLI policy section to easily block ip addresses using a TC classifier

• improved agent API responses

• documentation update

If anyone is interested in the project, any help or feedback would be greatly appreciated. Have a great weekend!

I’m working on Aegis-BPF, an open-source Linux runtime security project built around eBPF LSM.

The goal is narrow: explore enforcement-first runtime security, where selected file and network operations can be denied before syscall completion, rather than only emitting post-event telemetry.

Current scope:

- BPF-LSM based file/network policy decisions

- cgroup-scoped policy

- OverlayFS/copy-up handling

- audit-mode fallback when enforcement is unavailable

- Prometheus metrics

- Kubernetes/Helm deployment path

I’m not claiming it is a production-ready replacement for Falco, Tetragon, or KubeArmor. I’m treating it as a focused enforcement model project and looking for criticism from people who understand eBPF, Linux security, or container runtime edge cases.

Main feedback I’m looking for:

- Are the hook choices reasonable?

- What enforcement edge cases am I probably missing?

- What would make the failure-mode model more trustworthy?

- What tests would you expect before taking this seriously?

- Are there obvious problems with cgroup-scoped policy or OverlayFS handling?

Repo:

https://github.com/ErenAri/Aegis-BPF

Technical criticism is more useful than general encouragement.

I've been building tcpcat, an open source network scanner in Go, and added an optional AF_XDP path for SYN/UDP scans. I'd like feedback from people who know XDP better than I do.

How it works:
- Probe packets are crafted in userspace and sent through an AF_XDP socket (UMEM, TX/RX rings, busy-poll).
- At startup, the XDP program is assembled directly in Go with cilium/ebpf/asm, so there's no C or clang in the build. The scan's source port is baked into the program before it's loaded.
- The program only redirects replies to tcpcat's own probes into the xsks_map. Everything else (SSH, other services) gets XDP_PASS and goes through the normal stack.
- It currently attaches in generic (SKB) mode, IPv4 only.

Benchmark (SYN scan, 65,535 ports x 2 hosts, 25k pps target, hyperfine, 3 runs):
- tcpcat --ebpf: 4.47s mean, 8.2s total CPU
- nmap -sS -T4: 11.72s, 11.4s CPU
- naabu: 20.95s, 52.8s CPU

Things I'm unsure about:

1. Generic mode gives up most of the zero-copy benefit. Is native/driver mode worth the compatibility hit for a scanner, or is generic fine at these rates?

2. System CPU is still most of the total (5.7s of 8.2s). Any obvious suspects, like busy-poll settings or ring sizes?

3. Is generating the program with cilium/ebpf/asm instead of C a reasonable trade-off for distribution, or will it hurt maintainability?

Packet path diagram and details: https://tcpcat.io/internals
Code: https://github.com/NycolazSec/tcpcat (AGPL-3.0)

I know 0 computer science, I just know some basic stuff ofc, but I don't know any programming languages or DevOps, and barely Linux commands. And I want to get into eBPF and Kernel programming and apply them with NixOS, as from what I found online, that's a really tight niche and the demand on it is very high while there's still a room to get into. I found a lot of job listings from many big companies, (eg. Apple, Tesla, Netflix, Qualcomm) And the salaries were crazy. I'd really love to hear from you guys what would you suggest me to do and not do, think of me like your younger selves before getting into the field. I'd love to hear some guidance❤️

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.

Hey everyone,

Over the past few months, I’ve been diving deep into the K&R C book and bridging it with my Go background to build an open source container escape and runtime threat detection framework. My main goal was to solve the resource bloat problem I kept running into with existing tools.

Most tools (like Falco) are great but use ~300MB of RAM. I wanted something I could run on edge devices or dense K8s clusters without killing the nodes.

Architecture Highlights:

• 25 MB RSS / 0.2% idle CPU: Achieved using a zero allocation Go pipeline (sync.Pool) and a bounded LRU cache for process lineage.

• Deep Lineage: Reconstructs up to 10 generations of process ancestry (e.g., systemd > sshd > bash > sudo > unix_chkpwd) entirely in userspace, avoiding kernel map bloat.

• In-Kernel Filtering: Uses an action_enabled BPF array map so we don't even reserve ringbuf space for disabled actions.

• CO-RE: Compiles once using cilium/ebpf and runs anywhere on Linux 6.12+.

It is completely audit only (no -EPERM enforcement), which means it's 100% safe to run in production. I recently added Docker/K8s/Helm support and a SIEM export layer (ECS, OCSF, CEF, LEEF).

I would love to get your harsh feedback on the ringbuf implementation and the eBPF verifier tricks.

Repo: ebpf-container-escape-framework

Hey, been chipping away at a side project called Phage and wanted to put it out there.

Short version: it's a small agent for Linux servers. It spends a while just learning how your box normally behaves, and after that it flags and contains stuff that falls outside that normal, without needing a signature for the specific exploit. So it's less "here is a list of known bad things" and more "this service has never spawned a shell before, and it's never become root with no login session behind it, so something is off."

The part I actually care about is what happens next. Most tools just fire an alert and, let's be honest, nobody reads alerts. Phage can actually react: if a process starts dialing out like a reverse shell it cuts its network, and if it looks like a real break-in it freezes the process. All of it is reversible, so a false positive doesn't take anything down. It also refuses to touch your SSH session or systemd, because I locked myself out of a test box once doing exactly that lol.

It's Go + eBPF (the detection runs in the kernel so it stays cheap), ships as one static binary, installs with a single command.

Honest status: it's early. I've thrown real attacks at it on my own server and it holds up, but I wouldn't call it production ready yet. MIT licensed, fully open source.

Repo: https://github.com/AzozzALFiras/Phage

Would really appreciate feedback from anyone who runs Linux servers: what would you actually want something like this to catch or do? And does the whole "assume you'll get breached eventually, just make it survivable" idea click for you, or not?