We have a new BPF PoC here: <https://github.com/os...
# ebpf
a
We have a new BPF PoC here: https://github.com/osquery/osquery/pull/7773 Test packages: https://github.com/osquery/osquery/actions/runs/3132085206 TLDR: With BTF (built-in kernel debug symbols, in kernels >= ~5.3) we can now read kernel structures while also respecting the osquery guidelines of having no external dependencies. This means we no longer need to trace a large amount of system calls, which was solved by auto-generating the BPF probes using LLVM IR. The new probes are written in C! We have some additional advantages compared to other solutions, like being able to inspect private kernel types (thanks to the debug info we are parsing). If there is interest and some spare time during the next office hours, I'll briefly walk over this PR and explain what it contains, how it was built and why. It still requires some work, and it's currently marked as an experiment and not a stable feature (more on this in the PR description). As previously stated it is going to require newer kernels, so we may still have to keep the current implementation for a while
cc @Artemis Tosini
a
Nice, I'll look at it
a
The TLDR: 1. https://github.com/trailofbits/btfparse reads
/sys/kernel/btf/vmlinux
and converts it to a C header file 2. https://github.com/trailofbits/ebpf-common is used to allocate the perf events (in this case just sched:sched_process_exec), the maps (1 per-cpu map to replace the stack and 1 map for the event id counters), the perf outputs to send data to our usermode process 3. CMake will then take that sched_process_exec.c file and create a string out of it 4. ebpf-common again: the IClangCompiler class gets the string we just created + the defines for the maps we generated, then the bytecode is loaded
We already have both ebpf-common and btfparse inside osquery, so we can create additional tables/tracers directly in osquery core
I rushed to get this PoC working, so there are still some things to fix
a
I've been using the cgroup name since not all runtimes use cgroup names that make sense other than as an index into some runtime-specific table and it's possible to have mulitple runtimes installed on a single host