Skip to content

mm,boards/arm/qemu: Fix KASAN user-space false positives, global region link error, and linker script section placement.#19134

Open
leisiji wants to merge 3 commits into
apache:masterfrom
leisiji:master
Open

mm,boards/arm/qemu: Fix KASAN user-space false positives, global region link error, and linker script section placement.#19134
leisiji wants to merge 3 commits into
apache:masterfrom
leisiji:master

Conversation

@leisiji

@leisiji leisiji commented Jun 13, 2026

Copy link
Copy Markdown
Contributor

Summary

  • When CONFIG_MM_KASAN and CONFIG_BUILD_KERNEL are both enabled on
    qemu-armv7a:knsh, there are three issues preventing correct build
    and runtime: (1) user-space heap false positive KASAN reports,
    (2) app link failure due to undefined g_global_region symbol,
    (3) linker script misplaces KASAN sections causing boot failure.
  • This series fixes all three issues to make KASAN work correctly
    in kernel mode on QEMU ARMv7-A.

Impact

  • Is new feature added? NO
  • Impact on user? NO
  • Impact on build? YES — CMake post-build now strips .kasan.unused
    and .kasan.global sections when CONFIG_MM_KASAN_GLOBAL is enabled.
  • Impact on hardware? YES — affects boards using qemu-armv7a with
    KASAN enabled in kernel build.
  • Impact on documentation? NO
  • Impact on security? NO
  • Impact on compatibility? NO

Testing

  • Build Host: Linux x86_64, GCC
  • Target: qemu-armv7a:knsh (QEMU virt, Cortex-A7)

Setup config:

diff --git a/boards/arm/qemu/qemu-armv7a/configs/knsh/defconfig b/boards/arm/qemu/qemu-armv7a/configs/knsh/defconfig
index 18b086834c..1e2a1c3f96 100644
--- a/boards/arm/qemu/qemu-armv7a/configs/knsh/defconfig
+++ b/boards/arm/qemu/qemu-armv7a/configs/knsh/defconfig
@@ -91,3 +91,6 @@ CONFIG_UART1_PL011=y
 CONFIG_UART1_SERIAL_CONSOLE=y
 CONFIG_UART_PL011=y
 CONFIG_USEC_PER_TICK=1000
+CONFIG_MM_KASAN=y
+CONFIG_MM_KASAN_INSTRUMENT_ALL=y
+CONFIG_MM_KASAN_GLOBAL=y

Build:

cmake -B build -DBOARD_CONFIG=qemu-armv7a:knsh -GNinja && cmake --build build

Run:

qemu-system-arm -semihosting -M virt -m 128 -nographic -kernel ./build/nuttx

Testing logs before change:

  • Without commit 1 (mm/umm_heap), ls /proc triggers "detect kasan error".
  • Without commit 2 (mm/kasan), app link fails with undefined g_global_region.
  • Without commit 3 (boards/arm/qemu), QEMU fails to boot (LOAD segment conflict). Log of booting failure is below
qemu-system-arm: Some ROM regions are overlapping
These ROM regions might have been loaded by direct user request or by default.
They could be BIOS/firmware images, a guest kernel, initrd or some other file loaded into guest memory.
Check whether you intended to load all this guest code, and whether it has been built to load to the correct addresses.

The following two regions overlap (in the cpu-memory-0 address space):
  ./build/nuttx ELF program header segment 1 (addresses 0x0000000000000000 - 0x0000000000030000)
  dtb (addresses 0x0000000000000000 - 0x0000000000100000)

The following two regions overlap (in the cpu-memory-0 address space):
  dtb (addresses 0x0000000000000000 - 0x0000000000100000)
  ./build/nuttx ELF program header segment 2 (addresses 0x0000000000030000 - 0x0000000000034420)

leisiji added 2 commits June 14, 2026 05:43
When CONFIG_BUILD_KERNEL is enabled, user-space and kernel-space have
separate address spaces. User-space addresses passed via syscalls
(e.g., open) are registered by KASAN but should not be monitored,
as they are not kernel heap allocations. This causes KASAN to
report false positives on user-space pointers accessed through
system calls.

Mark the user-space heap with nokasan=true so KASAN skips checking
its address range, consistent with how rptun already handles this.

Signed-off-by: leisiji <2265215145@qq.com>
…_KERNEL on

When CONFIG_MM_KASAN_GLOBAL is enabled, hook.c is also linked into
libmm.a. However, g_global_region (defined in global.c) is only
injected into the nuttx ELF by kasan_global.py — it does not process
the app binary. This causes undefined symbol errors when linking an
app against libmm.a.

Guard the inclusion of global.c with __KERNEL__ so that only kernel
builds pull in the global KASAN region, while app builds fall back
to the no-op stub.

Signed-off-by: leisiji <2265215145@qq.com>
@github-actions github-actions Bot added Area: Build system Size: S The size of the change in this PR is small Board: arm labels Jun 13, 2026
1. The .kasan.unused and .kasan.global sections contain compiler-generated
data with the WRITE flag (.data..LASAN*), but the linker script placed
them before .text without specifying a memory region. The linker could
not put writable sections into the read-only ROM (rx) region, so it
silently placed them at 0x40000000 in RAM, creating an extra LOAD
segment that conflicts with QEMU virt's RAM layout and causes boot
failure.
2. The .kasan.global should be placed before .data because .data
patten (*(.data*)) includes .kasan.global pattern (*(.data..LASAN0)),
and it cause kasan_global.py cannot find .kasan.global section to
generate the g_global_region array.
3. Move .kasan.shadows from before .text to after .rodata. Placing it
before .text causes .text to shift when .kasan.shadows transitions
from empty (pass 1) to populated (pass 2+), preventing the multi-pass
link addresses from converging. After .rodata it does not affect any
upstream section addresses.
4. Add CMake post-build step to strip .kasan.unused and .kasan.global
sections from the final binary, matching the Makefile build behavior.

Signed-off-by: leisiji <2265215145@qq.com>

/* where the global variable out-of-bounds detection information located */

#ifdef CONFIG_MM_KASAN_GLOBAL

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yf13 has the patch which could fix kasan on protectd/kernel build, let's wait his patch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area: Build system Board: arm Size: S The size of the change in this PR is small

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants