Feature idea: use eBPF to get stacktrace of the socket calls in the process responsible for connections

[laundmo]

Heyo! I really like what i'm seeing so far, RustNet hits the balance of "just enough details to be useful, not wireshark levels of data" for me.

What i really love is the process attribution. However, sometimes its still really hard to know why a process is opening connections.

It would be incredibly cool if RustNet could show the stacktrace leading to the socket open+recv of a connection. I know this is techinically something possible to get using eBPF since eBPF is used in a lot of tracing/observability, but what i don't know: is it possible to correlate that with the packets?

In any case, i just wanted to put the idea out there, its a bit of a crazy one as i know the eBPF based tracing tools are pretty complex in and of themselves. But i wanted to throw the idea out there in case it seems like a interesting topic for you or anyone to dig into.

[domcyrus]

Hi @laundmo, thanks a lot for opening this issue!

I do think this would be a very cool feature, but I see some major obstacles that would likely limit it to very specific, custom-tailored setups.

The biggest one is stack unwinding. Out of eBPF you basically have two options:

• frame pointers (-fno-omit-frame-pointer), but that only works well if every binary and all the shared libraries in the call chain are built with them. In the past people didn't want to pay the cost for it, so unless you control the builds yourself (e.g. Gentoo where you compile everything) it's unreliable (https://developers.redhat.com/articles/2023/07/31/frame-pointers-untangling-unwinding).
• DWARF based unwinding, which works without frame pointers but is far more complex and expensive, and doing it from eBPF is a real project in itself.

And there are more gotchas, e.g. things that aren't compiled, or go (golang) with its gazillion of goroutines mapped onto a few native threads. Plus it would be linux only.

I'd like to keep RustNet a bit tight on features and don't think it should become a profiler. But a smaller, on-demand version could be kind of cool but maybe not continuous profiling, just "show me the stack that opened this connection" as an extension of the process attribution that is already there. perf/bpftrace already cover the "grab a stack at a socket call" part, and at socket-open time the kernel hands you the connection tuple anyway, so mapping isn't the hard part. It would mostly be about wiring it into the connection view.

That said, it is also pretty security sensitive with extra capabilities, landlock sandboxing, symbolication, poking at other processes etc., and therefore I don't think this is a good candidate for a quick PR. But I'll definitely think a bit more about this idea so thanks again for the good suggestion!