tracee-ebpf CO:RE roll out

[grantseltzer]

I'm thinking about what it would take to enable tracee-ebpf to utilize libbpf+CO:RE. We're already half way there since we use libbpf. A good source of information on this is this blog by the creator/maintainer of libbpf.

If I understand correctly the main thing we have to do is convert bpf_probe_read/bpf_probe_read_str calls to use BPF_CORE_READ and various other macros instead. There are also other helper functions in libbpf we should utilize, such as bpf_core_field_exists.

We have to be careful about supporting older kernels or ones that don't have BTF enabled. We should put CO:RE behind a feature flag in tracee-ebpf. The entrypoint for the tracee container can check the kernel for its version and for BTF support and toggle the feature flag accordingly.

The other very important thing is testing. We need infrastructure that we can test running tracee-ebpf on multiple kernels to verify CO:RE support is working properly

[yanivagman]

Correct.
libbpf already gives us most of the requirements to support CO-RE.
Like you said, the main work here will be to support kernels which don't support BTF.
One suggestion is to use libbpf 0.4.0 for the following feature libbpf/libbpf@a26ae1b
which should allow us to replace our READ_KERN macros and make the move to CO-RE easier.
Evenatually, we will probably need to have two embedded bpf codes in our tracee-epbf binary:
one for non-CO-RE kernels, for which tracee-ebpf will need to compile the code on the machine itself (so we need to embed the bpf.c sources like we do today)
and another for CO-RE kernels, for which tracee-ebpf can use a pre-compiled version (compiled bpf code, not sources)