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é >>> <[email protected]> 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) >>>> > <[email protected]> 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
