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

[Martin Kelly <martin.kelly@crowdstrike.com>]

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
>>
>>