libs
libs copied to clipboard
falcosecurity
BPF probe compile once run everywhere with BTF
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
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
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.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
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.
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.
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.
Someday I might have enough free time to help lift, unfortunately the invisible hand says otherwise at the moment.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community. /close
@poiana: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue with
/reopen.Mark the issue as fresh with
/remove-lifecycle rotten.Provide feedback via https://github.com/falcosecurity/community. /close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
@leogr: Reopened this issue.
In response to this:
/reopen /remove-lifecycle rotten
We still want this :)
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
If i understand correctly, we "only" need to port libscap to libbpf; libbpf right now supports CO-RE, but it mandates a kernel with BTF type information and clang/llvm 10+ (build only dep). See here for details: https://github.com/libbpf/libbpf#bpf-co-re-compile-once--run-everywhere
Here is a nice demo app that uses libbpf and CO-RE: https://github.com/libbpf/libbpf-bootstrap#bootstrap
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
The business need is and I think always will be a moving target here, libs or not. You can: A: Solve for unknown kernel with (likely) BTF, libs or not, it's still compiled for a specific kernel version. Maybe there is some kind of hook possible to hang with updates? It's hard to say. B: Have kernel solve for you by supporting specific versions, which is also difficult from an update/security perspective as an offering.
Hi all 🖖 I wrote down some ideas about a new BPF probe. If you are interested, you can take a look here :eyes:
We are using the software in depth.We believe that using kernel modules to adapt to lower versions of the kernel is still just needed, but libbpf is a trend. Do you have any plans to replace libbpf.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
We had this one https://github.com/falcosecurity/libs/issues/513 to track the syscall support of the modern BPF probe, and now we have this PR https://github.com/falcosecurity/falco/pull/2282 in Falco, that I will enrich with some info when we will be ready to release modern bpf packages
@leogr: Closing this issue.
In response to this:
Closing in favor of #513
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.