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 Fri May 22, 2026 at 7:13 PM CEST, Emil Tsalapatis wrote:
> On Fri May 22, 2026 at 10:14 AM EDT, Alexis Lothoré wrote:
>> On Tue Apr 14, 2026 at 4:38 PM CEST, Alexei Starovoitov wrote:
>>> On Tue, Apr 14, 2026 at 6:24 AM Alexis Lothoré
>>> <alexis.lothore@bootlin.com> wrote:
>>>>
>>>> On Tue Apr 14, 2026 at 12:20 AM CEST, Andrey Konovalov wrote:
>>>> > On Mon, Apr 13, 2026 at 8:29 PM Alexis Lothoré (eBPF Foundation)
>>>> > <alexis.lothore@bootlin.com> wrote:
>>
>> [...]
>>
>>>> >> +config BPF_JIT_KASAN
>>>> >> +       bool
>>>> >> +       depends on HAVE_EBPF_JIT_KASAN
>>>> >> +       default y if BPF_JIT && KASAN_GENERIC
>>>> >
>>>> > Should this be "depends on KASAN && KASAN_GENERIC"?
>>>>
>>>> Meaning, making it an explicit user-selectable option ?
>>>>
>>>> If so, the current design choice is voluntary and based on the feedback
>>>> received on the original RFC, where I have been suggested to
>>>> automatically enable the KASAN instrumentation in BPF programs if KASAN
>>>> support is enabled in the kernel ([1]). But if a user-selectable toggle
>>>> is eventually a better solution, I'm fine with changing it.
>>>
>>> Let's not add more config knobs.
>>> Even this patch looks redundant.
>>> Inside JIT do instrumentation when KASAN_GENERIC is set.
>>
>> (with quite some delay) I think it would be better to keep this new
>> BPF_JIT_KASAN, because aside from the possibility to use it in
>> bpf_jit_comp.c, it allows to update tests affected by KASAN
>> instrumentation in a nicer way. For example, the test_loader subtests
>> that monitor JITted instructions are confused by KASAN. I can either
>> skip them or make them smarter when KASAN is enabled for BPF, but in
>> both cases, it would be nicer to just adapt the behavior based on a
>> generic CONFIG_BPF_JIT_KASAN, rather than sprinkling some "if
>> jit_enabled AND CONFIG_KASAN_GENERIC AND ARCH_X86" in selftests. That
>> still does not make it a config knob, that just creates an internal
>> Kconfig option that is automatically turned on when KASAN and JIT are
>> enabled at build time.
>
> Having a togglable config knob gives us the option to set up KASAN for
> the kernel but not for BPF, and I don't see why we'd want that. Imo we are
> already paying the cost of KASAN for the rest of the kernel, there is no
> incentive to not run it for the BPF JIT. Having to eat the complexity cost
> in the selftests seems reasonable if the alternative means a cleaner
> interface for the user (preventing them from choosing an unreasonable
> combination of options).

Again, this does not expose a togglable knob, this is a purely internal
kconfig, automatically enabled if CONFIG_KASAN_GENERIC is set and if the
architecture-specific Kconfig defines HAVE_EBPF_JIT_KASAN (since we want
it for x86 only), and there would be no way to enable KASAN for kernel
only and not for BPF, or the other way around. What I am proposing is
just an internal, architecture-agnostice kconfig to avoid conditioning
some selftests to any architecture. 

Alexis

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com