-
Notifications
You must be signed in to change notification settings - Fork 6
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
bpf: Some fixes for nullness elision #4937
base: bpf-next_base
Are you sure you want to change the base?
bpf: Some fixes for nullness elision #4937
Conversation
Upstream branch: 5b67071 |
27c4909
to
9ce1c32
Compare
Upstream branch: 03f3aa4 |
aa22256
to
d0d0aab
Compare
Upstream branch: 03f3aa4 |
d0d0aab
to
75cea41
Compare
Upstream branch: 03f3aa4 |
75cea41
to
48ca528
Compare
Upstream branch: 03f3aa4 |
48ca528
to
6804d42
Compare
9ce1c32
to
30c33d1
Compare
Upstream branch: 03f3aa4 |
6804d42
to
073d716
Compare
30c33d1
to
2029cce
Compare
Upstream branch: 03f3aa4 |
073d716
to
fae7e70
Compare
2029cce
to
79342df
Compare
Upstream branch: 12befeb |
fae7e70
to
e2e05d1
Compare
79342df
to
1a4be3f
Compare
Upstream branch: 0abff46 |
e2e05d1
to
be04b49
Compare
1a4be3f
to
934ebcd
Compare
Previously, we were trying to extract constant map keys for all bpf_map_lookup_elem(), regardless of map type. This is an issue if the map has a u64 key and the value is very high, as it can be interpreted as a negative signed value. This in turn is treated as an error value by check_func_arg() which causes a valid program to be incorrectly rejected. Fix by only extracting constant map keys for relevant maps. This fix works because nullness elision is only allowed for {PERCPU_}ARRAY maps, and keys for these are within u32 range. See next commit for an example via selftest. Acked-by: Eduard Zingerman <[email protected]> Reported-by: Marc Hartmayer <[email protected]> Reported-by: Ilya Leoshkevich <[email protected]> Tested-by: Marc Hartmayer <[email protected]> Signed-off-by: Daniel Xu <[email protected]>
Test that very high constant map keys are not interpreted as an error value by the verifier. This would previously fail. Acked-by: Eduard Zingerman <[email protected]> Signed-off-by: Daniel Xu <[email protected]>
Refactor get_constant_map_key() to disambiguate the constant key value from potential error values. In the case that the key is negative, it could be confused for an error. It's not currently an issue, as the verifier seems to track s32 spills as u32. So even if the program wrongly uses a negative value for an arraymap key, the verifier just thinks it's an impossibly high value which gets correctly discarded. Refactor anyways to make things cleaner and prevent potential future issues. Acked-by: Eduard Zingerman <[email protected]> Signed-off-by: Daniel Xu <[email protected]>
Upstream branch: 003be25 |
be04b49
to
cebbfb9
Compare
Pull request for series with
subject: bpf: Some fixes for nullness elision
version: 1
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=929753