From: Sabyrzhan Tasbolatov <snovitoll@gmail.com>
To: hca@linux.ibm.com, christophe.leroy@csgroup.eu,
andreyknvl@gmail.com, agordeev@linux.ibm.com,
akpm@linux-foundation.org
Cc: ryabinin.a.a@gmail.com, glider@google.com, dvyukov@google.com,
kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org,
loongarch@lists.linux.dev, linuxppc-dev@lists.ozlabs.org,
linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
linux-um@lists.infradead.org, linux-mm@kvack.org,
snovitoll@gmail.com
Subject: [PATCH v3 00/12] kasan: unify kasan_arch_is_ready() and remove arch-specific implementations
Date: Thu, 17 Jul 2025 19:27:20 +0500 [thread overview]
Message-ID: <20250717142732.292822-1-snovitoll@gmail.com> (raw)
This patch series addresses the fragmentation in KASAN initialization
across architectures by introducing a unified approach that eliminates
duplicate static keys and arch-specific kasan_arch_is_ready()
implementations.
The core issue is that different architectures have inconsistent approaches
to KASAN readiness tracking:
- PowerPC, LoongArch, and um arch, each implement own kasan_arch_is_ready()
- Only HW_TAGS mode had a unified static key (kasan_flag_enabled)
- Generic and SW_TAGS modes relied on arch-specific solutions
or always-on behavior
This series implements two-level approach:
1. kasan_enabled() - compile-time check for KASAN configuration
2. kasan_shadow_initialized() - runtime check for shadow memory readiness
Key improvements:
- Unified static key infrastructure across all KASAN modes
- Runtime overhead only for architectures that actually need it
- Compile-time optimization for arch. with early KASAN initialization
- Complete elimination of arch-specific kasan_arch_is_ready()
- Consistent interface and reduced code duplication
Previous v2 thread: https://lore.kernel.org/all/20250626153147.145312-1-snovitoll@gmail.com/
Changes in v3 (sorry for the 3-week gap):
0. Included in TO, CC only KASAN devs and people who commented in v2.
1. Addressed Andrey Konovalov's feedback:
- Kept separate kasan_enabled() and kasan_shadow_initialized() functions
- Added proper __wrapper functions with clean separation
2. Addressed Christophe Leroy's performance comments:
- CONFIG_ARCH_DEFER_KASAN is only selected by architectures that need it
- No static key overhead for architectures that can enable KASAN early
- PowerPC 32-bit and book3e get compile-time optimization
3. Addressed Heiko Carstens and Alexander Gordeev s390 comments:
- s390 doesn't select ARCH_DEFER_KASAN (no unnecessary static key overhead)
- kasan_enable() is a no-op for architectures with early KASAN setup
4. Improved wrapper architecture:
- All existing wrapper functions in include/linux/kasan.h now check both
kasan_enabled() && kasan_shadow_initialized()
- Internal implementation functions focus purely on core functionality
- Shadow readiness logic is centralized in headers per Andrey's guidance
Architecture-specific changes:
- PowerPC radix MMU: selects ARCH_DEFER_KASAN for runtime control
- LoongArch: selects ARCH_DEFER_KASAN, removes custom kasan_early_stage
- um: selects ARCH_DEFER_KASAN, removes kasan_um_is_ready
- Other architectures: get compile-time optimization, no runtime overhead
The series maintains full backward compatibility while providing optimal
performance for each architecture's needs.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217049
=== Current mainline KUnit status
To see if there is any regression, I've tested via compiling a kernel
with CONFIG_KASAN_KUNIT_TEST and running QEMU VM. There are failing tests
in SW_TAGS and GENERIC modes in arm64:
arm64 CONFIG_KASAN_HW_TAGS:
# kasan: pass:62 fail:0 skip:13 total:75
# Totals: pass:62 fail:0 skip:13 total:75
ok 1 kasan
arm64 CONFIG_KASAN_SW_TAGS=y:
# kasan: pass:65 fail:1 skip:9 total:75
# Totals: pass:65 fail:1 skip:9 total:75
not ok 1 kasan
# kasan_strings: EXPECTATION FAILED at mm/kasan/kasan_test_c.c:1598
KASAN failure expected in "strscpy(ptr, src + KASAN_GRANULE_SIZE, KASAN_GRANULE_SIZE)", but none occurred
arm64 CONFIG_KASAN_GENERIC=y, CONFIG_KASAN_OUTLINE=y:
# kasan: pass:61 fail:1 skip:13 total:75
# Totals: pass:61 fail:1 skip:13 total:75
not ok 1 kasan
# same failure as above
x86_64 CONFIG_KASAN_GENERIC=y:
# kasan: pass:58 fail:0 skip:17 total:75
# Totals: pass:58 fail:0 skip:17 total:75
ok 1 kasan
=== Testing with patches
Testing in v3:
- Compiled every affected arch with no errors:
$ make CC=clang LD=ld.lld AR=llvm-ar NM=llvm-nm STRIP=llvm-strip \
OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump READELF=llvm-readelf \
HOSTCC=clang HOSTCXX=clang++ HOSTAR=llvm-ar HOSTLD=ld.lld \
ARCH=$ARCH
$ clang --version
ClangBuiltLinux clang version 19.1.4
Target: x86_64-unknown-linux-gnu
Thread model: posix
- make ARCH=um produces the warning during compiling:
MODPOST Module.symvers
WARNING: modpost: vmlinux: section mismatch in reference: \
kasan_init+0x43 (section: .ltext) -> \
kasan_init_generic (section: .init.text)
AFAIU, it's due to the code in arch/um/kernel/mem.c, where kasan_init()
is placed in own section ".kasan_init", which calls kasan_init_generic()
which is marked with "__init".
- Booting via qemu-system- and running KUnit tests:
* arm64 (GENERIC, HW_TAGS, SW_TAGS): no regression, same above results.
* x86_64 (GENERIC): no regression, no errors
Sabyrzhan Tasbolatov (12):
lib/kasan: introduce CONFIG_ARCH_DEFER_KASAN option
kasan: unify static kasan_flag_enabled across modes
kasan/powerpc: select ARCH_DEFER_KASAN and call kasan_init_generic
kasan/arm64: call kasan_init_generic in kasan_init
kasan/arm: call kasan_init_generic in kasan_init
kasan/xtensa: call kasan_init_generic in kasan_init
kasan/loongarch: select ARCH_DEFER_KASAN and call kasan_init_generic
kasan/um: select ARCH_DEFER_KASAN and call kasan_init_generic
kasan/x86: call kasan_init_generic in kasan_init
kasan/s390: call kasan_init_generic in kasan_init
kasan/riscv: call kasan_init_generic in kasan_init
kasan: add shadow checks to wrappers and rename kasan_arch_is_ready
arch/arm/mm/kasan_init.c | 2 +-
arch/arm64/mm/kasan_init.c | 4 +--
arch/loongarch/Kconfig | 1 +
arch/loongarch/include/asm/kasan.h | 7 -----
arch/loongarch/mm/kasan_init.c | 7 ++---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/kasan.h | 12 --------
arch/powerpc/mm/kasan/init_32.c | 2 +-
arch/powerpc/mm/kasan/init_book3e_64.c | 2 +-
arch/powerpc/mm/kasan/init_book3s_64.c | 6 +---
arch/riscv/mm/kasan_init.c | 1 +
arch/s390/kernel/early.c | 3 +-
arch/um/Kconfig | 1 +
arch/um/include/asm/kasan.h | 5 ---
arch/um/kernel/mem.c | 4 +--
arch/x86/mm/kasan_init_64.c | 2 +-
arch/xtensa/mm/kasan_init.c | 2 +-
include/linux/kasan-enabled.h | 34 ++++++++++++++++-----
include/linux/kasan.h | 42 ++++++++++++++++++++------
lib/Kconfig.kasan | 8 +++++
mm/kasan/common.c | 18 +++++++----
mm/kasan/generic.c | 23 ++++++++------
mm/kasan/hw_tags.c | 9 +-----
mm/kasan/kasan.h | 36 ++++++++++++++++------
mm/kasan/shadow.c | 32 +++++---------------
mm/kasan/sw_tags.c | 2 ++
26 files changed, 146 insertions(+), 120 deletions(-)
--
2.34.1
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Sabyrzhan Tasbolatov <snovitoll@gmail.com>
To: hca@linux.ibm.com, christophe.leroy@csgroup.eu,
andreyknvl@gmail.com, agordeev@linux.ibm.com,
akpm@linux-foundation.org
Cc: ryabinin.a.a@gmail.com, glider@google.com, dvyukov@google.com,
kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org,
loongarch@lists.linux.dev, linuxppc-dev@lists.ozlabs.org,
linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
linux-um@lists.infradead.org, linux-mm@kvack.org,
snovitoll@gmail.com
Subject: [PATCH v3 00/12] kasan: unify kasan_arch_is_ready() and remove arch-specific implementations
Date: Thu, 17 Jul 2025 19:27:20 +0500 [thread overview]
Message-ID: <20250717142732.292822-1-snovitoll@gmail.com> (raw)
This patch series addresses the fragmentation in KASAN initialization
across architectures by introducing a unified approach that eliminates
duplicate static keys and arch-specific kasan_arch_is_ready()
implementations.
The core issue is that different architectures have inconsistent approaches
to KASAN readiness tracking:
- PowerPC, LoongArch, and um arch, each implement own kasan_arch_is_ready()
- Only HW_TAGS mode had a unified static key (kasan_flag_enabled)
- Generic and SW_TAGS modes relied on arch-specific solutions
or always-on behavior
This series implements two-level approach:
1. kasan_enabled() - compile-time check for KASAN configuration
2. kasan_shadow_initialized() - runtime check for shadow memory readiness
Key improvements:
- Unified static key infrastructure across all KASAN modes
- Runtime overhead only for architectures that actually need it
- Compile-time optimization for arch. with early KASAN initialization
- Complete elimination of arch-specific kasan_arch_is_ready()
- Consistent interface and reduced code duplication
Previous v2 thread: https://lore.kernel.org/all/20250626153147.145312-1-snovitoll@gmail.com/
Changes in v3 (sorry for the 3-week gap):
0. Included in TO, CC only KASAN devs and people who commented in v2.
1. Addressed Andrey Konovalov's feedback:
- Kept separate kasan_enabled() and kasan_shadow_initialized() functions
- Added proper __wrapper functions with clean separation
2. Addressed Christophe Leroy's performance comments:
- CONFIG_ARCH_DEFER_KASAN is only selected by architectures that need it
- No static key overhead for architectures that can enable KASAN early
- PowerPC 32-bit and book3e get compile-time optimization
3. Addressed Heiko Carstens and Alexander Gordeev s390 comments:
- s390 doesn't select ARCH_DEFER_KASAN (no unnecessary static key overhead)
- kasan_enable() is a no-op for architectures with early KASAN setup
4. Improved wrapper architecture:
- All existing wrapper functions in include/linux/kasan.h now check both
kasan_enabled() && kasan_shadow_initialized()
- Internal implementation functions focus purely on core functionality
- Shadow readiness logic is centralized in headers per Andrey's guidance
Architecture-specific changes:
- PowerPC radix MMU: selects ARCH_DEFER_KASAN for runtime control
- LoongArch: selects ARCH_DEFER_KASAN, removes custom kasan_early_stage
- um: selects ARCH_DEFER_KASAN, removes kasan_um_is_ready
- Other architectures: get compile-time optimization, no runtime overhead
The series maintains full backward compatibility while providing optimal
performance for each architecture's needs.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217049
=== Current mainline KUnit status
To see if there is any regression, I've tested via compiling a kernel
with CONFIG_KASAN_KUNIT_TEST and running QEMU VM. There are failing tests
in SW_TAGS and GENERIC modes in arm64:
arm64 CONFIG_KASAN_HW_TAGS:
# kasan: pass:62 fail:0 skip:13 total:75
# Totals: pass:62 fail:0 skip:13 total:75
ok 1 kasan
arm64 CONFIG_KASAN_SW_TAGS=y:
# kasan: pass:65 fail:1 skip:9 total:75
# Totals: pass:65 fail:1 skip:9 total:75
not ok 1 kasan
# kasan_strings: EXPECTATION FAILED at mm/kasan/kasan_test_c.c:1598
KASAN failure expected in "strscpy(ptr, src + KASAN_GRANULE_SIZE, KASAN_GRANULE_SIZE)", but none occurred
arm64 CONFIG_KASAN_GENERIC=y, CONFIG_KASAN_OUTLINE=y:
# kasan: pass:61 fail:1 skip:13 total:75
# Totals: pass:61 fail:1 skip:13 total:75
not ok 1 kasan
# same failure as above
x86_64 CONFIG_KASAN_GENERIC=y:
# kasan: pass:58 fail:0 skip:17 total:75
# Totals: pass:58 fail:0 skip:17 total:75
ok 1 kasan
=== Testing with patches
Testing in v3:
- Compiled every affected arch with no errors:
$ make CC=clang LD=ld.lld AR=llvm-ar NM=llvm-nm STRIP=llvm-strip \
OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump READELF=llvm-readelf \
HOSTCC=clang HOSTCXX=clang++ HOSTAR=llvm-ar HOSTLD=ld.lld \
ARCH=$ARCH
$ clang --version
ClangBuiltLinux clang version 19.1.4
Target: x86_64-unknown-linux-gnu
Thread model: posix
- make ARCH=um produces the warning during compiling:
MODPOST Module.symvers
WARNING: modpost: vmlinux: section mismatch in reference: \
kasan_init+0x43 (section: .ltext) -> \
kasan_init_generic (section: .init.text)
AFAIU, it's due to the code in arch/um/kernel/mem.c, where kasan_init()
is placed in own section ".kasan_init", which calls kasan_init_generic()
which is marked with "__init".
- Booting via qemu-system- and running KUnit tests:
* arm64 (GENERIC, HW_TAGS, SW_TAGS): no regression, same above results.
* x86_64 (GENERIC): no regression, no errors
Sabyrzhan Tasbolatov (12):
lib/kasan: introduce CONFIG_ARCH_DEFER_KASAN option
kasan: unify static kasan_flag_enabled across modes
kasan/powerpc: select ARCH_DEFER_KASAN and call kasan_init_generic
kasan/arm64: call kasan_init_generic in kasan_init
kasan/arm: call kasan_init_generic in kasan_init
kasan/xtensa: call kasan_init_generic in kasan_init
kasan/loongarch: select ARCH_DEFER_KASAN and call kasan_init_generic
kasan/um: select ARCH_DEFER_KASAN and call kasan_init_generic
kasan/x86: call kasan_init_generic in kasan_init
kasan/s390: call kasan_init_generic in kasan_init
kasan/riscv: call kasan_init_generic in kasan_init
kasan: add shadow checks to wrappers and rename kasan_arch_is_ready
arch/arm/mm/kasan_init.c | 2 +-
arch/arm64/mm/kasan_init.c | 4 +--
arch/loongarch/Kconfig | 1 +
arch/loongarch/include/asm/kasan.h | 7 -----
arch/loongarch/mm/kasan_init.c | 7 ++---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/kasan.h | 12 --------
arch/powerpc/mm/kasan/init_32.c | 2 +-
arch/powerpc/mm/kasan/init_book3e_64.c | 2 +-
arch/powerpc/mm/kasan/init_book3s_64.c | 6 +---
arch/riscv/mm/kasan_init.c | 1 +
arch/s390/kernel/early.c | 3 +-
arch/um/Kconfig | 1 +
arch/um/include/asm/kasan.h | 5 ---
arch/um/kernel/mem.c | 4 +--
arch/x86/mm/kasan_init_64.c | 2 +-
arch/xtensa/mm/kasan_init.c | 2 +-
include/linux/kasan-enabled.h | 34 ++++++++++++++++-----
include/linux/kasan.h | 42 ++++++++++++++++++++------
lib/Kconfig.kasan | 8 +++++
mm/kasan/common.c | 18 +++++++----
mm/kasan/generic.c | 23 ++++++++------
mm/kasan/hw_tags.c | 9 +-----
mm/kasan/kasan.h | 36 ++++++++++++++++------
mm/kasan/shadow.c | 32 +++++---------------
mm/kasan/sw_tags.c | 2 ++
26 files changed, 146 insertions(+), 120 deletions(-)
--
2.34.1
next reply other threads:[~2025-07-17 15:03 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-17 14:27 Sabyrzhan Tasbolatov [this message]
2025-07-17 14:27 ` [PATCH v3 00/12] kasan: unify kasan_arch_is_ready() and remove arch-specific implementations Sabyrzhan Tasbolatov
2025-07-17 14:27 ` [PATCH v3 01/12] lib/kasan: introduce CONFIG_ARCH_DEFER_KASAN option Sabyrzhan Tasbolatov
2025-07-17 14:27 ` Sabyrzhan Tasbolatov
2025-07-17 22:10 ` Andrew Morton
2025-07-17 22:10 ` Andrew Morton
2025-07-18 8:05 ` Sabyrzhan Tasbolatov
2025-07-18 8:05 ` Sabyrzhan Tasbolatov
2025-07-21 23:18 ` Andrey Ryabinin
2025-07-21 23:18 ` Andrey Ryabinin
2025-07-22 0:35 ` Andrew Morton
2025-07-22 0:35 ` Andrew Morton
2025-07-18 12:38 ` Alexander Gordeev
2025-07-18 12:38 ` Alexander Gordeev
2025-07-21 22:59 ` Andrey Ryabinin
2025-07-21 22:59 ` Andrey Ryabinin
2025-07-17 14:27 ` [PATCH v3 02/12] kasan: unify static kasan_flag_enabled across modes Sabyrzhan Tasbolatov
2025-07-17 14:27 ` Sabyrzhan Tasbolatov
2025-07-21 22:59 ` Andrey Ryabinin
2025-07-21 22:59 ` Andrey Ryabinin
2025-07-17 14:27 ` [PATCH v3 03/12] kasan/powerpc: select ARCH_DEFER_KASAN and call kasan_init_generic Sabyrzhan Tasbolatov
2025-07-17 14:27 ` Sabyrzhan Tasbolatov
2025-07-17 14:27 ` [PATCH v3 04/12] kasan/arm64: call kasan_init_generic in kasan_init Sabyrzhan Tasbolatov
2025-07-17 14:27 ` Sabyrzhan Tasbolatov
2025-07-17 14:27 ` [PATCH v3 05/12] kasan/arm: " Sabyrzhan Tasbolatov
2025-07-17 14:27 ` Sabyrzhan Tasbolatov
2025-07-17 14:27 ` [PATCH v3 06/12] kasan/xtensa: " Sabyrzhan Tasbolatov
2025-07-17 14:27 ` Sabyrzhan Tasbolatov
2025-07-17 14:27 ` [PATCH v3 07/12] kasan/loongarch: select ARCH_DEFER_KASAN and call kasan_init_generic Sabyrzhan Tasbolatov
2025-07-17 14:27 ` Sabyrzhan Tasbolatov
2025-07-21 22:59 ` Andrey Ryabinin
2025-07-21 22:59 ` Andrey Ryabinin
2025-07-22 14:09 ` Sabyrzhan Tasbolatov
2025-07-22 14:09 ` Sabyrzhan Tasbolatov
2025-07-17 14:27 ` [PATCH v3 08/12] kasan/um: " Sabyrzhan Tasbolatov
2025-07-17 14:27 ` Sabyrzhan Tasbolatov
2025-07-21 23:00 ` Andrey Ryabinin
2025-07-21 23:00 ` Andrey Ryabinin
2025-07-22 14:17 ` Sabyrzhan Tasbolatov
2025-07-22 14:17 ` Sabyrzhan Tasbolatov
2025-07-23 17:10 ` Andrey Ryabinin
2025-07-23 17:10 ` Andrey Ryabinin
2025-07-17 14:27 ` [PATCH v3 09/12] kasan/x86: call kasan_init_generic in kasan_init Sabyrzhan Tasbolatov
2025-07-17 14:27 ` Sabyrzhan Tasbolatov
2025-07-17 14:27 ` [PATCH v3 10/12] kasan/s390: " Sabyrzhan Tasbolatov
2025-07-17 14:27 ` Sabyrzhan Tasbolatov
2025-07-18 12:38 ` Alexander Gordeev
2025-07-18 12:38 ` Alexander Gordeev
2025-07-17 14:27 ` [PATCH v3 11/12] kasan/riscv: " Sabyrzhan Tasbolatov
2025-07-17 14:27 ` Sabyrzhan Tasbolatov
2025-07-17 14:27 ` [PATCH v3 12/12] kasan: add shadow checks to wrappers and rename kasan_arch_is_ready Sabyrzhan Tasbolatov
2025-07-17 14:27 ` Sabyrzhan Tasbolatov
2025-07-21 22:59 ` [PATCH v3 00/12] kasan: unify kasan_arch_is_ready() and remove arch-specific implementations Andrey Ryabinin
2025-07-21 22:59 ` Andrey Ryabinin
2025-07-22 18:21 ` Sabyrzhan Tasbolatov
2025-07-22 18:21 ` Sabyrzhan Tasbolatov
2025-07-23 17:32 ` Andrey Ryabinin
2025-07-23 17:32 ` Andrey Ryabinin
2025-08-03 19:27 ` Sabyrzhan Tasbolatov
2025-08-04 12:04 ` Christophe Leroy
2025-08-04 13:21 ` Sabyrzhan Tasbolatov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250717142732.292822-1-snovitoll@gmail.com \
--to=snovitoll@gmail.com \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=christophe.leroy@csgroup.eu \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=hca@linux.ibm.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-um@lists.infradead.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=loongarch@lists.linux.dev \
--cc=ryabinin.a.a@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.