bpf

Is your feature request related to a problem? Please describe.

I fiddled around with bpftrace to write internal documentation for my colleagues on how to use it. I chose tracepoint:syscalls:sys_enter_mkdir as a suitable tracepoint for a simple demo, and wrote this code:

bpftrace -e 'tracepoint:syscalls:sys_enter_mkdir { printf("mkdir %s %o\n", str(args->pathname), args->mode); }

Currently we have just one type of docs which are "reference" documentation. We should add a "how-to/tutorials" section with goal-driven content. We can start by drawing already available content:

https://blog.aquasec.com/kubernetes-runtime-security-ebpf
https://blog.aquasec.com/tracee-runtime-malware-alerts-aqua-postee
https://blog.aquasec.com/runtime-security-tracee-rules
https://github.co

At the moment of writing this issue, kubectl trace only supports X86-64 as target architecture.

The tool should be able to schedule bpftrace programs against all the architectures supported by bpftrace, that are X86-64 and arm64 (aarch64) see the Cmake definition.

To achieve that we n

kinvolk/inspektor-gadget#163 introduced support for a new hook mode based on NRI (Node Resource Interface). Currently this mode only works if the user explicitly pass the --hook-mode=nri option and it's not considered when --hook-mode=auto is used.

Inspektor Gadget should detect if containerd v1.5+ is used as runtime and set HOOK_MODE="podinformer" in the followin

Can we get some performance comparison between polycube and using standard linux facilities (NAT, iptables, etc.)?

CPU usage, PPS, latencies, etc.

Feature Request

Short Description
Currently documentation mentions to only install bcc and doesn't specify that the version should be 0.21.0 or greater (here https://github.com/kubearmor/KubeArmor/blob/main/getting-started/kubearmor_vm.md), this causes KubeArmor failing in initializing system monitor upon deployment if the user installs lower version of bcc (for eg: using package manage

https://github.com/aquasecurity/libbpfgo/blob/main/helpers/osinfo.go seems to be untested. It would be helpful to add some unit tests to cover certain scenarios.

nhi currently supports only systemd