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); }

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

We currently only check for CAP_SYS_ADMIN when running Tracee (https://github.com/aquasecurity/tracee/blob/main/tracee-ebpf/main.go#L885), which was correct for old kernels.
For newer kernels, CAP_SYS_ADMIN was split into combination of 3 other capabilities:
CAP_BPF, CAP_PERFMON and CAP_NET_ADMIN as described in https://lwn.net/Articles/820560/, and https://lwn.net/Articles/822362/
Update check

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

Almost every single BPF application out there has to implement bumping RLIMIT_MEMLOCK. What's worse, starting from some recent kernel version, RLIMIT_MEMLOCK is not necessary anymore for loading BPF programs and maps. Instead of asking all users to implement this detection logic and RLIMIT_MEMLOCK adjustment, do a sensible thing automatically:

• on older kernels, bump RLIMIT_MEMLOCK to infinity

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

CPU usage, PPS, latencies, etc.

When the k8s subcommand notices that a container is deleted, it keeps the tracelet for one minute. Directly retire the tracelet without any timeouts after dumping it a final time and store the rendered string compressed in a second list (which has a maximal length, appending if full will push the oldest element out).
If the API functions for dump, close etc can't find an active tracelet,