-
Notifications
You must be signed in to change notification settings - Fork 138
bpf: deny trampoline attachment if args can not be located exactly on stack #9113
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
base: bpf_base
Are you sure you want to change the base?
Conversation
Upstream branch: 9cc7d59 |
16f9923
to
a842966
Compare
Upstream branch: 02adc14 |
10bccd5
to
f47c55d
Compare
a842966
to
a224fba
Compare
Upstream branch: d60d09e |
f47c55d
to
5ea1319
Compare
a224fba
to
a80e842
Compare
Upstream branch: ad9ef7f |
5ea1319
to
fb743a4
Compare
a80e842
to
db5bba6
Compare
x86 allows using up to 6 registers to pass arguments between function calls. This value is hardcoded in multiple places, use a define for this value. Signed-off-by: Alexis Lothoré (eBPF Foundation) <[email protected]>
… uncertain When the target function receives more arguments than available registers, the additional arguments are passed on stack, and so the generated trampoline needs to read those to prepare the bpf context, but also to prepare the target function stack when it is in charge of calling it. This works well for scalar types, but if the value is a struct, we can not know for sure the exact struct location, as it may have been packed or manually aligned to a greater value. Prevent wrong readings by refusing trampoline attachment if the target function receives a struct on stack. While at it, move the max bpf args check in the new function. Fixes: 473e315 ("bpf, x86: allow function arguments up to 12 for TRACING") Signed-off-by: Alexis Lothoré (eBPF Foundation) <[email protected]>
…is uncertain When the target function receives more arguments than available registers, the additional arguments are passed on stack, and so the generated trampoline needs to read those to prepare the bpf context, but also to prepare the target function stack when it is in charge of calling it. This works well for scalar types, but if the value is a struct, we can not know for sure the exact struct location, as it may have been packed or manually aligned to a greater value. Prevent wrong readings by refusing trampoline attachment if the target function receives a struct on stack. While at it, move the max bpf args check in the new function. Fixes: 6801b0a ("riscv, bpf: Add 12-argument support for RV64 bpf trampoline") Signed-off-by: Alexis Lothoré (eBPF Foundation) <[email protected]>
…s uncertain When the target function receives more arguments than available registers, the additional arguments are passed on stack, and so the generated trampoline needs to read those to prepare the bpf context, but also to prepare the target function stack when it is in charge of calling it. This works well for scalar types, but if the value is a struct, we can not know for sure the exact struct location, as it may have been packed or manually aligned to a greater value. Prevent wrong readings by refusing trampoline attachment if the target function receives a struct on stack. While doing so, move the existing check (ensuring that the number of args passed on stack is not higher than MAX_NR_STACK_ARGS) into the newly created check function. Fixes: 528eb2c ("s390/bpf: Implement arch_prepare_bpf_trampoline()") Signed-off-by: Alexis Lothoré (eBPF Foundation) <[email protected]>
powerpc allows using up to 8 registers to pass arguments between function calls. This value is hardcoded in multiple places, use a define for this value. Signed-off-by: Alexis Lothoré (eBPF Foundation) <[email protected]>
…ack is uncertain When the target function receives more arguments than available registers, the additional arguments are passed on stack, and so the generated trampoline needs to read those to prepare the bpf context, but also to prepare the target function stack when it is in charge of calling it. This works well for scalar types, but if the value is a struct, we can not know for sure the exact struct location, as it may have been packed or manually aligned to a greater value. Prevent wrong readings by refusing trampoline attachment if the target function receives a struct on stack. While at it, move the max bpf args check in the new function. Fixes: d243b62 ("powerpc64/bpf: Add support for bpf trampolines") Signed-off-by: Alexis Lothoré (eBPF Foundation) <[email protected]>
… be hooked When attaching ebpf programs to functions through fentry/fexit, the generated trampolines can not really make sure about the arguments exact location on the stack if those are structures: those structures can be altered with attributes such as packed or aligned(x), but this information is not encoded in BTF. Update tracing_struct_many_args test to check that programs can not be attached on those specific functions. Not all architectures can use the same number of registers to pass arguments, so define a testing function that makes all currently supported architectures start passing arguments on stack (-> more than 8 args) Signed-off-by: Alexis Lothoré (eBPF Foundation) <[email protected]>
Upstream branch: a766cfb |
fb743a4
to
6b61545
Compare
Pull request for series with
subject: bpf: deny trampoline attachment if args can not be located exactly on stack
version: 1
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=971683