Use bpf_probe_read_user and bpf_probe_read_kernel helpers

[yanivagman]

On newer kernels (>=5.5), there are four new bpf helper functions which are safer to use. These are: bpf_probe_read_user(), bpf_probe_read_user_str(), bpf_probe_read_kernel(), bpf_probe_read_kernel_str() (For more info about these helpers also see https://github.com/iovisor/bcc/blob/master/docs/reference_guide.md#data)

We should start using these functions instead of bpf_probe_read[_str]() functions as libbpf will automatically fall back to bpf_probe_read[_str]() if bpf_proberead{kernel, user}[_str]() are not supported on older kernels, so it's always safe to use bpf_proberead{kernel, user}[_str]() and not worry about kernel version compatibility

[cdelzotti]

Hello ! Is this issue still relevant ? If so, is it possible to work on it ?

[yanivagman]

Hello! This was partially implemented as can be seen here: https://github.com/aquasecurity/tracee/blob/main/pkg/ebpf/c/tracee.bpf.c#L324 However, we still don't make use of xxx_str() functions, and xxx_kernel[_str].

So yes! You can go ahead with this one. I think the challenges here are to make sure things work as expected with the new helpers, and distinguishing user pointers from kernel pointers.

[cdelzotti]

Sorry for the long delay, I got caught in school projects and exams. I see the problem and I understand what to do, but I don't see how to verify what I'm doing. Tests seem to have the same outputs whether I use kernel_str() or user_str(). How can I be sure to do not make a mistake ?

[yanivagman]

We actually didn't use these helpers to this point, so I guess verifying that the output isn't changed is a good start. As a test, I would try calling the user_str()helper for a kernel string, and vice versa to see if any error pops. In the code review we will then need to make sure that indeed user pointers are read using user_str() and kernel pointers with kernel_str()

[yanivagman]

Already done in #3952