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
