Re: [PATCH v4 5/5] selftest/bpf: Add tailcall verifier selftest for powerpc64

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] This problem wasn't introduced by this patch, but the selftest enforces the use of a 32-bit comparison (`cmplwi`) for distinguishing 64-bit pointers from scalar values, codifying a tail-call limit bypass vulnerability.
- [Medium] The expected powerpc64 JIT disassembly hardcodes config-dependent instructions and offsets, causing test failures on kernels with `CONFIG_PPC_KERNEL_PCREL` enabled.
--

commit 9136278f4ffaab3858500dc94c8a08d981e53500
Author: Abhishek Dubey <adubey@linux.ibm.com>

selftest/bpf: Add tailcall verifier selftest for powerpc64

This commit adds a verifier tailcall test case specifically for the powerpc64
architecture. It verifies the JIT compiler's code generation for BPF tail
calls by matching expected instructions.

> diff --git a/tools/testing/selftests/bpf/progs/verifier_tailcall_jit.c b/tools/testing/selftests/bpf/progs/verifier_tailcall_jit.c
> index 8d60c634a114f..17475ecb3207a 100644
> --- a/tools/testing/selftests/bpf/progs/verifier_tailcall_jit.c
> +++ b/tools/testing/selftests/bpf/progs/verifier_tailcall_jit.c
> @@ -90,6 +90,75 @@ __jited("	popq	%rax")
>  __jited("	jmp	{{.*}}")		/* jump to tail call tgt   */
>  __jited("L0:	leave")
>  __jited("	{{(retq|jmp	0x)}}")		/* return or jump to rethunk */
> +__arch_powerpc64
> +/* program entry for main(), regular function prologue */
> +__jited("	nop")
> +__jited("	ld 2, 16(13)")

Are we sure this load is always emitted?

On modern PowerPC configurations where CONFIG_PPC_KERNEL_PCREL is enabled,
the TOC load might be omitted by the JIT compiler.

Could this use wildcards to prevent test failures on kernels with PC-relative
addressing enabled?

[ ... ]

> +/* tail call prologue for subprogram */
> +__jited("	ld 10, 0(1)")
> +__jited("	ld 9, -8(10)")
> +__jited("	cmplwi	9, 33")

This isn't a bug introduced by this patch, but does the use of cmplwi here
codify a vulnerability in the JIT compiler?

Since tail_call_info can contain either a scalar counter value or a 64-bit
pointer to the counter, using a 32-bit compare (cmplwi) only checks the lower
32 bits.

If a 64-bit pointer's lower 32 bits happen to be <= 33 (for example, a stack
pointer near a 4GB boundary), it might incorrectly bypass the tail call limit
and cause an infinite loop leading to a CPU hard lockup.

Should the JIT (and this selftest) be using cmpldi instead to properly handle
the 64-bit comparison?

[ ... ]

> +/* bpf_tail_call implementation */
> +__jited("	ld 9, -8(1)")
> +__jited("	cmplwi	9, 33")
> +__jited("	bf	{{.*}}, {{.*}}")
> +__jited("	ld 9, 0(9)")
> +__jited("	cmplwi	9, 33")

(Same question here regarding the use of cmplwi instead of cmpldi)

[ ... ]

> +__jited("	ld 10, {{.*}}(10)")
> +__jited("	cmpldi	10, 0")
> +__jited("	bt	{{.*}}, {{.*}}")
> +__jited("	ld 10, {{.*}}(10)")
> +__jited("	addi 10, 10, 16")

Does this instruction offset also depend on the kernel configuration?

It looks like the prologue size calculation that produces this offset depends
on !IS_ENABLED(CONFIG_PPC_KERNEL_PCREL).

Could this fail on configurations where PC-relative addressing is enabled, and
would wildcards be more appropriate here as well?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260517214043.12975-1-adubey@linux.ibm.com?part=5