Re: [PATCH RFC bpf-next 3/8] bpf: add BPF_JIT_KASAN for KASAN instrumentation of JITed programs

["Alexis Lothoré" <alexis.lothore@bootlin.com>]

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