r/eBPF

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

Most Linux debugging tools answer one question well.

• top tells you who's using the CPU.
• strace tells you which syscalls are happening.
• perf tells you what the CPU is doing.
• vmstat tells you about memory.

But when something weird happens, I always found myself jumping between half a dozen tools and trying to correlate timestamps manually.

So I started building ASCENT.

The idea is to visualize the entire stack simultaneously instead of looking at one layer at a time.

Current implementation includes 9 live layers:

• System metrics (/proc)
• Process activity
• Syscall statistics
• Kernel datapath (vfs_read, tcp_sendmsg, etc.)
• Hardware PMU counters
• Scheduler dynamics
• Memory management
• Lock contention
• IRQ / softirq / workqueue causality

Everything is streamed into a single terminal dashboard.

A few things that made this project fun:

• Dashboard written in pure x86-64 NASM assembly
• No libc
• No runtime
• No allocator
• Uses ANSI escape sequences for rendering
• eBPF CO-RE sensors
• PMU counters through perf_event_open()
• Fixed 60-byte binary event protocol over a FIFO between the loader and the renderer

The goal isn't to replace tools like perf or bpftrace. It's to answer a different question:

>

There are still a lot of things left to build (Intel PT, KVM tracing, AI-based correlation, etc.), but the core pipeline is working.

I'd love feedback from people who work with Linux internals or eBPF.

GitHub: https://github.com/Kritagya123611/Ascent

i have been working on a research project around LangChain agent runtime security and wanted to share it here and hear from people who are actually building with LangChain.

the problem i am trying to address is that when an LLM calls one of your registered tools in an unintended way, process level monitoring tells you a suspicious syscall happened but it doesnt tell you which tool caused it. for agentic workloads where different tools have genuinely different trust levels, that granularity gap matters.

the approach is to hook into CPython's internal runtime state via eBPF to track BaseTool execution boundaries and attribute every syscall back to the specific tool that caused it, file opens, network connections, process spawns, with per-tool enforcement policies applied at the kernel level via LSM hooks. no code changes needed in your agent.

current support is CPython 3.12, LangChain and LangGraph. the reason scope is this narrow is because generalizing hook point discovery across different runtimes and versions is the hard unsolved part, and i didnt want to overclaim anything before that is solved.

this is not production ready and there is a lot of work still ahead. but i wanted to put it out and hear from people building LangChain services. how are you thinking about monitoring and enforcement for your tools today? is tool level attribution something that would matter for your workload?

would also genuinely welcome collaborators if anyone finds this direction interesting.

https://github.com/altugbozkurt07/ironscope

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/