On Thu Sep 3, 2026 at 3:51 PM CEST, Alexis Lothoré (eBPF Foundation) wrote: > Hello, > this is v9 of the series aiming to bring basic support for KASAN checks > to BPF JITed programs. Among a few minor optimizations, this revision > fixes some wrong kasan instrumentation on some unwanted stack access > (stack access ending up being instrumented AND targeting the wrong stack > offset). To mitigate this risk further, this revision introduces a > systematic KASAN check skip when (addr_reg == BPF_REG_FP || addr_reg == > BPF_REG_PARAMS) in emit_kasan_check. This secondary check (on top of the > non_stack_access flag), should hopefully prevent the issues raised in > v8. I've also reworked the emit_st refactoring to realign it with > BPF_STX management in the x86 JIT compiler, as the "arguments on stack" > feature made me realize that it could be kept more symmetric with > BPF_STX; so I've dropped Ihor's Acked-by on this. > > Original cover letter: > > "Traditional" KASAN allows to spot memory management mistakes by > reserving a fraction of memory as "shadow memory" that will map to the > rest of the memory and allow its monitoring. Each memory-accessing > instruction is then instrumented at build time to call some ASAN check > function, that will analyze the corresponding bits in shadow memory, and > if it detects the access as invalid, trigger a detailed report. The goal > of this series is to replicate this mechanism for BPF programs when they > are being JITed into native instructions: that's then the JIT compiler > that is in charge of inserting calls to the corresponding kasan checks, > when a program is being loaded into the kernel. This task involves: > - identifying at program load time the instructions performing memory > accesses > - identifying those accesses properties (size ? read or write ?) to > define the relevant kasan check function to call > - just before the identified instructions: > - perform the basic context saving (ie: saving registers) > - inserting a call to the relevant kasan check function > - restore context > - whenever the instrumented program executes, if it performs an invalid > access, it triggers a kasan report identical to those instrumented on > kernel side at build time. > > The series comes with new selftests programs that generate a wide > variety of kasan reports: those need the kernel to be running with > kasan_multi_shot enabled. > > As discussed in [1], this series is based on some choices and > assumptions: > - it focuses on x86_64 for now, and so only on KASAN_GENERIC > - not all memory accessing BPF instructions are being instrumented: > - it discards instructions accessing BPF program stack (already > monitored by page guards) > - it discards possibly faulting instructions, like BPF_PROBE_MEM or > BPF_PROBE_ATOMIC insns >
For the series: Acked-by: Kumar Kartikeya Dwivedi <[email protected]> If there are remaining issues, we can fix forward, but I think we should try and land this for now. > [...]
