ebpf

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, users of the library need to explicitly call unix.Setrlimit to increase the process' maximum amount of memory available for memlocking eBPF maps. A series of patches recently landed in kernel v5.11 that switches bpf map memory accounting to be cgroup-based. As far as I understand, the consequence for userspa

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

It appears that the RedBPF toolchain imposes currently undocumented restrictions on map value types that go beyond those expressed by the generic constraints:

• All variants of an enum must have the same size in memory.
• Struct fields are (mostly?) required to be aligned to multiples of 32 bits, though sometimes 64-bit alignment is required, and some structs don't work at all despite their fi

Since the kernel's libbpf seems to handle .text ELF sections gracefully, we should probably do that too.

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

CPU usage, PPS, latencies, etc.