Open grantseltzer opened 2 years ago
I liked this approach a lot!
@rafaeldtinoco @yanivagman What do you think about shelling out to bpftool feature
in order to detect kernel features? I was hoping there'd be some large bpf file that bpftool uses to load and detect errors, but the programs are actually inlined as BPF byte code within bpftool. We can recreate this functionality but that will require adding API for activating every single bpf feature first. Additionally we'd have to maintain this, and it'd be updated often.
The downside is that we'd require bpftool as a runtime dependency. Perhaps we can embed it at compile time?
I don't like the idea of relying in a specific userland tool output (even if we embed it into tracee binary and/or tracee container). I think we should approach this by attempting to load very simple eBPF programs, split by different objects, and take conclusions on that (even if not complete as bpftool does)). @yanivagman thoughts ?
I agree with @rafaeldtinoco. We should fibd the way to look for features in libbpfgo
From @yanivagman: We recently added the new "dependencies" field into the event definition. This concept of dependencies can be expanded to describe which BPF features are required for an event to work, such as BTF support, LSM bpf programs support, ring buffer support, or a minimal kernel version. We can query which bpf features are available on tracee init (we already do that for BTF support and the kernel version), and verify that an event chosen by the user satisfies these dependencies. To support "legacy" kernels for already existing events, we can have two (or more) different "flavors" of bpf programs for the SAME event. We can then automatically choose the program that best fits the environment where tracee runs by adding a new dependency field to the probe struct (same concept of events dependencies, but this time for probes and not for events).