Title
#general
p

Prateek Kumar Nischal

10/06/2020, 4:36 PM
Also, would the experimental bpf based implementation help in this regard so that we can rule out most of noise in the kernel space and not let it enter the full blown processing within osquery. I would be really interested in that. PS: I am not using the managed audit config and letting osquery manage the audit config as we kind of need some globbing patterns in the file patterns.
a

alessandrogario

10/06/2020, 4:59 PM
The BPF support (https://github.com/osquery/osquery/pull/6571) only implements bpf_process_events and bpf_socket_events Implementing FIM again would require additional work
p

Prateek Kumar Nischal

10/06/2020, 5:35 PM
I got really interested into the bpf stuff when I came across it and then saw this PR and got even more excited about it 😄 . Was there a significant resource utilization improvement while using bpf with the process_events table.. ? if yes, then that might be a good route, atleast for the future.
a

alessandrogario

10/06/2020, 7:19 PM
You can try out the packages i uploaded in the #ebpf channel!
7:19 PM
i will update them with the next release 4.5.1
7:23 PM
But back to memory usage, depends on the hardware
7:23 PM
we have to use per-cpu maps to store data
7:25 PM
it's 4 buffer storages (to store strings like paths or buffers like sockaddr_in) of 4096 (configurable) slots of 4k bytes each (not configurable) for each cpu core
7:26 PM
plus the perf_events ring buffer of 2^12 (configurable) bytes, also per cpu core
7:26 PM
there is also an additional small map for each syscall we trace but the size is really tiny
7:27 PM
so if you have a monster machine with 64 core then it's going to use quite a lot of memory
7:27 PM
main issue is that with bpf you can't block or pause the execution forever, so the best approach is to just save data without having to rely on locks
7:29 PM
so we basically use per-cpu maps that basically save data like this: map[cpu_index][key] = value