fix(driver/bpf): fixed a couple of verifier issues. #1896
Conversation
poiana
added
kind/bug
|
Please double check driver/SCHEMA_VERSION file. See versioning. /hold |
| @@ -571,236 +571,158 @@ FILLER(sys_poll_x, true) | |||
| return bpf_poll_parse_fds(data, false); | |||
| } | |||
|
|
|||
| #define MAX_IOVCNT 32 | |||
| #define MAX_IOVCNT_COMPAT 8 | |||
| #ifdef CONFIG_COMPAT | |||
There was a problem hiding this comment.
Only real downside of the patch (except for its ugliness probably :D ) is that we will have max iovec count of 8 when config compat is enabled; this is needed because we must have a constant to be able to unroll the loops below. Not a big deal; this is only on the old ebpf probe.
| if (curr_shift > SCRATCH_SIZE_HALF) | ||
| break; | ||
|
|
||
| long curr_len; |
There was a problem hiding this comment.
Don't know why, it won't make me use memcpy (that is an alias for __builtin_memcpy from clang) here.
There was a problem hiding this comment.
If i could use memcpy the patch would look much tidier, but that's not the case unfortunately.
There was a problem hiding this comment.
Oh we can't because for __builtin_memcpy size must be a compile time constant.
| @@ -4312,10 +4234,12 @@ FILLER(sys_recvfrom_x, true) | |||
| unsigned long val; | |||
| uint16_t size = 0; | |||
| long retval; | |||
| int addrlen; | |||
| int addrlen = 0; | |||
There was a problem hiding this comment.
recvfrom instead looks tidier now imo.
|
|
||
| static __always_inline int bpf_parse_readv_writev_bufs_64(struct filler_data *data, | ||
| static __always_inline int bpf_parse_readv_writev_bufs(struct filler_data *data, |
There was a problem hiding this comment.
to be honest I would prefer to revert this code to what we had before this PR https://github.com/falcosecurity/libs/pull/1814/files#diff-a8b6fc07077f8fcef2f22e51392da619a5e68b7c603c62b3ab93ce5b6be22d6b. The new implementation seems pretty easy to break and the only advantage is that we support readv and writev on 32 bits... that IMO is a corner case.
Btw if you feel confident we can also merge it and maybe revert it if we see it doesn't work well...
There was a problem hiding this comment.
Yep, i would love to be able to just use memcpy there (the clang builtin of course); but it won't work :/ it would make the code much better...
|
🚀 posted current results here #1890 (comment) |
FedeDP
force-pushed
the
fix/verifier
branch
2 times, most recently
from
1ed0fb2 to
5e706a2
Compare
|
@incertum this is now ready IMO. Other regressions you highlighted (mostly referring to #1890 (comment)) are not verifier issues, thus we can go on with this. I'd like to understand them too though, we can digging into that on #1890 ; feel free to add any new info you got :) |
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
|
/unhold |
Agree, we will dig into this separately. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Andreagit97, FedeDP, incertum 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 |
What type of PR is this?
/kind bug
Any specific area of the project related to this PR?
/area driver-bpf
Does this PR require a change in the driver versions?
What this PR does / why we need it:
#1814 and #1767 introduced 2 old bpf verifier regressions.
This PR aims at fixing them.
Which issue(s) this PR fixes:
Fixes #1890
Special notes for your reviewer:
Already tested against our kernel matrix (https://github.com/falcosecurity/libs/actions/runs/9386047428):
AMD64:
arm64:
Does this PR introduce a user-facing change?:
/milestone next-driver
/cc @incertum @Andreagit97