https://github.com/osquery/osquery logo
Join Slack
Powered by
Hello everyone, I am playing with BPF these days a...
# ebpf
a
Hello everyone, I am playing with BPF these days and I see we can trace kernel’s function calls via 
kprobe
. I don’t think we can trace a returning function with the 
kretprobe
though. Is that correct or am I missing something ? my use case would be tracing 
tcp_v4_connect
the same way 
bcc/tools/tcpconnect
does, which looks better for tracing local/destination address+port than tracing connect() bind() accept() separately (again..unless I missed something 🙂 ). Any pointer would be appreciated! thanks
a
You can, provided you can correctly specify a prototype for that function according to the simple DSL that the library supports
I have experimental branches for those features, but they are mostly a spare time project as of now
With the current ebpfpub code, it should however be possible to trace it The prototype is simple enough:
Copy code
int tcp_v4_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len);
Copy code
tob::ebpfpub::IFunctionTracer::ParameterList parameter_list = {
    {
      "sk",
      tob::ebpfpub::IFunctionTracer::Parameter::Type::Integer,
      tob::ebpfpub::IFunctionTracer::Parameter::Mode::In,
      8U
    },

    {
      "uaddr",
      tob::ebpfpub::IFunctionTracer::Parameter::Type::Buffer,
      tob::ebpfpub::IFunctionTracer::Parameter::Mode::In,
      "addr_len"
    },

    {
      "addr_len",
      tob::ebpfpub::IFunctionTracer::Parameter::Type::Integer,
      tob::ebpfpub::IFunctionTracer::Parameter::Mode::In,
      8U
    }
  };
I guess the biggest problem here is that we do not have the definition for 
struct sock
You could attempt to capture it as a raw buffer with
Copy code
{
      "sk",
      tob::ebpfpub::IFunctionTracer::Parameter::Type::Buffer,
      tob::ebpfpub::IFunctionTracer::Parameter::Mode::In,
      1U // <- buffer size here
    },
But you won't be able to dereference pointers within the struct sock ptr
The library was mainly written to generate probes for syscalls, where this problem never present itself
a
Interesting. That would have been my next step as I saw one of your draft PRs about getting capabilities events. I am not sure I understand where the 
kretprobe
comes into play in the library though 🤔
a
I think it's better to use both the kprobe and kretprobe
the addr_len is available when you are in the kprobe
if you only trace kretprobe you'll miss some parameters
More about that: from our code we can't really inspect much state in the kernel, and we have to rely on what we can capture through the function signature
a
sorry I wasn’t clear. I mean I can see there is a 
tob::ebpfpub::IFunctionTracer::createFromKprobe
API in ifunctiontracer.h but I don’t see anything about tracing 
kretprobe
More about that: from our code we can’t really inspect much state in the kernel, and we have to rely on what we can capture through the function signature
yeah that’s why I reckon tracing kretprobe for that specific call is necessary 🤔
a
the function tracer will automatically trace both the kprobe and the kretprobe
I did not understand the question, thought you were asking to just trace the kretprobe and avoid the kprobe
a
gotcha
thank you
a
https://github.com/trailofbits/ebpfpub/blob/main/ebpfpub/src/ifunctiontracer.cpp#L106-L121 EDIT: could not get selection to work, ended up editing the link manually 😄
a
lol it worked ok actually 🙂
thank you that was the bit I missed
13 Views
Open in Slack
PreviousNext
Powered by