Re: [PATCH RFC bpf-next 3/8] bpf: add BPF_JIT_KASAN for KASAN instrumentation of JITed programs
Alexis Lothoré <[email protected]>
| Newsgroups | dev.linux.lists.sashiko,org.kernel.vger.bpf |
|---|---|
| Message-ID | <[email protected]> |
On Sat Apr 25, 2026 at 7:18 AM CEST, sashiko-bot wrote: > Sashiko AI review found 2 potential issue(s): > - [Medium] BPF_JIT_KASAN is defined as a hidden config, preventing users from disabling it. > - [Medium] Mismatch between commit message claims and Kconfig implementation regarding KASAN modes. > -- [...] >> @@ -101,4 +105,9 @@ config BPF_LSM >> >> If you are unsure how to answer this question, answer N. >> >> +config BPF_JIT_KASAN >> + bool >> + depends on HAVE_EBPF_JIT_KASAN >> + default y if BPF_JIT && KASAN_GENERIC >> + >> endmenu # "BPF subsystem" > > Since this config is defined as a bool without a prompt string, it acts as a > hidden symbol that is forcefully enabled whenever its dependencies are met. > > Because KASAN instrumentation emits shadow memory checks, it can significantly > inflate the size of generated JIT code. > > Could this code expansion cause large BPF programs to exceed the strict BPF > JIT memory limits (bpf_jit_limit) and break BPF functionality? It likely can, indeed, but... > If so, would it make sense to provide a prompt text so users and automated > testing systems have a mechanism to manually disable CONFIG_BPF_JIT_KASAN > to work around JIT limits or isolate bugs without having to entirely disable > KASAN_GENERIC? ... the discussions around this RFC rather tend make the series go in the opposite direction ([1]) and keep it systematically enabled if KASAN is enabled (I'll even drop this patch in the next revision and just make the KASAN code in JIT directly depend on KASAN_GENERIC). [1] https://lore.kernel.org/bpf/CAADnVQLj=UosnsC-4V2+mN92Fe0-kW++U+m-O9c93kk6BwiXgw@mail.gmail.com/ -- Alexis Lothoré, Bootlin Embedded Linux and Kernel engineering https://bootlin.com