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

[sashiko-bot@kernel.org]

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.
--

commit db39a97fa52b06c5f7f9fee25e7e76e2302a4e9d
Author: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>

bpf: add BPF_JIT_KASAN for KASAN instrumentation of JITed programs

This commit adds a new Kconfig option CONFIG_BPF_JIT_KASAN to enable KASAN
memory access checks for JIT-compiled BPF programs. When supported by the
architecture, it emits shadow memory checks to detect memory safety bugs at
runtime.

> Add a new Kconfig option CONFIG_BPF_JIT_KASAN that automatically enables
> KASAN (Kernel Address Sanitizer) memory access checks for JIT-compiled
> BPF programs, when both KASAN and JIT compiler are enabled.

Does this description accurately reflect the implementation?

The commit message states it is enabled when "both KASAN and JIT compiler
are enabled", but the Kconfig implementation restricts it specifically to
KASAN_GENERIC. It appears it will not be enabled if other KASAN modes
(such as KASAN_SW_TAGS or KASAN_HW_TAGS) are used.

Could the commit message be more precise about which KASAN modes are
supported?

> diff --git a/kernel/bpf/Kconfig b/kernel/bpf/Kconfig
> index eb3de35734f09..28392adb3d7e3 100644
> --- a/kernel/bpf/Kconfig
> +++ b/kernel/bpf/Kconfig

[ ... ]

> @@ -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?

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?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260413-kasan-v1-0-1a5831230821@bootlin.com?part=3