Re: [PATCH bpf-next v2] arm64, bpf: Add 12-argument support for bpf trampoline

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7/8/2024 5:00 PM, Puranjay Mohan wrote:
Xu Kuohai <xukuohai@xxxxxxxxxxxxxxx> writes:

On 7/5/2024 8:53 PM, Puranjay Mohan wrote:
The arm64 bpf JIT currently supports attaching the trampoline to
functions with <= 8 arguments. This is because up to 8 arguments can be
passed in registers r0-r7. If there are more than 8 arguments then the
9th and later arguments are passed on the stack, with SP pointing to the
first stacked argument. See aapcs64[1] for more details.

If the 8th argument is a structure of size > 8B, then it is passed fully
on stack and r7 is not used for passing any argument. If there is a 9th
argument, it will be passed on the stack, even though r7 is available.

Add the support of storing and restoring arguments passed on the stack
to the arm64 bpf trampoline. This will allow attaching the trampoline to
functions that take up to 12 arguments.

[1] https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#parameter-passing

Signed-off-by: Puranjay Mohan <puranjay@xxxxxxxxxx>
---
Changes in V1 -> V2:
V1: https://lore.kernel.org/all/20240704173227.130491-1-puranjay@xxxxxxxxxx/
- Fixed the argument handling for composite types (structs)
---
   arch/arm64/net/bpf_jit_comp.c                | 139 ++++++++++++++-----
   tools/testing/selftests/bpf/DENYLIST.aarch64 |   3 -
   2 files changed, 107 insertions(+), 35 deletions(-)


[SNIP]

   fill_link_info/kprobe_multi_invalid_ubuff        # bpf_program__attach_kprobe_multi_opts unexpected error: -95

It looks like this patch, similar to [1], also does not handle
parameter alignment properly [2].

For example:

int func(__int128 a, __int128 b, __int128 c, int64_t d, __int128 e, int64_t f, __int128 g)
{
}

parameter a~d are passed through register x0~x6, while parameter
e~g are passed through stack. Since __int128 is 16-byte aligned,
parameter e, f, and g should be placed at sp + 0, +16, and +32
respectively, with 8 bytes **padding** between f and g.


And the compiler's alignment or packed attribute may make things
worse, causing parameters to be placed on the stack at positions
that are not naturally aligned.

Hi Xu,
Thanks for explaining this. I was not aware that you have already sent a
patch[1] to add this support to arm64.

So, I see that it will be non-trivial to calculate padding for each
argument passed on the stack. If you are not planning to work on this
then I can try to implement it.


Sure, go ahead and do it.

Alsoi, do we currently have a selftest that checks for this edge case? if
not I can try to add that too.


Not yet, feel free to add it. Thanks.

Thanks,
Puranjay

[1] https://lore.kernel.org/bpf/20230917150752.69612-1-xukuohai@xxxxxxxxxxxxxxx/
[2] https://lore.kernel.org/bpf/CABRcYmLtk8aQEzoUFw+j5Rdd-MXf-q+i7RHXZtu-skjRz11ZDw@xxxxxxxxxxxxxx/





[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux