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

As part of integrating Tracee as a library we would like to have the ability to use functions like 'missingKernelConfigOptions', 'checkRequiredCapabilities' etc.

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.