Adoption of our kernel drivers

[Andreagit97]

Hi all! I'm a Falco Maintainer and I would like to collect some feedback!
More precisely, we would like to understand the adoption of our kernel drivers.
This would help us plan future improvements and understand where to focus our efforts.
If you could find a few seconds to answer the poll it would be amazing! Thank you all! (edited)

[cccsss01]

I am interested in a decision tree, like what best suites or needs, one of the things being the performance/resource cost, comparatively, for moderneBPF, kernel, auditd.

[Andreagit97]

ei @cccsss01 the idea here is:

Kernel module

PRO

• is the most lightweight solution (it puts less overhead in your system when you run it)
• is the only driver we support for kernel versions < 4.14

CONS

• Is not supported in some environments (e.g. GKE clusters)
• It is not statically verified by a verifier like in eBPF, so we can say that this solution is more error-prone and less secure to use in production.
• We try to build a specific kernel module for as many as possible kernel versions/distro, but we cannot build it for each existent combination so it's possible that is not available for your system.
• the kernel module is not shipped with Falco so you need to download it or compile it on the fly.

Legacy eBPF

PRO

• use eBPF technology so it is more secure than the kernel module
• In some environments (e.g. GKE with kernel version <5.8) is the only supported driver

CONS

• We try to build a specific ebpf probe for as many as possible kernel versions/distro, but we cannot build it for each existent combination so it's possible that is not available for your system. (Same issue of the kmod)
• it is less lightweight than the kernel module and also slightly less lightweight than the modern eBPF probe.
• the ebpf Probe is not shipped with Falco so you need to download it or compile it on the fly.

Modern eBPF

PRO

• use eBPF technology so it is more secure than the kernel module
• is slightly more lightweight than the legacy ebpf probe (but it is less lightweight than the kernel module) -> If you have a kernel 5.8 there is no reason to run the legacy ebpf probe.
• it uses the CO-RE technology so we build a unique probe shipped directly inside the Falco binary, no need to download or compile anything

CONS

• It requires a kernel version >= 5.8
• it is less lightweight than the kernel module

In all the above points with more lightweight I mean that the driver should put less overhead in your system when you run it, but please pay attention, this doesn't mean that Falco will run "better" (i.e. with fewer drops) it just means that your host should run all your applications with less overhead and so faster

[incertum]

@Andreagit97 few suggestions:

Mention that for kernel modules the kernel side performance overhead is not accounted for if you check resource utilization using ps or htop, but it is accounted for in legacy eBPF and modern eBPF. Measuring the actual impact of kernel modules is also more difficult and you risk crashing the kernel.