On Fri, Nov 28, 2025 at 4:33 AM Baoquan He <[email protected]> wrote: > > Currently only hw_tags mode of kasan can be enabled or disabled with > kernel parameter kasan=on|off for built kernel. For kasan generic and > sw_tags mode, there's no way to disable them once kernel is built. > > This is not convenient sometime, e.g in system kdump is configured. > When the 1st kernel has KASAN enabled and crash triggered to switch to > kdump kernel, the generic or sw_tags mode will cost much extra memory > while in fact it's meaningless to have kasan in kdump kernel > > There are two parts of big amount of memory requiring for kasan enabed > kernel. One is the direct memory mapping shadow of kasan, which is 1/8 > of system RAM in generic mode and 1/16 of system RAM in sw_tags mode; > the other is the shadow meomry for vmalloc which causes big meomry > usage in kdump kernel because of lazy vmap freeing. By introducing > "kasan=off|on", if we specify 'kasan=off', the former is avoided by skipping > the kasan_init(), and the latter is avoided by not building the vmalloc > shadow for vmalloc. > > So this patchset moves the kasan=on|off out of hw_tags scope and into > common code to make it visible in generic and sw_tags mode too. Then we > can add kasan=off in kdump kernel to reduce the unneeded meomry cost for > kasan. > > Testing: > ======== > - Testing on x86_64 and arm64 for generic mode passed when kasan=on or > kasan=off. > > - Testing on arm64 with sw_tags mode passed when kasan=off is set. But > when I tried to test sw_tags on arm64, the system bootup failed. It's > not introduced by my patchset, the original code has the bug. I have > reported it to upstream. > - System is broken in KASAN sw_tags mode during bootup > - https://lore.kernel.org/all/aSXKqJTkZPNskFop@MiWiFi-R3L-srv/T/#u
This will hopefully be fixed soon, so you'll be able to test. > > - Haven't found hardware to test hw_tags. If anybody has the system, > please help take a test. You don't need hardware to run the HW_TAGS mode, just pass -machine virt,mte=on to QEMU. I also wonder if we should keep this kasan=off functionality conservative and limit it to x86 and arm64 (since these are the only two tested architectures). > > Changelog: > ==== > v3->v4: > - Rebase code to the latest linux-next/master to make the whole patchset > set on top of > [PATCH 0/2] kasan: cleanups for kasan_enabled() checks > [PATCH v6 0/2] kasan: unify kasan_enabled() and remove arch-specific > implementations Note that are also: [PATCH 1/2] kasan: remove __kasan_save_free_info wrapper [PATCH 2/2] kasan: cleanup of kasan_enabled() checks But I don't know if there will be any conflicts with these. > > v2->v3: > - Fix a building error on UML ARCH when CONFIG_KASAN is not set. The > change of fixing is appended into patch patch 11. This is reported > by LKP, thanks to them. > > v1->v2: > - Add __ro_after_init for kasan_arg_disabled, and remove redundant blank > lines in mm/kasan/common.c. Thanks to Marco. > - Fix a code bug in <linux/kasan-enabled.h> when CONFIG_KASAN is unset, > this is found out by SeongJae and Lorenzo, and also reported by LKP > report, thanks to them. > - Add a missing kasan_enabled() checking in kasan_report(). This will > cause below KASAN report info even though kasan=off is set: > ================================================================== > BUG: KASAN: stack-out-of-bounds in tick_program_event+0x130/0x150 > Read of size 4 at addr ffff00005f747778 by task swapper/0/1 > > CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.16.0+ #8 > PREEMPT(voluntary) > Hardware name: GIGABYTE R272-P30-JG/MP32-AR0-JG, BIOS F31n (SCP: > 2.10.20220810) 09/30/2022 > Call trace: > show_stack+0x30/0x90 (C) > dump_stack_lvl+0x7c/0xa0 > print_address_description.constprop.0+0x90/0x310 > print_report+0x104/0x1f0 > kasan_report+0xc8/0x110 > __asan_report_load4_noabort+0x20/0x30 > tick_program_event+0x130/0x150 > ......snip... > ================================================================== > > - Add jump_label_init() calling before kasan_init() in setup_arch() in these > architectures: xtensa, arm. Because they currenly rely on > jump_label_init() in main() which is a little late. Then the early static > key kasan_flag_enabled in kasan_init() won't work. > > - In UML architecture, change to enable kasan_flag_enabled in > arch_mm_preinit() > because kasan_init() is enabled before main(), there's no chance to operate > on static key in kasan_init(). > > Baoquan He (12): > mm/kasan: add conditional checks in functions to return directly if > kasan is disabled > mm/kasan: move kasan= code to common place > mm/kasan/sw_tags: don't initialize kasan if it's disabled > arch/arm: don't initialize kasan if it's disabled > arch/arm64: don't initialize kasan if it's disabled > arch/loongarch: don't initialize kasan if it's disabled > arch/powerpc: don't initialize kasan if it's disabled > arch/riscv: don't initialize kasan if it's disabled > arch/x86: don't initialize kasan if it's disabled > arch/xtensa: don't initialize kasan if it's disabled > arch/um: don't initialize kasan if it's disabled > mm/kasan: make kasan=on|off take effect for all three modes > > arch/arm/kernel/setup.c | 6 ++++++ > arch/arm/mm/kasan_init.c | 2 ++ > arch/arm64/mm/kasan_init.c | 6 ++++++ > arch/loongarch/mm/kasan_init.c | 2 ++ > arch/powerpc/mm/kasan/init_32.c | 5 ++++- > arch/powerpc/mm/kasan/init_book3e_64.c | 3 +++ > arch/powerpc/mm/kasan/init_book3s_64.c | 3 +++ > arch/riscv/mm/kasan_init.c | 3 +++ > arch/um/kernel/mem.c | 5 ++++- > arch/x86/mm/kasan_init_64.c | 3 +++ > arch/xtensa/kernel/setup.c | 1 + > arch/xtensa/mm/kasan_init.c | 3 +++ > include/linux/kasan-enabled.h | 6 ++++-- > mm/kasan/common.c | 20 ++++++++++++++++-- > mm/kasan/generic.c | 17 ++++++++++++++-- > mm/kasan/hw_tags.c | 28 ++------------------------ > mm/kasan/init.c | 6 ++++++ > mm/kasan/quarantine.c | 3 +++ > mm/kasan/report.c | 4 +++- > mm/kasan/shadow.c | 11 +++++++++- > mm/kasan/sw_tags.c | 6 ++++++ > 21 files changed, 107 insertions(+), 36 deletions(-) One part that's still missing is a Documentation change. > > -- > 2.41.0 >
