On Sat Apr 25, 2026 at 1:28 AM CEST, Alexei Starovoitov wrote: > On Fri, Apr 24, 2026 at 4:10 PM Ihor Solodrai <[email protected]> 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/[email protected]/ in the "Basic instrumentation" block. -- Alexis Lothoré, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
