linux-kernel - Re: [PATCH v4 6/6] powerpc64/bpf: Additional NVR handling for bpf

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <b35dab8c-7e6b-4b7a-ac77-b85e33051e95@linux.ibm.com>
Date: Fri, 23 Jan 2026 18:47:51 +0530
From: Hari Bathini <hbathini@...ux.ibm.com>
To: bot+bpf-ci@...nel.org, adubey@...ux.ibm.com, bpf@...r.kernel.org,
        linuxppc-dev@...ts.ozlabs.org, linux-kselftest@...r.kernel.org,
        linux-kernel@...r.kernel.org
Cc: sachinpb@...ux.ibm.com, venkat88@...ux.ibm.com, andrii@...nel.org,
        eddyz87@...il.com, mykolal@...com, ast@...nel.org,
        daniel@...earbox.net, martin.lau@...ux.dev, song@...nel.org,
        yonghong.song@...ux.dev, john.fastabend@...il.com, kpsingh@...nel.org,
        sdf@...ichev.me, haoluo@...gle.com, jolsa@...nel.org,
        christophe.leroy@...roup.eu, naveen@...nel.org, maddy@...ux.ibm.com,
        mpe@...erman.id.au, npiggin@...il.com, memxor@...il.com,
        iii@...ux.ibm.com, shuah@...nel.org, martin.lau@...nel.org,
        clm@...a.com, ihor.solodrai@...ux.dev
Subject: Re: [PATCH v4 6/6] powerpc64/bpf: Additional NVR handling for
 bpf_throw



On 23/01/26 3:10 am, bot+bpf-ci@...nel.org wrote:
>> diff --git a/arch/powerpc/net/bpf_jit_comp64.c b/arch/powerpc/net/bpf_jit_comp64.c
>> index c284a12fce6e..98780a15fc69 100644
>> --- a/arch/powerpc/net/bpf_jit_comp64.c
>> +++ b/arch/powerpc/net/bpf_jit_comp64.c
> 
> [ ... ]
> 
>> @@ -125,9 +149,19 @@ int bpf_jit_stack_tailcallinfo_offset(struct codegen_context *ctx)
>>
>>   static int bpf_jit_stack_offsetof(struct codegen_context *ctx, int reg)
>>   {
>> -	if (reg >= BPF_PPC_NVR_MIN && reg < 32)
>> +	int min_valid_nvreg = BPF_PPC_NVR_MIN;
>> +	/* Default frame size for all cases except exception boundary */
>> +	int frame_nvr_size = BPF_PPC_STACKFRAME;
>> +
>> +	/* Consider all nv regs for handling exceptions */
>> +	if (ctx->exception_boundary || ctx->exception_cb) {
>> +		min_valid_nvreg = _R14;
>> +		frame_nvr_size = BPF_PPC_EXC_STACKFRAME;
>> +	}
>> +
>> +	if (reg >= min_valid_nvreg && reg < 32)
>>   		return (bpf_has_stack_frame(ctx) ?
>> -			(BPF_PPC_STACKFRAME + ctx->stack_size) : 0)
>> +			(frame_nvr_size + ctx->stack_size) : 0)
>>   				- (8 * (32 - reg)) - BPF_PPC_TAILCALL;
> 
> For the redzone case (no stack frame) with exception_boundary, this
> formula computes R23 at offset -80 and R24 at offset -72 from R1.
> 
> However, bpf_stf_barrier() uses hardcoded offsets -80(1) and -72(1) to
> temporarily save R21 and R22 during STF barrier execution:
> 
>      asm (
>      "	bpf_stf_barrier:		;"
>      "		std	21,-80(1)	;"
>      "		std	22,-72(1)	;"
>      "		sync			;"
>      "		ld	21,-80(1)	;"
>      "		ld	22,-72(1)	;"
>      ...
>      );
> 
> When an exception_boundary program without its own stack frame executes a
> memory load that triggers STF_BARRIER_FALLBACK, can bpf_stf_barrier()
> corrupt the saved R23 and R24 values? The hardcoded offsets would overlap
> with the extended NVR save area.
> 
> If exception_cb later restores these registers, it would get R21/R22 values
> instead of the original R23/R24 values.
> 
That is practically not possible as exception_boundary would mean
at least bpf_throw() is in the program (SEEN_FUNC) and SEEN_FUNC
would setup a frame for the exception_boundary program. Also, 
bpf_stf_barrier() always uses the redzone. So, it never stomps
on the stack of exception_boundary program...

@abhishek, better add the above comment and probably
also make bpf_has_stack_frame() return true explicitly for
exception_boundary as well (though SEEN_FUNC can't be false
in case of exception_boundary)..

- Hari