Flatcar driver loader support #2043
Conversation
|
Welcome @jepio! It looks like this is your first PR to falcosecurity/falco 🎉 |
|
/milestone 0.33.0 |
|
LGTM label has been added. Git tree hash: 0421b0ddb2fa71b52360617accb41bae4d749b5f
|
|
Closing and reopening to trigger the CI /close |
|
@jasondellaluce: Closed this PR. In response to 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. |
|
/reopen |
|
@jasondellaluce: Reopened this PR. In response to 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. |
|
This PR needs to be rebased. I'll do that for you. |
Relocate necessary tools from the kernel module build system to run using host dynlinker and libraries, so that compiling falco module on Flatcar works. Since Flatcar v2983.0.0, Flatcar ships with glibc-2.33, but the falco-driver-loader container is based on debian:buster and so has a much older glibc. This prevents some necessary tools within /lib/modules/*/build from working which causes the falco module to fail to compile using dkms. To make the tools work, we need to relocate them so we add patchelf to the falco and local dockerfiles. The relocation is based on the approach done by the sysdig agent-kmodule build system, but I'm unable to find the source code for it. The host linker and libs will be found at /host/usr/lib64, so we change the interpreter and rpath on the tools. The relocation happens on a copy of the tools which are then bind mounted at the right location. The result allows the module build to work. Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
Pre-built kernel modules/eBPF probes for Flatcar use the value of the OS VERSION_ID field as KERNEL_RELEASE in the filename. A specific kernel release version does not uniquely identify a Flatcar configuration, because Flatcar is image-based instead of package-based. Here's a more specific example: the same kernel version can be part of various Flatcar releases (across channels alpha/beta/stable) with differences in configuration. This is why we use the VERSION_ID value during offline builds with driverkit. Flatcar version numbers are all higher than 1500.0.0, so there is no risk of collision with kernel version numbers. When locally building the kernel module on the system, we have access to the correct kernel build directory at /lib/modules/$(uname -r)/build with the right configuration and so for that branch, we need to reset KERNEL_RELEASE=$(uname -r). See also the driverkit PR that introduces a builder for Flatcar: falcosecurity/driverkit#131 Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
leogr
force-pushed
the
flatcar-driver-loader-support
branch
from
715bdc7 to
8fe79ee
Compare
There was a problem hiding this comment.
Rebased.
cc @jasondellaluce Could you approve again please? 🙏
|
LGTM label has been added. Git tree hash: 9184469600670b71c8b0031ab67aeffc3df7a5a5
|
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jasondellaluce, jepio The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Thanks a lot! |
|
@jepio you are welcome :) and thank you again for your contribution 👍 |
In falcosecurity#2043 we've added logic for relocating tools on Flatcar when running falco-driver-loader in kmod mode. This logic is relevant for BPF mode, too, which is currently broken on Flatcar. Call flatcar_relocate_tools in BPF mode, too. Signed-off-by: Johanan Liebermann <jliebermann@microsoft.com>
In falcosecurity#2043 we've added logic for relocating tools on Flatcar when running falco-driver-loader in kmod mode. This logic is relevant for BPF mode, too, which is currently broken on Flatcar. Call flatcar_relocate_tools in BPF mode, too. Signed-off-by: Johanan Liebermann <jliebermann@microsoft.com>
In #2043 we've added logic for relocating tools on Flatcar when running falco-driver-loader in kmod mode. This logic is relevant for BPF mode, too, which is currently broken on Flatcar. Call flatcar_relocate_tools in BPF mode, too. Signed-off-by: Johanan Liebermann <jliebermann@microsoft.com>
What type of PR is this?
/kind bug
Any specific area of the project related to this PR?
/area build
What this PR does / why we need it:
This PR ensure falco-driver-loader supports Flatcar. There are two commits that address two parts of this:
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?: