https://github.com/osquery/osquery logo
Powered by
#ebpf
Title
a

Andrea

04/21/2023, 9:59 AM
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

alessandrogario

04/21/2023, 10:40 AM
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

Andrea

04/21/2023, 12:01 PM
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

alessandrogario

04/21/2023, 12:33 PM
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

Andrea

04/21/2023, 12:39 PM
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

alessandrogario

04/21/2023, 12:40 PM
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

Andrea

04/21/2023, 12:41 PM
gotcha
thank you
a

alessandrogario

04/21/2023, 12:43 PM
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

Andrea

04/21/2023, 12:45 PM
lol it worked ok actually 🙂
thank you that was the bit I missed
7 Views
Powered by