-
Notifications
You must be signed in to change notification settings - Fork 164
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] scap bpf engine requires API VERSION major bumps when it shouldn't #1283
Comments
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle stale |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle stale |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle stale |
/remove-lifecycle stale |
Describe the bug
When the scap bpf engine loads the
.o
file it scans all elf sections. Right now when the engine finds a new filler section it expects to have the corresponding enum in userspace tableslibs/userspace/libscap/engine/bpf/scap_bpf.c
Line 596 in dc4ab16
but this is not always true. Consider this example:
Let's imagine
SCAP_MINIMUM_DRIVER_SCHEMA_VERSION
is like today:and we have a driver with SCHEMA VERSION
2.0.0
. Now we add a new filler like in this PR #1256sys_listen_e
and we bump the driver SCHEMA VERSION to2.1.0
. When libscap tries to load the new.o
with SCHEMA_VERSION2.1.0
it will fail because it will find asys_listen_e
section not known and will printinvalid filler name
. For this reason, when we add a new filler we need to bump also a major for the API VERSION until we fix this issuethis issue happens when we use an old libscap version and a driver with at least one new filler, not a very common case but BTW it is a bug.
How to reproduce it
Build libscap with the commit before this PR and build the bpf probe over this PR, you will see the
invalid filler name
error when you load the bpf probeThe text was updated successfully, but these errors were encountered: