Add embed directive to embed the compiled CORE bpf object into go binary #818
Conversation
|
how is this fixing #783? |
|
I've pushed a commit that seems to be the only way to conditionally use the embed directive. I use a "core" build flag with two different files that build depending on if the tag is present or not. |
|
I've pushed a change which reads the CO:RE binary straight from the embedded go binary into a slice of bytes, and loads it using |
|
After discussing with @yanivagman we came to the agreement that for the sake of optimal portability, the CO:RE should always be built (since BTF kernel is not required, just the vmlinux.h file) and embedded. At runtime tracee-ebpf should check if it's running on a BTF enabled kernel (see if /sys/kernel/btf exists). If there is BTF, use that embedded CORE binary. If not, look for the compiled bpf object, and if it doesn't exist attempt to build it from the embedded source. I will push a commit with this soon. @itaysk @rafaeldtinoco any thoughts? |
+1. Will start giving us the flexibility we want/need.
So, wrapping up.. with your change we will have:
And after BTFHUB we will have (@yanivagman pls confirm if this is right):
I like it =) |
|
@rafaeldtinoco Just what I had in mind :-) I will turn your comment into an issue as part of merging this PR |
|
@rafaeldtinoco LGTM, just one thing I'm not sure about:
Do we really want to look for bpf.o only then? |
Yes, exactly. Thanks for clarifying it and implementing! |
Isn't it late to look for BPF support in running kernel, at this stage? Also, I agree with @yanivagman that specific object file, if present, should override the embedded one |
| @@ -132,7 +127,6 @@ $(OUT_DIR)/tracee.bpf.core.%.o: $(BPF_SRC) $(LIBBPF_HEADERS) $(CMD_CLANG) | |||
| -DLINUX_VERSION_CODE=$(LINUX_VERSION_CODE) \ | |||
| -target bpf \ | |||
| -O2 -c -g -o $@ $< | |||
| endif | |||
| else | |||
There was a problem hiding this comment.
DOCKER mode seem to be inconsistently supported for the obj files now. We need to be able to build both obj targets with docker and without. currently I think it's not possible? (haven't tried, just by reading the code)
If I'm right, would be easier to implement, and also more readable to just copy the same stanza from the other targets (e.g the OUT_BIN target) where the DOKCER variance is inside the target, not outside.
There was a problem hiding this comment.
is it resolved? I don't see any change in the code
There was a problem hiding this comment.
Ugh, I forgot to git push... Sorry about that.
CO-RE phase:
If /sys/kernel/btf exists then BPF support is already there (so we are checking it in the first item). This item is to check for old kernels that have BPF support but no BTF support, they would need the BTFHUB (bellow).
Yes, if environment variable provided, we should use that object no matter what, I'm +1 on that as well. |
Signed-off-by: grantseltzer <grantseltzer@gmail.com>
Signed-off-by: grantseltzer <grantseltzer@gmail.com>
Signed-off-by: grantseltzer <grantseltzer@gmail.com>
Signed-off-by: grantseltzer <grantseltzer@gmail.com>
Signed-off-by: grantseltzer <grantseltzer@gmail.com>
… bpf source, add logic for checking if bpf is enabled Signed-off-by: grantseltzer <grantseltzer@gmail.com>
|
Opened #833 |
tracee-ebpf/main.go
Outdated
| // getBPFObject finds or builds ebpf object file and returns it's path | ||
| func getBPFObject() (string, error) { | ||
| // getBPFObjectPath finds or builds ebpf object file and returns it's path | ||
| func getBPFObjectPath() (string, error) { |
There was a problem hiding this comment.
As discussed, we want to have to TRACEE_BPF_FILE to be looked also in core mode. I think that we can call this function an exit before the binary build (or just split it into two functions)
Signed-off-by: grantseltzer <grantseltzer@gmail.com>
Signed-off-by: grantseltzer <grantseltzer@gmail.com>
|
@itaysk I don't fully understand it either, I don't have the strongest make knowledge. Doesn't having OUT_BPF allow for calling the |
Handles #783
Signed-off-by: grantseltzer grantseltzer@gmail.com