Skip to content

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

Open
wants to merge 7 commits into
base: bpf_base
Choose a base branch
from

Conversation

kernel-patches-daemon-bpf[bot]
Copy link

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

@kernel-patches-daemon-bpf
Copy link
Author

Upstream branch: 9cc7d59
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=971683
version: 1

@kernel-patches-daemon-bpf
Copy link
Author

Upstream branch: 02adc14
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=971683
version: 1

@kernel-patches-daemon-bpf
Copy link
Author

Upstream branch: d60d09e
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=971683
version: 1

@kernel-patches-daemon-bpf
Copy link
Author

Upstream branch: ad9ef7f
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=971683
version: 1

Tropicao added 7 commits June 17, 2025 08:45
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]>
@kernel-patches-daemon-bpf
Copy link
Author

Upstream branch: a766cfb
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=971683
version: 1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant