test321 #3
Comments
|
comment 2 |
ketank-new
pushed a commit
that referenced
this issue
Jul 21, 2020
valgrind reports: ``` ==75769== Syscall param bpf(attr->value) points to uninitialised byte(s) ==75769== at 0x4CA62A9: syscall (syscall.S:38) ==75769== by 0xC36BD8: sys_bpf (misc.h:38) ==75769== by 0xC36CC7: bpf_map_update_elem (scap_bpf.c:95) ==75769== by 0xC39D3E: set_default_settings (scap_bpf.c:1230) ==75769== by 0xC3A2C1: scap_bpf_load (scap_bpf.c:1371) ==75769== by 0xC2120D: scap_open_live_int (scap.c:294) ==75769== by 0xC2231C: scap_open (scap.c:720) ==75769== by 0xA64BF2: sinsp::open(unsigned int) (sinsp.cpp:475) ==75769== by 0xA6580A: sinsp::open(std::string) (sinsp.cpp:683) ==75769== by 0x90D9B8: sysdig_init(int, char**) (sysdig.cpp:1454) ==75769== by 0x90EF6C: main (sysdig.cpp:1692) ==75769== Address 0x1ffeffeaed is on thread 1's stack ==75769== in frame #3, created by set_default_settings (scap_bpf.c:1209) ==75769== ```
ketank-new
pushed a commit
that referenced
this issue
Jul 21, 2020
* More flexible way to build bpf probe in-container There are some cases where a user wants to use the BPF probe and run sysdig/falco/agent/etc from a container, but doesn't want to install kernel headers/sources on the host. We already had two versions of this--minikube and cos. Each had nearly identical steps of downloading the kernel sources, applying the running config, and building the ebpf program using the kernel sources as a basis. This refactors the minikube/cos steps to share common steps, as well as allowing for a more generic path that downloads the kernel sources in-container. To use it, set the environment variable BPF_USE_LOCAL_KERNEL_SOURCES to any value. In a docker run command, it would be set via: docker run ... -e BPF_USE_LOCAL_KERNEL_SOURCES=1 ... sysdig/sysdig I tested this with a locally built sysdig container and the following: 1. Minikube version v0.33.1: uname -a=Linux minikube 4.15.0 #1 SMP Fri Jan 18 22:39:33 UTC 2019 x86_64 GNU/Linux 2. COS Container-Optimized OS 69-10895.273.0 stable: uname -a=Linux mstemm-sysdig-testing-2 4.14.124+ #1 SMP Fri Jun 14 22:50:58 PDT 2019 x86_64 Intel(R) Xeon(R) CPU @ 2.30GHz GenuineIntel GNU/Linux 3. Amazon linux 2: uname -a=Linux ip-172-31-48-89.ec2.internal 4.14.123-111.109.amzn2.x86_64 #1 SMP Mon Jun 10 19:37:57 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux For #1/#2, the docker run command line was: docker run -it --privileged --net=host -v /var/run/docker.sock:/host/var/run/docker.sock -v /dev:/host/dev -v /proc:/host/proc:ro -v /boot:/host/boot:ro -v /lib/modules:/host/lib/modules:ro -v /usr:/host/usr:ro -v /etc:/host/etc:ro -e SYSDIG_BPF_PROBE="" ... For #3, added -e BPF_USE_LOCAL_KERNEL_SOURCES=1. All 3 could build the ebpf program. #1 and #3 had this error during the kernel config steps, but it's not a regression and didn't interfere with building the ebpf program: scripts/extract-cert.c:21:25: fatal error: openssl/bio.h: No such file or directory compilation terminated. * Add SYSDIG_ prefix to BPF_USE_LOCAL_KERNEL_SOURCES Convention that external env vars start with SYSDIG_.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
comment 1
The text was updated successfully, but these errors were encountered: