Best way to check for fentry attach support

Best way to check for fentry attach support

[Martin Kelly]

Hi all,

I'm trying to figure out the best way to handle the fact that 
fentry/fexit trampolines are not fully supported on all architectures 
and kernel versions. As an example, I want to be able to load an fentry 
if the kernel supports it, and a kprobe otherwise.

It's tempting to use libbpf_probe_bpf_prog_type for this, but on ARM64 
kernels >= 5.5 (when BPF trampolines were introduced) but before the 
most recent ones, loading an fentry program will pass, but attaching it 
will still fail. This also means that libbpf_probe_bpf_prog_type will 
return true even if the program can't be attached, so that can't be used 
to test for attachability.

I can work around this by attempting to attach a dummy fentry program in 
my application, but I'm wondering if this is something that should be 
done more generally by libbpf. Some possible ways to do this are:

- Extend the libbpf_probe API to add libbpf_probe_trampoline or similar, 
attempting attach to a known-exported function, such as the BPF syscall, 
or to a user-specified symbol.

- Extend the libbpf_probe API to add a generic libbpf_probe_attach API 
to check if a given function is attachable. However, as attach code is 
different depending on the hook, this might be very complex and require 
a ton of parameters.

- Maybe there are other options that I haven't thought of.

I have a patch I could send for libbpf_probe_trampoline, but I wanted to 
first check if this is a good idea or if it's preferred to simply have 
applications probe this themselves.

Thanks,

Martin

Re: Best way to check for fentry attach support

[Andrii Nakryiko]

On Tue, Sep 12, 2023 at 11:50 AM Martin Kelly
<martin.kelly@crowdstrike.com> wrote:
>
> Hi all,
>
> I'm trying to figure out the best way to handle the fact that
> fentry/fexit trampolines are not fully supported on all architectures
> and kernel versions. As an example, I want to be able to load an fentry
> if the kernel supports it, and a kprobe otherwise.
>
> It's tempting to use libbpf_probe_bpf_prog_type for this, but on ARM64
> kernels >= 5.5 (when BPF trampolines were introduced) but before the
> most recent ones, loading an fentry program will pass, but attaching it
> will still fail. This also means that libbpf_probe_bpf_prog_type will
> return true even if the program can't be attached, so that can't be used
> to test for attachability.

Right, because libbpf_probe_bpf_prog_type() is testing whether given
program type can be loaded, not attached.

>
> I can work around this by attempting to attach a dummy fentry program in
> my application, but I'm wondering if this is something that should be
> done more generally by libbpf. Some possible ways to do this are:
>
> - Extend the libbpf_probe API to add libbpf_probe_trampoline or similar,
> attempting attach to a known-exported function, such as the BPF syscall,
> or to a user-specified symbol.
>
> - Extend the libbpf_probe API to add a generic libbpf_probe_attach API
> to check if a given function is attachable. However, as attach code is
> different depending on the hook, this might be very complex and require
> a ton of parameters.
>
> - Maybe there are other options that I haven't thought of.
>
> I have a patch I could send for libbpf_probe_trampoline, but I wanted to
> first check if this is a good idea or if it's preferred to simply have
> applications probe this themselves.

It doesn't seem too hard for an application to try to attach and if
attachment fails fallback to attaching kprobe-based program. So I'd
prefer that over much more maintenance burden of keeping this "can
attach" generic API. At least for now.

>
> Thanks,
>
> Martin
>
>

Re: Re: Best way to check for fentry attach support

[Martin Kelly]

On 9/14/23 11:05, Andrii Nakryiko wrote:
> On Tue, Sep 12, 2023 at 11:50 AM Martin Kelly
> <martin.kelly@crowdstrike.com> wrote:
>> Hi all,
>>
>> I'm trying to figure out the best way to handle the fact that
>> fentry/fexit trampolines are not fully supported on all architectures
>> and kernel versions. As an example, I want to be able to load an fentry
>> if the kernel supports it, and a kprobe otherwise.
>>
>> It's tempting to use libbpf_probe_bpf_prog_type for this, but on ARM64
>> kernels >= 5.5 (when BPF trampolines were introduced) but before the
>> most recent ones, loading an fentry program will pass, but attaching it
>> will still fail. This also means that libbpf_probe_bpf_prog_type will
>> return true even if the program can't be attached, so that can't be used
>> to test for attachability.
> Right, because libbpf_probe_bpf_prog_type() is testing whether given
> program type can be loaded, not attached.
>
>> I can work around this by attempting to attach a dummy fentry program in
>> my application, but I'm wondering if this is something that should be
>> done more generally by libbpf. Some possible ways to do this are:
>>
>> - Extend the libbpf_probe API to add libbpf_probe_trampoline or similar,
>> attempting attach to a known-exported function, such as the BPF syscall,
>> or to a user-specified symbol.
>>
>> - Extend the libbpf_probe API to add a generic libbpf_probe_attach API
>> to check if a given function is attachable. However, as attach code is
>> different depending on the hook, this might be very complex and require
>> a ton of parameters.
>>
>> - Maybe there are other options that I haven't thought of.
>>
>> I have a patch I could send for libbpf_probe_trampoline, but I wanted to
>> first check if this is a good idea or if it's preferred to simply have
>> applications probe this themselves.
> It doesn't seem too hard for an application to try to attach and if
> attachment fails fallback to attaching kprobe-based program. So I'd
> prefer that over much more maintenance burden of keeping this "can
> attach" generic API. At least for now.

OK, it's easy enough to do it in the application, so we'll do that. Thanks!

>> Thanks,
>>
>> Martin
>>
>>