On Sun, Apr 19, 2026 at 2:49 PM Andrey Konovalov <[email protected]> wrote: > > On Tue, Apr 14, 2026 at 5:58 PM Alexei Starovoitov > <[email protected]> wrote: > > > > I think we're talking past each other. > > We're not interested in KASAN_SW_TAGS or KASAN_HW_TAGS. > > We're not going to modify arm64 JIT at all. > > > > This is purely KASAN_GENRIC and only on x86-64. > > JIT will emit exactly what compilers emit for generic > > which is __asan_load/store. This is as stable ABI as it can get > > and we don't want to deviate from it. > > OK, I supposed that's fair. You did throw me off point with your > performance comment. But if you decide to add SW_TAGS support at some > point, I think this discussion needs to be revisited. > > But please add a comment saying that those functions are only exposed > for BPF JIT and they are not supposed to be used by other parts of the > kernel. And in case you do end up adding a new config option, guard > the public declarations by a corresponding ifdef.
I feel concerns of misuse are overblown. Being in include/linux/kasan.h doesn't make them free-for-all all of a sudden, but if you prefer we can just copy paste: +void __asan_load1(void *p); +void __asan_store1(void *p); into bpf_jit_comp.c > > The goal here is to find bugs in the verifier. > > If something got past it, that shouldn't have, > > kasan generic on x86-64 is enough. > > FWIW, I suspect HW_TAGS KASAN already just works with JITed BPF code. Ohh. Good point. Looks like modern arm64 cpus in public clouds don't have that enabled, so one would need pixel phone to catch verifier bugs via hw_tags. So we still need this x86-specific jit kasan. I guess eventually it can be removed when hw_tags support is widespread.
