Re: [PATCH RFC bpf-next 0/8] bpf: add support for KASAN checks in JITed programs

Alexis Lothoré
2026-04-27T08:54:38Z

On Sat Apr 25, 2026 at 1:28 AM CEST, Alexei Starovoitov wrote:
> On Fri, Apr 24, 2026 at 4:10 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>>
>> I wonder if it's feasible to implement KASAN support on the verifier
>> side in post-verification fixups. AI slop for illustration:
>>
>> ;; Original (1 BPF insn):
>> dst = *(u64 *)(src + off) ; BPF_LDX | BPF_MEM | BPF_DW
>>
>> ;; Rewrite (~7 BPF insns):
>> r_tmp1 = src ; BPF_MOV64_REG
>> r_tmp1 += off ; BPF_ALU64 | BPF_ADD | K (full address)
>> r_tmp2 = r_tmp1 ; copy
>> r_tmp2 >>= 3 ; KASAN_SHADOW_SCALE_SHIFT
>> r_tmp2 += KASAN_SHADOW_OFFSET ; shadow address
>> r_tmp3 = *(u8 *)(r_tmp2 + 0) ; BPF_LDX | BPF_B (load shadow byte)
>> if r_tmp3 != 0 goto +2 ; BPF_JNE | PC+2
>> dst = *(u64 *)(src + off) ; original access (fast path)
>> goto +1 ; skip slowpath
>> call __asan_report_load8 ; BPF kfunc
>> dst = *(u64 *)(src + off) ; retry the access after report (non-fatal)
>>
>> A sort of inline kasan directly in BPF.
>>
>> There are plenty of issues with it: instruction limit, exposing asan
>> API as kfuncs, etc. On the flip side we get cross-arch support out of
>> the box with no or mininal JIT changes.
>>
>> Honestly I'm not excited about this approach, but curious if anyone
>> thought about this, or maybe it was already discussed?
>
> We discussed this.
> It won't work because we don't have that many temp registers for once
> and second it has to preserve all (both callee and caller saved regs).
> This is arch specific.

This "fast path" was indeed part of my initial proposal. For the record:

https://lore.kernel.org/bpf/DG7UG112AVBC.JKYISDTAM30T@bootlin.com/

in the "Basic instrumentation" block.

--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering