BTFHub support #1125
BTFHub support #1125
Conversation
- tracee-ebpf: add BTFHub support
- tracee: new AttachTracepoint prototype (needed because of new libbpfgo)
- libbpfgo: update libbpfgo version due to osinfo arch support
|
BTFHub was added as a submodule inside 3rdparty/ directory. After initializing all submodules, you're able to either compile tracee without BTF files embedded (BTFHUB=0, which is the default option) or opt to set BTFHUB=1 and compile it with embedded BTF files. With the following snippet: All the BTF files from BTFHub are extracted, then tailored (to tracee.bpf.o) BTF files are encoded and, at the end, all the tailored BTF files are embedded into the go binary file. |
The correct embedded BTF file is written (and read) according to the running environment: |
|
Somethings worth mentioning.
After Ubuntu starts releasing BTF enabled kernels for all its LTS releases, we will be capable of embedding all BTF files needed in order to support the older kernels... and the new kernels won't need external BTF files. This would make the "BTFHub API" idea to loose strength since we wouldn't need to download BTF files from an online API. Everything will be already embedded. WDYT ? |
|
@rafaeldtinoco does this PR handle one of the following (or both): If so, let's link them to this PR (so they will also be closed when this is merged) |
|
Is there a way to test this on a machine with BTF enabled? |
not really.. Tracee won't try to load embedded file if there is a /sys/kernel/btf/vmlinux file available.. even if the go binary had the BTF file version for the running kernel (which is not the case for kernels that are BTF enabled). |
| func unpackBTFHub(outFilePath string, OSInfo *helpers.OSInfo) error { | ||
| var btfFilePath string | ||
|
|
||
| osId := OSInfo.GetOSReleaseFieldValue(helpers.OS_ID) |
There was a problem hiding this comment.
It might be a problem to use this API of OSInfo in tracee container (alpine based) as we will get the wrong distro release info (aquasecurity/libbpfgo#92)
There was a problem hiding this comment.
Let's discuss this at: aquasecurity/libbpfgo#92 (comment) so we have a single point to talk about it. IIRC we already addressed this in the past, but we can discuss in that issue you opened if you are okay.
There was a problem hiding this comment.
Even if we agree to use the mock osrelease solution, this PR will have to be updated, or the tracee container would not detect the correct osrelease (as it is based on an alpine container)
There was a problem hiding this comment.
If I understood correctly what you are saying, you mean that we have to make sure the mock is done to tracee container within this PR (and not other). This way, tracee container would run by default with LIBBPFGO_OSRELEASE_FILE setting correctly having the host information.
Is that what you meant ?
There was a problem hiding this comment.
This still needs to be addressed.
- embed files, or not, based in build tags (by @grantseltzer) - Makefile: CORE and STATIC as build time options - CORE=1 does not exist anymore: always embed CORE bpf object - STATIC=1 now really sets go build options for STATIC binary - BTFHUB=1 sets go build options for embedding BTFhub files
|
I'm closing this PR and opening a new one in order to have a cleaner view of reviews. I'll point this one there to keep history of discussions. |