Falco: BPF probe compile once run everywhere with BTF

[fntlnz]

This will likely become a proposal if it receives a good feedback here (like doing a :+1: counts as feedback )

What would you like to be added:

Adapt and compile our eBPF probe loader code to the BPF type format (BTF) - links below.

Why is this needed:

Some considerations first
One of the main barriers that new and old users encounter when trying to adopt falco is building either the kernel module or the BPF probe. To mitigate this we’ve been working on two main efforts over time:

• doing containerized builds to minimize the host dependencies
• having pre built kernel modules for a wide variety of kernels

Despite this, many users still struggle and in my opinion the experience in that area has a lot of room of improvement.

Moreover, in new-ish environments (recent kernel 4 and 5) using eBPF is becoming more and more common and honestly I expect that to become the default for Falco at some point. This also makes sense from a privileges point of view where we will only need capabilities for the bpf syscall .

Summary of Problems with our current approach

• difficult to just run falco because the compilation or the download might not go right
• kernel headers need to be installed on every host along with the clang tool chain that processes them
• sometimes having kernel headers and tool chain is just very hard or impossible (immutable environments)
• compiling is complicated, a single mistake and the user can’t load the loader and falco becomes useless
• wider attack surface because having to compile stuff for the kernel requires a tool chain in a container that can read kernel folders (e.g /lib/modules)
• difficult to distribute the “kernel side” of falco

The actual idea
After all these considerations I think that we need to adapt our current programs to take advantage of BTF (links below) in order to be able to compile once and run everywhere.

Read more about BTF here: https://www.kernel.org/doc/html/latest/bpf/btf.html and here https://facebookmicrosites.github.io/bpf/blog/2018/11/14/btf-enhancement.html

Next steps
After gathering some initial feedback here with this message I’ll open a formal proposal with an action plan

[fntlnz]

/assign @fntlnz

dibs

[leodido]

/assign @leodido

[sunil1783]

For porting falco on ppc64le ,we are facing issues while using containers of docker files having older OS kernel version and gcc-6/5 dependent packages.
So above suggested changes are required, to support latest OS kernel version and latest gcc versions.
https://github.com/falcosecurity/falco/issues/982
https://github.com/falcosecurity/falco/pull/932

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jnach]

Fundamentally, to offer an eBPF agent _to a system/kernel you do not yourself control_, I would imagine you inevitably have to solve this problem to drive eBPF adoption. I started down this path as well after an analysis of BCC optimizations, bravo and consider this an upvote.

[fntlnz]

Thanks @jnach - I'd also love some help here in case you are up to!

[jnach]

Interested...

[jnach]

Also _doing containerized builds to minimize the host dependencies_ - doesn't matter with eBPF, you can try an init container to make sure kernel-devel packages are there (which tends to break on update) _or_ you can crack the code on CORE. The second one is particularly scalable.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Issues labeled "cncf", "roadmap" and "help wanted" will not be automatically closed. Please refer to a maintainer to get such label added if you think this should be kept open.

[fntlnz]

I'm working on it.

[jnach]

Someday I might have enough free time to help lift, unfortunately the invisible hand says otherwise at the moment.