-
Notifications
You must be signed in to change notification settings - Fork 169
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
fix(driver): simplify exe_upper_layer extraction #1960
Conversation
Signed-off-by: Andrea Terzolo <[email protected]>
Perf diff from master - unit tests
Perf diff from master - scap file
Heap diff from master - unit tests
Heap diff from master - scap file
|
Please double check driver/SCHEMA_VERSION file. See versioning. /hold |
/hold we still have an issue in the kmod, it seems like |
driver/ppm_fillers.c
Outdated
#endif | ||
return false; | ||
|
||
// WARNING: this could cause undefined behavior if the upper dentry is not immediately after the vfs_inode |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is exactly what is happening, not clear why...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks @FedeDP for the help!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it was a random access memory due to a wrong pointer management
Signed-off-by: Andrea Terzolo <[email protected]> Co-authored-by: Federico Di Pierro <[email protected]>
Perf diff from master - unit tests
Perf diff from master - scap file
Heap diff from master - unit tests
Heap diff from master - scap file
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1960 +/- ##
=========================================
Coverage ? 51.00%
=========================================
Files ? 310
Lines ? 39570
Branches ? 17714
=========================================
Hits ? 20183
Misses ? 14366
Partials ? 5021 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, now it should be ready for review!
#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 18, 0) | ||
struct super_block* sb = _READ(dentry->d_sb); | ||
#else | ||
struct super_block *sb = _READ(inode->i_sb); | ||
#endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@therealbobo @loresuso It's unclear why we need this distinction...why cannot we take the superblock always from the dentry
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR LGTM! Thanks andre!
Once ☝️ gets an answer, i am ready to approve :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I remember it was a bit of trial and error. Something changed in OverlayFS in kernel 4.18 but I can't recall at the moment, trying to look around and I'll keep you posted.
Do we have tests to run if we try to get it always from the dentry
? We could try that in the meantime in my opinion, to check whether it is working as expected
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes in our current CI, we have 2 tests for it that are running on a kernel version > 4.18... Moreover, I tested it on at least 3 different machines during the implementation and this seems fine 🤔 I expect the dentry always to have a reference to the superblock, am I missing something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes the dentry should always have a reference to the superblock. Anyway, is it hard to add another kernel version for testing that is less than 4.18?
Coverage for this would be really helpful
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unfortunately at the moment, we don't have a setup for these machines. But in this case, I touched the ifdef for kernels >= 4.18 so the kernels < 4.18 should be untouched
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't remember the exact reason and it was the outcome of some trial and error. BTW I tested (with the driver_tests
framework) your implementation with 4.14, 4.17, 4.20, 5.4, 6.2,6.9 e 6.10 kernels and it seems to work just fine 😄
Mentioning #1409 to have github link them, and have more context. |
/hold |
Signed-off-by: Andrea Terzolo <[email protected]>
Perf diff from master - unit tests
Perf diff from master - scap file
Heap diff from master - unit tests
Heap diff from master - scap file
|
Driver test results: https://github.com/falcosecurity/libs/actions/runs/10056427915 x86
arm64
/unhold |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/approve
LGTM label has been added. Git tree hash: b00a255627fc70caed6b0fd5733b3cadc6e620d5
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Andreagit97, FedeDP 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 |
/milestone 0.17.3 |
/milestone 7.2.1+driver |
What type of PR is this?
/kind bug
/kind cleanup
Any specific area of the project related to this PR?
/area driver-kmod
/area driver-bpf
/area driver-modern-bpf
Does this PR require a change in the driver versions?
No
What this PR does / why we need it:
This PR provides a fix for falcosecurity/falco#3276.
The page fault was due to a backport in RHEL9.
More in detail this commit torvalds/linux@0af950f was backported to kernel versions older than 6.5.
So when our drivers run this code:
they enter in the
#elif LINUX_VERSION_CODE < KERNEL_VERSION(6, 5, 0)
, they try to dereferenceoe->flags
but the fieldflags
is no more there. This is bad for every driver because we are reading random memory but it is even worse for the kmod because it could lead to undefined behavior (and so a host crash) if the address is not aligned.Even with the new approach proposed with this patch, we are still subject to possible crashes... if the layout of the
struct ovl_inode
changes, and the__upperdentry
field is not immediately after thevfs_inode
field, the following code could cause undefined behaviors:Just for reference, this is the actual layout of the
struct ovl_inode
Which issue(s) this PR fixes:
Ref falcosecurity/falco#3276
Special notes for your reviewer:
Does this PR introduce a user-facing change?: