Re: [PATCH bpf-next v7 4/9] bpf, x86: emit KASAN checks in x86 JITed programs

["Alexis Lothoré" <alexis.lothore@bootlin.com>]

Hi Ihor, Kumar,

On Tue Aug 25, 2026 at 2:26 AM CEST, Kumar Kartikeya Dwivedi wrote:

[...]

>>>> If %r10 is clobbered, could this corrupt the stashed BPF_REG_0 and potentially
>>>> cause a crash when real_dst_reg is used as a memory pointer in the subsequent
>>>> emit_ldx() call?
>>>>
>>>> arch/x86/net/bpf_jit_comp.c:do_jit() {
>>>>     ...
>>>>     /* Load old value */
>>>>     emit_ldx(&prog, BPF_SIZE(insn->code), BPF_REG_0, real_dst_reg, insn->off);
>>>>     ...
>>>>     /* Restore R0 after clobbering RAX */
>>>>     emit_mov_reg(&prog, true, BPF_REG_0, BPF_REG_AX);
>>>>     ...
>>>> }
>>>
>>> This looks like a real bug, R10 is used for both atomics and constant blinding.
>>> We probably also should save R11.
>>
>>
>> Hi Kumar, Alexis.
>>
>> This topic has a bit of history now [1][2].
>
> From [1],
>
> "I built the kernel with gcc 11.5, gcc 15.2 and clang 22 and
> disassembled __asan_{load,store}{1,2,4,8}: none of them touch r10 or
> r11. gcc goes up to r8, clang uses nothing above rdi."
>
> Isn't this dependent on register pressure inside the function, i.e. depending on
> different code or whatever, it might begin using those registers?
>
>> I don't quite like it, but IMO we should give in to the bots.
>>
>> Reasons to save r10 and r11:
>> * SystemV ABI
>> * bots wouldn't shut up about it (think of future llm bot reports!)
>> * if our analysis of the kasan helpers is wrong about r10/r11 usage OR
>>   if something changes (the helpers themselves, the compilers, build
>>   flags, JIT's usage of r10/r11 etc.) - we'll get clobbered regs

Indeed, there's this risk of future versions of compilers deciding to
change the way those asan helpers are compiled, it will then silently
break (not sure how big of a risk it is, though).

>> Reasons to *not* save r10 and r11:
>> * we make the bpf prog a bit smaller and faster, the win is not very
>>   clear but it's percentages, not a factor
>>
>
> Yeah, also, we're already saving a ton of other registers, I don't know whether
> saving two would matter, even if it wasn't incorrect. I wouldn't worry too much
> about KASAN performance, it's already orders of magnitude slower than normal
> kernel build.

Ok, let's settle this then, I'll re-apply the r10/r11 save/restore
mechanism. If we eventually end up wanting to optimize it, this can be
revisited later.

Alexis

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com