* Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS on
@ 2025-07-14 3:12 刘海燕 (Haiyan Liu)
2025-07-14 20:04 ` Miguel Ojeda
` (2 more replies)
0 siblings, 3 replies; 16+ messages in thread
From: 刘海燕 (Haiyan Liu) @ 2025-07-14 3:12 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
rust-for-linux@vger.kernel.org
Cc: 代子为 (Ziwei Dai),
周平 (Ping Zhou/9032),
杨丽娜 (Lina Yang),
王双 (Shuang Wang)
I am enabling generic kasan feature in kernel 6.12, and met kernel boot crash.
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
pc : do_basic_setup+0x6c/0xac
lr : do_basic_setup+0x88/0xac
sp : ffffffc080087e40
After debug, I find some error in do_ctors().
Normally, the complier should insert the paciasp instruction at the function entry so that its corresponding autiasp instruction is used to validate the return address when the function returns.
NSX:FFFFFFC0800A840C|F800865E asan.module_ctor: str x30,[x18],#0x8；x30,[x18],#8
NSX:FFFFFFC0800A8410|A9BF7BFD stp x29,x30,[sp,#-0x10]! ; x29,x30,[sp,#-16]!
NSX:FFFFFFC0800A8414|910003FD mov x29,sp
NSX:FFFFFFC0800A8418|B0023420 adrp x0,0xFFFFFFC08472D000
NSX:FFFFFFC0800A841C|91390000 add x0,x0,#0xE40 ; x0,x0,#3648
NSX:FFFFFFC0800A8420|528000A1 mov w1,#0x5 ; w1,#5
NSX:FFFFFFC0800A8424|9422AF50 bl 0xFFFFFFC080954164 ; __asan_register_globals
NSX:FFFFFFC0800A8428|A8C17BFD ldp x29,x30,[sp],#0x10 ; x29,x30,[sp],#16
NSX:FFFFFFC0800A842C|F85F8E5E ldr x30,[x18,#-0x8]! ; x30,[x18,#-8]!
NSX:FFFFFFC0800A8430|D65F03C0 ret
NSX:FFFFFFC0800A8478|D503233F asan.module_ctor: paciasp
NSX:FFFFFFC0800A847C|A9BF7BFD stp x29,x30,[sp,#-0x10]! ; x29,x30,[sp,#-16]!
NSX:FFFFFFC0800A8480|910003FD mov x29,sp
NSX:FFFFFFC0800A8484|B0023420 adrp x0,0xFFFFFFC08472D000
NSX:FFFFFFC0800A8488|913E0000 add x0,x0,#0xF80 ; x0,x0,#3968
NSX:FFFFFFC0800A848C|52800021 mov w1,#0x1 ; w1,#1
NSX:FFFFFFC0800A8490|9422AF35 bl 0xFFFFFFC080954164 ; __asan_register_globals
NSX:FFFFFFC0800A8494|A8C17BFD ldp x29,x30,[sp],#0x10 ; x29,x30,[sp],#16
NSX:FFFFFFC0800A8498|D50323BF autiasp
NSX:FFFFFFC0800A849C|D65F03C0 ret
But actually, in two asan.module_ctor functions, there is only autiasp instruction inserted before return, for validation of return address, while paciasp instruction is missing before.
NSX:FFFFFFC0800A72D8|F800865E asan.module_ctor: str x30,[x18],#0x8 ; x30,[x18],#8
NSX:FFFFFFC0800A72DC|F81F0FFE str x30,[sp,#-0x10]! ; x30,[sp,#-16]!
NSX:FFFFFFC0800A72E0|B00233C0 adrp x0,0xFFFFFFC084720000
NSX:FFFFFFC0800A72E4|91350000 add x0,x0,#0xD40 ; x0,x0,#3392
NSX:FFFFFFC0800A72E8|52803D61 mov w1,#0x1EB ; w1,#491
NSX:FFFFFFC0800A72EC|9422B39E bl 0xFFFFFFC080954164 ; __asan_register_globals
NSX:FFFFFFC0800A72F0|F84107FE ldr x30,[sp],#0x10 ; x30,[sp],#16
NSX:FFFFFFC0800A72F4|D50323BF autiasp
NSX:FFFFFFC0800A72F8|D65F03C0 ret
NSX:FFFFFFC0800A7390|F800865E asan.module_ctor: str x30,[x18],#0x8 ; x30,[x18],#8
NSX:FFFFFFC0800A7394|F81F0FFE str x30,[sp,#-0x10]! ; x30,[sp,#-16]!
NSX:FFFFFFC0800A7398|B0023400 adrp x0,0xFFFFFFC084728000
NSX:FFFFFFC0800A739C|91210000 add x0,x0,#0x840 ; x0,x0,#2112
NSX:FFFFFFC0800A73A0|528006E1 mov w1,#0x37 ; w1,#55
NSX:FFFFFFC0800A73A4|9422B370 bl 0xFFFFFFC080954164 ; __asan_register_globals
NSX:FFFFFFC0800A73A8|F84107FE ldr x30,[sp],#0x10 ; x30,[sp],#16
NSX:FFFFFFC0800A73AC|D50323BF autiasp
NSX:FFFFFFC0800A73B0|D65F03C0 ret
I compare kernel 6.6 and kernel 6.12 ARM Makefile, and find the difference.
Kernel6.6 Makefile
66 ifeq ($(CONFIG_ARM64_BTI_KERNEL),y)
67 KBUILD_CFLAGS += -mbranch-protection=pac-ret+bti
68 else ifeq ($(CONFIG_ARM64_PTR_AUTH_KERNEL),y)
69 ifeq ($(CONFIG_CC_HAS_BRANCH_PROT_PAC_RET),y)
70 KBUILD_CFLAGS += -mbranch-protection=pac-ret
71 else
72 KBUILD_CFLAGS += -msign-return-address=non-leaf
73 endif
74 else
75 KBUILD_CFLAGS += $(call cc-option,-mbranch-protection=none)
76 endif
Kernel6.12 Makefile
81 ifeq ($(CONFIG_ARM64_BTI_KERNEL),y)
82 KBUILD_CFLAGS += -mbranch-protection=pac-ret+bti
83 KBUILD_RUSTFLAGS += -Zbranch-protection=bti,pac-ret
84 else ifeq ($(CONFIG_ARM64_PTR_AUTH_KERNEL),y)
85 KBUILD_RUSTFLAGS += -Zbranch-protection=pac-ret
86 ifeq ($(CONFIG_CC_HAS_BRANCH_PROT_PAC_RET),y)
87 KBUILD_CFLAGS += -mbranch-protection=pac-ret
88 else
89 KBUILD_CFLAGS += -msign-return-address=non-leaf
90 endif
91 else
92 KBUILD_CFLAGS += $(call cc-option,-mbranch-protection=none)
93 endif
After I delete the rust build flags, the asan.module_ctor binary is right and kasan feature works fine.Could you help check why KBUILD_RUSTFLAGS impacts kernel complication with kasan feature enabled and how can this issue fixed?
I use the build.config.constants:
BRANCH=android16-6.12
KMI_GENERATION=4
CLANG_VERSION=r536225
RUSTC_VERSION=1.82.0
AARCH64_NDK_TRIPLE=aarch64-linux-android31
X86_64_NDK_TRIPLE=x86_64-linux-android31
ARM_NDK_TRIPLE=arm-linux-androideabi31
compile configuration is :
CONFIG_GCC_VERSION=0
CONFIG_CC_IS_CLANG=y
CONFIG_CLANG_VERSION=190001
CONFIG_AS_IS_LLVM=y
CONFIG_AS_VERSION=190001
CONFIG_LD_VERSION=0
CONFIG_LD_IS_LLD=y
CONFIG_LLD_VERSION=190001
CONFIG_RUSTC_VERSION=108200
CONFIG_RUST_IS_AVAILABLE=y
CONFIG_RUSTC_LLVM_VERSION=190001
CONFIG_CC_CAN_LINK=y
CONFIG_CC_CAN_LINK_STATIC=y
CONFIG_CC_HAS_ASM_GOTO_OUTPUT=y
CONFIG_CC_HAS_ASM_GOTO_TIED_OUTPUT=y
CONFIG_TOOLS_SUPPORT_RELR=y
CONFIG_CC_HAS_ASM_INLINE=y
CONFIG_CC_HAS_NO_PROFILE_FN_ATTR=y
CONFIG_PAHOLE_VERSION=125
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_TABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
Thank you
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS on
2025-07-14 3:12 Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS on 刘海燕 (Haiyan Liu)
@ 2025-07-14 20:04 ` Miguel Ojeda
[not found] ` <202507150830.56F8U908028199@SHSPAM01.spreadtrum.com>
2025-07-17 10:38 ` Mark Rutland
2 siblings, 0 replies; 16+ messages in thread
From: Miguel Ojeda @ 2025-07-14 20:04 UTC (permalink / raw)
To: haiyan.liu
Cc: Ping.Zhou1, Ziwei.Dai, lina.yang, linux-arm-kernel, linux-kernel,
rust-for-linux, shuang.wang, Andrey Ryabinin, Alexander Potapenko,
Andrey Konovalov, Dmitry Vyukov, Vincenzo Frascino, kasan-dev,
Greg Kroah-Hartman, Arve Hjønnevåg, Todd Kjos,
Martijn Coenen, Joel Fernandes, Christian Brauner, Carlos Llamas,
Suren Baghdasaryan, Jamie Cunliffe, Catalin Marinas
On Mon, 14 Jul 2025 03:12:33 +0000 "刘海燕 (Haiyan Liu)" <haiyan.liu@unisoc.com> wrote:
>
> After I delete the rust build flags, the asan.module_ctor binary is right and kasan feature works fine.Could you help check why KBUILD_RUSTFLAGS impacts kernel complication with kasan feature enabled and how can this issue fixed?
I assume Rust is enabled in that kernel, right? Or do you mean that somehow removing those lines from the `Makefile` makes the issue go away even if Rust is not enabled?
Could you please share your kernel commit and the full configuration? From a quick build arm64 KASAN in v6.12.38, I see the `paciasp`/`autiasp` pair in one of the Rust object files:
0000000000000000 <asan.module_ctor>:
0: d503233f paciasp
4: f81f0ffe str x30, [sp, #-0x10]!
8: 90000000 adrp x0, 0x0 <asan.module_ctor>
c: 91000000 add x0, x0, #0x0
10: 52800601 mov w1, #0x30 // =48
14: 94000000 bl 0x14 <asan.module_ctor+0x14>
18: f84107fe ldr x30, [sp], #0x10
1c: d50323bf autiasp
20: d65f03c0 ret
But I am definitely not an expert at all in this, so Cc'ing KASAN and Android maintainers: https://lore.kernel.org/rust-for-linux/4c459085b9ae42bdbf99b6014952b965@BJMBX01.spreadtrum.com/
Cheers,
Miguel
^ permalink raw reply [flat|nested] 16+ messages in thread
* 答复: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS on
[not found] ` <202507150830.56F8U908028199@SHSPAM01.spreadtrum.com>
@ 2025-07-15 9:40 ` 刘海燕 (Haiyan Liu)
2025-07-15 17:50 ` Miguel Ojeda
0 siblings, 1 reply; 16+ messages in thread
From: 刘海燕 (Haiyan Liu) @ 2025-07-15 9:40 UTC (permalink / raw)
To: Miguel Ojeda
Cc: 周平 (Ping Zhou/9032),
代子为 (Ziwei Dai),
杨丽娜 (Lina Yang),
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
王双 (Shuang Wang), Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, kasan-dev@googlegroups.com, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Martijn Coenen,
Joel Fernandes, Christian Brauner, Carlos Llamas,
Suren Baghdasaryan, Jamie Cunliffe, Catalin Marinas
> -----邮件原件-----
> 发件人: Miguel Ojeda <ojeda@kernel.org>
> 发送时间: 2025年7月15日 4:05
> 收件人: 刘海燕 (Haiyan Liu) <haiyan.liu@unisoc.com>
> 抄送: 周平 (Ping Zhou/9032) <Ping.Zhou1@unisoc.com>; 代子为 (Ziwei Dai) <Ziwei.Dai@unisoc.com>; 杨丽娜 (Lina Yang)
> <lina.yang@unisoc.com>; linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; rust-for-linux@vger.kernel.org; 王双
> (Shuang Wang) <shuang.wang@unisoc.com>; Andrey Ryabinin <ryabinin.a.a@gmail.com>; Alexander Potapenko <glider@google.com>;
> Andrey Konovalov <andreyknvl@gmail.com>; Dmitry Vyukov <dvyukov@google.com>; Vincenzo Frascino <vincenzo.frascino@arm.com>;
> kasan-dev@googlegroups.com; Greg Kroah-Hartman <gregkh@linuxfoundation.org>; Arve Hjønnevåg <arve@android.com>; Todd Kjos
> <tkjos@android.com>; Martijn Coenen <maco@android.com>; Joel Fernandes <joelagnelf@nvidia.com>; Christian Brauner
> <christian@brauner.io>; Carlos Llamas <cmllamas@google.com>; Suren Baghdasaryan <surenb@google.com>; Jamie Cunliffe
> <Jamie.Cunliffe@arm.com>; Catalin Marinas <catalin.marinas@arm.com>
> 主题: Re: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS
> on
>
>
> 注意: 这封邮件来自于外部。除非你确定邮件内容安全，否则不要点击任何链接和附件。
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender
> and know the content is safe.
>
>
>
> On Mon, 14 Jul 2025 03:12:33 +0000 "刘海燕 (Haiyan Liu)" <haiyan.liu@unisoc.com> wrote:
> >
> > After I delete the rust build flags, the asan.module_ctor binary is right and kasan feature works fine.Could you help check why
> KBUILD_RUSTFLAGS impacts kernel complication with kasan feature enabled and how can this issue fixed?
>
> I assume Rust is enabled in that kernel, right? Or do you mean that somehow removing those lines from the `Makefile` makes the issue go
> away even if Rust is not enabled?
Rust is enabled in kernel, and rustc version is 1.82.0. I want to know why the pacisap/autiasp are not in pair.
> Could you please share your kernel commit and the full configuration? From a quick build arm64 KASAN in v6.12.38, I see the
> `paciasp`/`autiasp` pair in one of the Rust object files:
The commit changes the fragment and diff is:
+CONFIG_CMDLINE="stack_depot_disable=off kasan.stacktrace=on kasan.fault=panic kvm-arm.mode=protected cgroup_disable=pressure"
+CONFIG_KASAN_GENERIC=y
Only two rust-related global variables in fmr.rs and layout.rs have this issue. Their asan.module_ctor complied binaries are wrong.
> 0000000000000000 <asan.module_ctor>:
> 0: d503233f paciasp
> 4: f81f0ffe str x30, [sp, #-0x10]!
> 8: 90000000 adrp x0, 0x0 <asan.module_ctor>
> c: 91000000 add x0, x0, #0x0
> 10: 52800601 mov w1, #0x30 // =48
> 14: 94000000 bl 0x14 <asan.module_ctor+0x14>
> 18: f84107fe ldr x30, [sp], #0x10
> 1c: d50323bf autiasp
> 20: d65f03c0 ret
>
> But I am definitely not an expert at all in this, so Cc'ing KASAN and Android maintainers:
> https://lore.kernel.org/rust-for-linux/4c459085b9ae42bdbf99b6014952b965@BJMBX01.spreadtrum.com/
>
> Cheers,
> Miguel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS on
2025-07-15 9:40 ` 答复: " 刘海燕 (Haiyan Liu)
@ 2025-07-15 17:50 ` Miguel Ojeda
2025-07-16 7:01 ` 刘海燕 (Haiyan Liu)
0 siblings, 1 reply; 16+ messages in thread
From: Miguel Ojeda @ 2025-07-15 17:50 UTC (permalink / raw)
To: 刘海燕 (Haiyan Liu)
Cc: Miguel Ojeda, 周平 (Ping Zhou/9032),
代子为 (Ziwei Dai),
杨丽娜 (Lina Yang),
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
王双 (Shuang Wang), Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, kasan-dev@googlegroups.com, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Martijn Coenen,
Joel Fernandes, Christian Brauner, Carlos Llamas,
Suren Baghdasaryan, Jamie Cunliffe, Catalin Marinas
On Tue, Jul 15, 2025 at 11:41 AM 刘海燕 (Haiyan Liu) <haiyan.liu@unisoc.com> wrote:
>
> The commit changes the fragment and diff is:
An Android engineer should know how to handle that, but if you are
reporting upstream, it is best to try to reproduce the issue with the
upstream kernels (e.g. arm64 is not in 6.6.y) and provide the full
kernel config used.
> Only two rust-related global variables in fmr.rs and layout.rs have this issue. Their asan.module_ctor complied binaries are wrong.
I am not sure what you mean by `fmr.rs`. As for `layout.rs`, that is
in the `kernel` crate in 6.12.y -- isn't there a single
`asan.module_ctor` per TU? Which object file are you referring to? I
get the pair for my `rust/kernel.o`.
Cheers,
Miguel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS on
2025-07-15 17:50 ` Miguel Ojeda
@ 2025-07-16 7:01 ` 刘海燕 (Haiyan Liu)
2025-07-16 18:21 ` Carlos Llamas
0 siblings, 1 reply; 16+ messages in thread
From: 刘海燕 (Haiyan Liu) @ 2025-07-16 7:01 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Miguel Ojeda, 周平 (Ping Zhou/9032),
代子为 (Ziwei Dai),
杨丽娜 (Lina Yang),
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
王双 (Shuang Wang), Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, kasan-dev@googlegroups.com, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Martijn Coenen,
Joel Fernandes, Christian Brauner, Carlos Llamas,
Suren Baghdasaryan, Jamie Cunliffe, Catalin Marinas
> -----邮件原件-----
> 发件人: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
> 发送时间: 2025年7月16日 1:51
> 收件人: 刘海燕 (Haiyan Liu) <haiyan.liu@unisoc.com>
> 抄送: Miguel Ojeda <ojeda@kernel.org>; 周平 (Ping Zhou/9032) <Ping.Zhou1@unisoc.com>; 代子为 (Ziwei Dai)
> <Ziwei.Dai@unisoc.com>; 杨丽娜 (Lina Yang) <lina.yang@unisoc.com>; linux-arm-kernel@lists.infradead.org;
> linux-kernel@vger.kernel.org; rust-for-linux@vger.kernel.org; 王双 (Shuang Wang) <shuang.wang@unisoc.com>; Andrey Ryabinin
> <ryabinin.a.a@gmail.com>; Alexander Potapenko <glider@google.com>; Andrey Konovalov <andreyknvl@gmail.com>; Dmitry Vyukov
> <dvyukov@google.com>; Vincenzo Frascino <vincenzo.frascino@arm.com>; kasan-dev@googlegroups.com; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>; Arve Hjønnevåg <arve@android.com>; Todd Kjos <tkjos@android.com>; Martijn Coenen
> <maco@android.com>; Joel Fernandes <joelagnelf@nvidia.com>; Christian Brauner <christian@brauner.io>; Carlos Llamas
> <cmllamas@google.com>; Suren Baghdasaryan <surenb@google.com>; Jamie Cunliffe <Jamie.Cunliffe@arm.com>; Catalin Marinas
> <catalin.marinas@arm.com>
> 主题: Re: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS
> on
>
>
> 注意: 这封邮件来自于外部。除非你确定邮件内容安全，否则不要点击任何链接和附件。
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender
> and know the content is safe.
>
>
>
> On Tue, Jul 15, 2025 at 11:41 AM 刘海燕 (Haiyan Liu) <haiyan.liu@unisoc.com> wrote:
> >
> > The commit changes the fragment and diff is:
>
> An Android engineer should know how to handle that, but if you are reporting upstream, it is best to try to reproduce the issue with the
> upstream kernels (e.g. arm64 is not in 6.6.y) and provide the full kernel config used.
>
> > Only two rust-related global variables in fmr.rs and layout.rs have this issue. Their asan.module_ctor complied binaries are wrong.
>
> I am not sure what you mean by `fmr.rs`. As for `layout.rs`, that is in the `kernel` crate in 6.12.y -- isn't there a single `asan.module_ctor`
> per TU? Which object file are you referring to? I get the pair for my `rust/kernel.o`.
NSX:FFFFFFC0800A7C94|F800865E asan.module_ctor: str x30,[x18],#0x8 ; x30,[x18],#8
NSX:FFFFFFC0800A7C98|F81F0FFE str x30,[sp,#-0x10]! ; x30,[sp,#-16]!
NSX:FFFFFFC0800A7C9C|F00240A0 adrp x0,0xFFFFFFC0848BE000
NSX:FFFFFFC0800A7CA0|911D8000 add x0,x0,#0x760 ; x0,x0,#1888
NSX:FFFFFFC0800A7CA4|52803D61 mov w1,#0x1EB ; w1,#491
NSX:FFFFFFC0800A7CA8|94233816 bl 0xFFFFFFC080975D00 ; __asan_register_globals
NSX:FFFFFFC0800A7CAC|F84107FE ldr x30,[sp],#0x10 ; x30,[sp],#16
NSX:FFFFFFC0800A7CB0|D50323BF autiasp
NSX:FFFFFFC0800A7CB4|D65F03C0 ret
The first __asan_global struct value is
ENAXI:FFFFFFC0848BE760|>FFFFFFC082EDB180 000000000000005F ........_.......
ENAXI:FFFFFFC0848BE770| 0000000000000080 FFFFFFC0836DC431 ........1.m.....
ENAXI:FFFFFFC0848BE780| FFFFFFC082EEC780 0000000000000000 ................
ENAXI:FFFFFFC0848BE790| 0000000000000000 FFFFFFFFFFFFFFFF ................
The address of the global is 0xFFFFFFC082EDB180 which value is '/proc/self/cwd/prebuilts/rust/linux-x86/1.82.0/lib/rustlib/src/rust/library/core/src/num/fmt.rs' and its viewinfo is 'vmlinux\Global\__unnamed_357'
The original size of the global is 0x5F
The name of the global is kmalloc-2k
The module name of the global is 'core.27758904ccee4c80-cgu.o'
NSX:FFFFFFC0800A7D4C|F800865E asan.mod.:str x30,[x18],#0x8 ; x30,[x18],#8
NSX:FFFFFFC0800A7D50|F81F0FFE str x30,[sp,#-0x10]! ; x30,[sp,#-16]!
NSX:FFFFFFC0800A7D54|F00240E0 adrp x0,0xFFFFFFC0848C6000
NSX:FFFFFFC0800A7D58|912E8000 add x0,x0,#0xBA0 ; x0,x0,#2976
NSX:FFFFFFC0800A7D5C|52800961 mov w1,#0x4B ; w1,#75
NSX:FFFFFFC0800A7D60|942337E8 bl 0xFFFFFFC080975D00 ; __asan_register_globals
NSX:FFFFFFC0800A7D64|F84107FE ldr x30,[sp],#0x10 ; x30,[sp],#16
NSX:FFFFFFC0800A7D68|D50323BF autiasp
NSX:FFFFFFC0800A7D6C|D65F03C0 ret
The second __asan_global struct value is
NSD:FFFFFFC0848C6BA0|>FFFFFFC082EECA80 0000000000000020 ........ .......
NSD:FFFFFFC0848C6BB0| 0000000000000040 FFFFFFC0836DC431 @.......1.m.....
NSD:FFFFFFC0848C6BC0| FFFFFFC082EEDA80 0000000000000000 ................
NSD:FFFFFFC0848C6BD0| 0000000000000000 FFFFFFFFFFFFFFFF ................
The address of the global is 0xFFFFFFC082EECA80 which value is 0 and its viewinfo is '<&usize_as_core::f..vmlinux\kernel_9a6cb9fd7c8dfd66_cgu\<&usize_as_core::fmt::Debug>::{vtable}'
The original size of the global is 0x20
The name of the global is kmalloc-2k
The module name of the global is 'kernel.9a6cb9fd7c8dfd66-cgu.o'
> Cheers,
> Miguel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS on
2025-07-16 7:01 ` 刘海燕 (Haiyan Liu)
@ 2025-07-16 18:21 ` Carlos Llamas
2025-07-16 20:07 ` Alice Ryhl
2025-07-17 1:34 ` 答复: " 刘海燕 (Haiyan Liu)
0 siblings, 2 replies; 16+ messages in thread
From: Carlos Llamas @ 2025-07-16 18:21 UTC (permalink / raw)
To: 刘海燕 (Haiyan Liu), Alice Ryhl, Matthew Maurer
Cc: Miguel Ojeda, Miguel Ojeda, 周平 (Ping Zhou/9032),
代子为 (Ziwei Dai),
杨丽娜 (Lina Yang),
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
王双 (Shuang Wang), Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, kasan-dev@googlegroups.com, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Martijn Coenen,
Joel Fernandes, Christian Brauner, Suren Baghdasaryan,
Jamie Cunliffe, Catalin Marinas
On Wed, Jul 16, 2025 at 07:01:29AM +0000, 刘海燕 (Haiyan Liu) wrote:
>
>
> > -----邮件原件-----
> > 发件人: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
> > 发送时间: 2025年7月16日 1:51
> > 收件人: 刘海燕 (Haiyan Liu) <haiyan.liu@unisoc.com>
> > 抄送: Miguel Ojeda <ojeda@kernel.org>; 周平 (Ping Zhou/9032) <Ping.Zhou1@unisoc.com>; 代子为 (Ziwei Dai)
> > <Ziwei.Dai@unisoc.com>; 杨丽娜 (Lina Yang) <lina.yang@unisoc.com>; linux-arm-kernel@lists.infradead.org;
> > linux-kernel@vger.kernel.org; rust-for-linux@vger.kernel.org; 王双 (Shuang Wang) <shuang.wang@unisoc.com>; Andrey Ryabinin
> > <ryabinin.a.a@gmail.com>; Alexander Potapenko <glider@google.com>; Andrey Konovalov <andreyknvl@gmail.com>; Dmitry Vyukov
> > <dvyukov@google.com>; Vincenzo Frascino <vincenzo.frascino@arm.com>; kasan-dev@googlegroups.com; Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org>; Arve Hjønnevåg <arve@android.com>; Todd Kjos <tkjos@android.com>; Martijn Coenen
> > <maco@android.com>; Joel Fernandes <joelagnelf@nvidia.com>; Christian Brauner <christian@brauner.io>; Carlos Llamas
> > <cmllamas@google.com>; Suren Baghdasaryan <surenb@google.com>; Jamie Cunliffe <Jamie.Cunliffe@arm.com>; Catalin Marinas
> > <catalin.marinas@arm.com>
> > 主题: Re: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS
> > on
> >
> >
> > 注意: 这封邮件来自于外部。除非你确定邮件内容安全，否则不要点击任何链接和附件。
> > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender
> > and know the content is safe.
> >
> >
> >
> > On Tue, Jul 15, 2025 at 11:41 AM 刘海燕 (Haiyan Liu) <haiyan.liu@unisoc.com> wrote:
> > >
> > > The commit changes the fragment and diff is:
> >
> > An Android engineer should know how to handle that, but if you are reporting upstream, it is best to try to reproduce the issue with the
> > upstream kernels (e.g. arm64 is not in 6.6.y) and provide the full kernel config used.
> >
> > > Only two rust-related global variables in fmr.rs and layout.rs have this issue. Their asan.module_ctor complied binaries are wrong.
> >
> > I am not sure what you mean by `fmr.rs`. As for `layout.rs`, that is in the `kernel` crate in 6.12.y -- isn't there a single `asan.module_ctor`
> > per TU? Which object file are you referring to? I get the pair for my `rust/kernel.o`.
>
> NSX:FFFFFFC0800A7C94|F800865E asan.module_ctor: str x30,[x18],#0x8 ; x30,[x18],#8
> NSX:FFFFFFC0800A7C98|F81F0FFE str x30,[sp,#-0x10]! ; x30,[sp,#-16]!
> NSX:FFFFFFC0800A7C9C|F00240A0 adrp x0,0xFFFFFFC0848BE000
> NSX:FFFFFFC0800A7CA0|911D8000 add x0,x0,#0x760 ; x0,x0,#1888
> NSX:FFFFFFC0800A7CA4|52803D61 mov w1,#0x1EB ; w1,#491
> NSX:FFFFFFC0800A7CA8|94233816 bl 0xFFFFFFC080975D00 ; __asan_register_globals
> NSX:FFFFFFC0800A7CAC|F84107FE ldr x30,[sp],#0x10 ; x30,[sp],#16
> NSX:FFFFFFC0800A7CB0|D50323BF autiasp
> NSX:FFFFFFC0800A7CB4|D65F03C0 ret
> The first __asan_global struct value is
> ENAXI:FFFFFFC0848BE760|>FFFFFFC082EDB180 000000000000005F ........_.......
> ENAXI:FFFFFFC0848BE770| 0000000000000080 FFFFFFC0836DC431 ........1.m.....
> ENAXI:FFFFFFC0848BE780| FFFFFFC082EEC780 0000000000000000 ................
> ENAXI:FFFFFFC0848BE790| 0000000000000000 FFFFFFFFFFFFFFFF ................
> The address of the global is 0xFFFFFFC082EDB180 which value is '/proc/self/cwd/prebuilts/rust/linux-x86/1.82.0/lib/rustlib/src/rust/library/core/src/num/fmt.rs' and its viewinfo is 'vmlinux\Global\__unnamed_357'
> The original size of the global is 0x5F
> The name of the global is kmalloc-2k
> The module name of the global is 'core.27758904ccee4c80-cgu.o'
>
> NSX:FFFFFFC0800A7D4C|F800865E asan.mod.:str x30,[x18],#0x8 ; x30,[x18],#8
> NSX:FFFFFFC0800A7D50|F81F0FFE str x30,[sp,#-0x10]! ; x30,[sp,#-16]!
> NSX:FFFFFFC0800A7D54|F00240E0 adrp x0,0xFFFFFFC0848C6000
> NSX:FFFFFFC0800A7D58|912E8000 add x0,x0,#0xBA0 ; x0,x0,#2976
> NSX:FFFFFFC0800A7D5C|52800961 mov w1,#0x4B ; w1,#75
> NSX:FFFFFFC0800A7D60|942337E8 bl 0xFFFFFFC080975D00 ; __asan_register_globals
> NSX:FFFFFFC0800A7D64|F84107FE ldr x30,[sp],#0x10 ; x30,[sp],#16
> NSX:FFFFFFC0800A7D68|D50323BF autiasp
> NSX:FFFFFFC0800A7D6C|D65F03C0 ret
> The second __asan_global struct value is
> NSD:FFFFFFC0848C6BA0|>FFFFFFC082EECA80 0000000000000020 ........ .......
> NSD:FFFFFFC0848C6BB0| 0000000000000040 FFFFFFC0836DC431 @.......1.m.....
> NSD:FFFFFFC0848C6BC0| FFFFFFC082EEDA80 0000000000000000 ................
> NSD:FFFFFFC0848C6BD0| 0000000000000000 FFFFFFFFFFFFFFFF ................
> The address of the global is 0xFFFFFFC082EECA80 which value is 0 and its viewinfo is '<&usize_as_core::f..vmlinux\kernel_9a6cb9fd7c8dfd66_cgu\<&usize_as_core::fmt::Debug>::{vtable}'
> The original size of the global is 0x20
> The name of the global is kmalloc-2k
> The module name of the global is 'kernel.9a6cb9fd7c8dfd66-cgu.o'
>
> > Cheers,
> > Miguel
We have KASAN builds with android16-6.12 and haven't seen this issue.
Can you share your entire config file, so we can try to reproduce?
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Matthew Maurer <mmaurer@google.com>
Alice, Matthew, have you seen this before?
--
Carlos Llamas
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS on
2025-07-16 18:21 ` Carlos Llamas
@ 2025-07-16 20:07 ` Alice Ryhl
2025-07-16 23:19 ` Matthew Maurer
2025-07-17 1:34 ` 答复: " 刘海燕 (Haiyan Liu)
1 sibling, 1 reply; 16+ messages in thread
From: Alice Ryhl @ 2025-07-16 20:07 UTC (permalink / raw)
To: Carlos Llamas
Cc: 刘海燕 (Haiyan Liu), Matthew Maurer,
Miguel Ojeda, Miguel Ojeda, 周平 (Ping Zhou/9032),
代子为 (Ziwei Dai),
杨丽娜 (Lina Yang),
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
王双 (Shuang Wang), Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, kasan-dev@googlegroups.com, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Martijn Coenen,
Joel Fernandes, Christian Brauner, Suren Baghdasaryan,
Jamie Cunliffe, Catalin Marinas
On Wed, Jul 16, 2025 at 8:21 PM Carlos Llamas <cmllamas@google.com> wrote:
>
> On Wed, Jul 16, 2025 at 07:01:29AM +0000, 刘海燕 (Haiyan Liu) wrote:
> >
> >
> > > -----邮件原件-----
> > > 发件人: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
> > > 发送时间: 2025年7月16日 1:51
> > > 收件人: 刘海燕 (Haiyan Liu) <haiyan.liu@unisoc.com>
> > > 抄送: Miguel Ojeda <ojeda@kernel.org>; 周平 (Ping Zhou/9032) <Ping.Zhou1@unisoc.com>; 代子为 (Ziwei Dai)
> > > <Ziwei.Dai@unisoc.com>; 杨丽娜 (Lina Yang) <lina.yang@unisoc.com>; linux-arm-kernel@lists.infradead.org;
> > > linux-kernel@vger.kernel.org; rust-for-linux@vger.kernel.org; 王双 (Shuang Wang) <shuang.wang@unisoc.com>; Andrey Ryabinin
> > > <ryabinin.a.a@gmail.com>; Alexander Potapenko <glider@google.com>; Andrey Konovalov <andreyknvl@gmail.com>; Dmitry Vyukov
> > > <dvyukov@google.com>; Vincenzo Frascino <vincenzo.frascino@arm.com>; kasan-dev@googlegroups.com; Greg Kroah-Hartman
> > > <gregkh@linuxfoundation.org>; Arve Hjønnevåg <arve@android.com>; Todd Kjos <tkjos@android.com>; Martijn Coenen
> > > <maco@android.com>; Joel Fernandes <joelagnelf@nvidia.com>; Christian Brauner <christian@brauner.io>; Carlos Llamas
> > > <cmllamas@google.com>; Suren Baghdasaryan <surenb@google.com>; Jamie Cunliffe <Jamie.Cunliffe@arm.com>; Catalin Marinas
> > > <catalin.marinas@arm.com>
> > > 主题: Re: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS
> > > on
> > >
> > >
> > > 注意: 这封邮件来自于外部。除非你确定邮件内容安全，否则不要点击任何链接和附件。
> > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender
> > > and know the content is safe.
> > >
> > >
> > >
> > > On Tue, Jul 15, 2025 at 11:41 AM 刘海燕 (Haiyan Liu) <haiyan.liu@unisoc.com> wrote:
> > > >
> > > > The commit changes the fragment and diff is:
> > >
> > > An Android engineer should know how to handle that, but if you are reporting upstream, it is best to try to reproduce the issue with the
> > > upstream kernels (e.g. arm64 is not in 6.6.y) and provide the full kernel config used.
> > >
> > > > Only two rust-related global variables in fmr.rs and layout.rs have this issue. Their asan.module_ctor complied binaries are wrong.
> > >
> > > I am not sure what you mean by `fmr.rs`. As for `layout.rs`, that is in the `kernel` crate in 6.12.y -- isn't there a single `asan.module_ctor`
> > > per TU? Which object file are you referring to? I get the pair for my `rust/kernel.o`.
> >
> > NSX:FFFFFFC0800A7C94|F800865E asan.module_ctor: str x30,[x18],#0x8 ; x30,[x18],#8
> > NSX:FFFFFFC0800A7C98|F81F0FFE str x30,[sp,#-0x10]! ; x30,[sp,#-16]!
> > NSX:FFFFFFC0800A7C9C|F00240A0 adrp x0,0xFFFFFFC0848BE000
> > NSX:FFFFFFC0800A7CA0|911D8000 add x0,x0,#0x760 ; x0,x0,#1888
> > NSX:FFFFFFC0800A7CA4|52803D61 mov w1,#0x1EB ; w1,#491
> > NSX:FFFFFFC0800A7CA8|94233816 bl 0xFFFFFFC080975D00 ; __asan_register_globals
> > NSX:FFFFFFC0800A7CAC|F84107FE ldr x30,[sp],#0x10 ; x30,[sp],#16
> > NSX:FFFFFFC0800A7CB0|D50323BF autiasp
> > NSX:FFFFFFC0800A7CB4|D65F03C0 ret
> > The first __asan_global struct value is
> > ENAXI:FFFFFFC0848BE760|>FFFFFFC082EDB180 000000000000005F ........_.......
> > ENAXI:FFFFFFC0848BE770| 0000000000000080 FFFFFFC0836DC431 ........1.m.....
> > ENAXI:FFFFFFC0848BE780| FFFFFFC082EEC780 0000000000000000 ................
> > ENAXI:FFFFFFC0848BE790| 0000000000000000 FFFFFFFFFFFFFFFF ................
> > The address of the global is 0xFFFFFFC082EDB180 which value is '/proc/self/cwd/prebuilts/rust/linux-x86/1.82.0/lib/rustlib/src/rust/library/core/src/num/fmt.rs' and its viewinfo is 'vmlinux\Global\__unnamed_357'
> > The original size of the global is 0x5F
> > The name of the global is kmalloc-2k
> > The module name of the global is 'core.27758904ccee4c80-cgu.o'
> >
> > NSX:FFFFFFC0800A7D4C|F800865E asan.mod.:str x30,[x18],#0x8 ; x30,[x18],#8
> > NSX:FFFFFFC0800A7D50|F81F0FFE str x30,[sp,#-0x10]! ; x30,[sp,#-16]!
> > NSX:FFFFFFC0800A7D54|F00240E0 adrp x0,0xFFFFFFC0848C6000
> > NSX:FFFFFFC0800A7D58|912E8000 add x0,x0,#0xBA0 ; x0,x0,#2976
> > NSX:FFFFFFC0800A7D5C|52800961 mov w1,#0x4B ; w1,#75
> > NSX:FFFFFFC0800A7D60|942337E8 bl 0xFFFFFFC080975D00 ; __asan_register_globals
> > NSX:FFFFFFC0800A7D64|F84107FE ldr x30,[sp],#0x10 ; x30,[sp],#16
> > NSX:FFFFFFC0800A7D68|D50323BF autiasp
> > NSX:FFFFFFC0800A7D6C|D65F03C0 ret
> > The second __asan_global struct value is
> > NSD:FFFFFFC0848C6BA0|>FFFFFFC082EECA80 0000000000000020 ........ .......
> > NSD:FFFFFFC0848C6BB0| 0000000000000040 FFFFFFC0836DC431 @.......1.m.....
> > NSD:FFFFFFC0848C6BC0| FFFFFFC082EEDA80 0000000000000000 ................
> > NSD:FFFFFFC0848C6BD0| 0000000000000000 FFFFFFFFFFFFFFFF ................
> > The address of the global is 0xFFFFFFC082EECA80 which value is 0 and its viewinfo is '<&usize_as_core::f..vmlinux\kernel_9a6cb9fd7c8dfd66_cgu\<&usize_as_core::fmt::Debug>::{vtable}'
> > The original size of the global is 0x20
> > The name of the global is kmalloc-2k
> > The module name of the global is 'kernel.9a6cb9fd7c8dfd66-cgu.o'
> >
> > > Cheers,
> > > Miguel
>
> We have KASAN builds with android16-6.12 and haven't seen this issue.
> Can you share your entire config file, so we can try to reproduce?
>
> Cc: Alice Ryhl <aliceryhl@google.com>
> Cc: Matthew Maurer <mmaurer@google.com>
>
> Alice, Matthew, have you seen this before?
No, this doesn't ring any bells for me. I guess we need to see a full
config so we can try and reproduce ourselves.
Alice
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS on
2025-07-16 20:07 ` Alice Ryhl
@ 2025-07-16 23:19 ` Matthew Maurer
0 siblings, 0 replies; 16+ messages in thread
From: Matthew Maurer @ 2025-07-16 23:19 UTC (permalink / raw)
To: Alice Ryhl
Cc: Carlos Llamas, 刘海燕 (Haiyan Liu),
Miguel Ojeda, Miguel Ojeda, 周平 (Ping Zhou/9032),
代子为 (Ziwei Dai),
杨丽娜 (Lina Yang),
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
王双 (Shuang Wang), Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, kasan-dev@googlegroups.com, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Martijn Coenen,
Joel Fernandes, Christian Brauner, Suren Baghdasaryan,
Jamie Cunliffe, Catalin Marinas
The reason removing that code makes your build "work" is because it
entirely disables pointer authentication in Rust code when you remove
it. That is likely not what you want.
> > We have KASAN builds with android16-6.12 and haven't seen this issue.
> > Can you share your entire config file, so we can try to reproduce?
This - please provide the config file or instructions to reproduce the
build. Since this is an upstream avenue, ideally provide instructions
for reproducing against `linux-next`, or failing that (e.g. if it's
not broken there) against v6.12.38. The default android16-6.12 build
will work fine with ASAN. If you can't provide the entire config file
in a public context, or if you only have instructions for building it
with Kleaf + fragments, or can only reproduce with the Android tree,
please reroute this request to our bug intake system (I am pretty sure
unisoc has access) and cc myself, carlos, and Alice.
^ permalink raw reply [flat|nested] 16+ messages in thread
* 答复: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS on
2025-07-16 18:21 ` Carlos Llamas
2025-07-16 20:07 ` Alice Ryhl
@ 2025-07-17 1:34 ` 刘海燕 (Haiyan Liu)
2025-07-17 7:29 ` Miguel Ojeda
1 sibling, 1 reply; 16+ messages in thread
From: 刘海燕 (Haiyan Liu) @ 2025-07-17 1:34 UTC (permalink / raw)
To: Carlos Llamas, Alice Ryhl, Matthew Maurer
Cc: Miguel Ojeda, Miguel Ojeda, 周平 (Ping Zhou/9032),
代子为 (Ziwei Dai),
杨丽娜 (Lina Yang),
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
王双 (Shuang Wang), Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, kasan-dev@googlegroups.com, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Martijn Coenen,
Joel Fernandes, Christian Brauner, Suren Baghdasaryan,
Jamie Cunliffe, Catalin Marinas
> -----邮件原件-----
> 发件人: Carlos Llamas <cmllamas@google.com>
> 发送时间: 2025年7月17日 2:21
> 收件人: 刘海燕 (Haiyan Liu) <haiyan.liu@unisoc.com>; Alice Ryhl <aliceryhl@google.com>; Matthew Maurer <mmaurer@google.com>
> 抄送: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>; Miguel Ojeda <ojeda@kernel.org>; 周平 (Ping Zhou/9032)
> <Ping.Zhou1@unisoc.com>; 代子为 (Ziwei Dai) <Ziwei.Dai@unisoc.com>; 杨丽娜 (Lina Yang) <lina.yang@unisoc.com>;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; rust-for-linux@vger.kernel.org; 王双 (Shuang Wang)
> <shuang.wang@unisoc.com>; Andrey Ryabinin <ryabinin.a.a@gmail.com>; Alexander Potapenko <glider@google.com>; Andrey Konovalov
> <andreyknvl@gmail.com>; Dmitry Vyukov <dvyukov@google.com>; Vincenzo Frascino <vincenzo.frascino@arm.com>;
> kasan-dev@googlegroups.com; Greg Kroah-Hartman <gregkh@linuxfoundation.org>; Arve Hjønnevåg <arve@android.com>; Todd Kjos
> <tkjos@android.com>; Martijn Coenen <maco@android.com>; Joel Fernandes <joelagnelf@nvidia.com>; Christian Brauner
> <christian@brauner.io>; Suren Baghdasaryan <surenb@google.com>; Jamie Cunliffe <Jamie.Cunliffe@arm.com>; Catalin Marinas
> <catalin.marinas@arm.com>
> 主题: Re: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS
> on
>
>
> 注意: 这封邮件来自于外部。除非你确定邮件内容安全，否则不要点击任何链接和附件。
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender
> and know the content is safe.
>
>
>
> On Wed, Jul 16, 2025 at 07:01:29AM +0000, 刘海燕 (Haiyan Liu) wrote:
> >
> >
> > > -----邮件原件-----
> > > 发件人: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
> > > 发送时间: 2025年7月16日 1:51
> > > 收件人: 刘海燕 (Haiyan Liu) <haiyan.liu@unisoc.com>
> > > 抄送: Miguel Ojeda <ojeda@kernel.org>; 周平 (Ping Zhou/9032)
> > > <Ping.Zhou1@unisoc.com>; 代子为 (Ziwei Dai) <Ziwei.Dai@unisoc.com>; 杨丽娜
> > > (Lina Yang) <lina.yang@unisoc.com>;
> > > linux-arm-kernel@lists.infradead.org;
> > > linux-kernel@vger.kernel.org; rust-for-linux@vger.kernel.org; 王双
> > > (Shuang Wang) <shuang.wang@unisoc.com>; Andrey Ryabinin
> > > <ryabinin.a.a@gmail.com>; Alexander Potapenko <glider@google.com>;
> > > Andrey Konovalov <andreyknvl@gmail.com>; Dmitry Vyukov
> > > <dvyukov@google.com>; Vincenzo Frascino <vincenzo.frascino@arm.com>;
> > > kasan-dev@googlegroups.com; Greg Kroah-Hartman
> > > <gregkh@linuxfoundation.org>; Arve Hjønnevåg <arve@android.com>;
> > > Todd Kjos <tkjos@android.com>; Martijn Coenen <maco@android.com>;
> > > Joel Fernandes <joelagnelf@nvidia.com>; Christian Brauner
> > > <christian@brauner.io>; Carlos Llamas <cmllamas@google.com>; Suren
> > > Baghdasaryan <surenb@google.com>; Jamie Cunliffe
> > > <Jamie.Cunliffe@arm.com>; Catalin Marinas <catalin.marinas@arm.com>
> > > 主题: Re: Meet compiled kernel binaray abnormal issue while enabling
> > > generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS on
> > >
> > >
> > > 注意: 这封邮件来自于外部。除非你确定邮件内容安全，否则不要点击任何链接和附件。
> > > CAUTION: This email originated from outside of the organization. Do
> > > not click links or open attachments unless you recognize the sender and know the content is safe.
> > >
> > >
> > >
> > > On Tue, Jul 15, 2025 at 11:41 AM 刘海燕 (Haiyan Liu) <haiyan.liu@unisoc.com> wrote:
> > > >
> > > > The commit changes the fragment and diff is:
> > >
> > > An Android engineer should know how to handle that, but if you are
> > > reporting upstream, it is best to try to reproduce the issue with the upstream kernels (e.g. arm64 is not in 6.6.y) and provide the full
> kernel config used.
> > >
> > > > Only two rust-related global variables in fmr.rs and layout.rs have this issue. Their asan.module_ctor complied binaries are wrong.
> > >
> > > I am not sure what you mean by `fmr.rs`. As for `layout.rs`, that is
> > > in the `kernel` crate in 6.12.y -- isn't there a single `asan.module_ctor` per TU? Which object file are you referring to? I get the pair for
> my `rust/kernel.o`.
> >
> > NSX:FFFFFFC0800A7C94|F800865E asan.module_ctor: str x30,[x18],#0x8 ; x30,[x18],#8
> > NSX:FFFFFFC0800A7C98|F81F0FFE str x30,[sp,#-0x10]! ; x30,[sp,#-16]!
> > NSX:FFFFFFC0800A7C9C|F00240A0 adrp x0,0xFFFFFFC0848BE000
> > NSX:FFFFFFC0800A7CA0|911D8000 add x0,x0,#0x760 ; x0,x0,#1888
> > NSX:FFFFFFC0800A7CA4|52803D61 mov w1,#0x1EB ; w1,#491
> > NSX:FFFFFFC0800A7CA8|94233816 bl 0xFFFFFFC080975D00 ; __asan_register_globals
> > NSX:FFFFFFC0800A7CAC|F84107FE ldr x30,[sp],#0x10 ; x30,[sp],#16
> > NSX:FFFFFFC0800A7CB0|D50323BF autiasp
> > NSX:FFFFFFC0800A7CB4|D65F03C0 ret
> > The first __asan_global struct value is
> > ENAXI:FFFFFFC0848BE760|>FFFFFFC082EDB180 000000000000005F ........_.......
> > ENAXI:FFFFFFC0848BE770| 0000000000000080 FFFFFFC0836DC431 ........1.m.....
> > ENAXI:FFFFFFC0848BE780| FFFFFFC082EEC780 0000000000000000 ................
> > ENAXI:FFFFFFC0848BE790| 0000000000000000 FFFFFFFFFFFFFFFF ................
> > The address of the global is 0xFFFFFFC082EDB180 which value is
> '/proc/self/cwd/prebuilts/rust/linux-x86/1.82.0/lib/rustlib/src/rust/library/core/src/num/fmt.rs' and its viewinfo is
> 'vmlinux\Global\__unnamed_357'
> > The original size of the global is 0x5F The name of the global is
> > kmalloc-2k The module name of the global is
> > 'core.27758904ccee4c80-cgu.o'
> >
> > NSX:FFFFFFC0800A7D4C|F800865E asan.mod.:str x30,[x18],#0x8 ; x30,[x18],#8
> > NSX:FFFFFFC0800A7D50|F81F0FFE str x30,[sp,#-0x10]! ; x30,[sp,#-16]!
> > NSX:FFFFFFC0800A7D54|F00240E0 adrp x0,0xFFFFFFC0848C6000
> > NSX:FFFFFFC0800A7D58|912E8000 add x0,x0,#0xBA0 ; x0,x0,#2976
> > NSX:FFFFFFC0800A7D5C|52800961 mov w1,#0x4B ; w1,#75
> > NSX:FFFFFFC0800A7D60|942337E8 bl 0xFFFFFFC080975D00 ; __asan_register_globals
> > NSX:FFFFFFC0800A7D64|F84107FE ldr x30,[sp],#0x10 ; x30,[sp],#16
> > NSX:FFFFFFC0800A7D68|D50323BF autiasp
> > NSX:FFFFFFC0800A7D6C|D65F03C0 ret
> > The second __asan_global struct value is
> > NSD:FFFFFFC0848C6BA0|>FFFFFFC082EECA80 0000000000000020 ........ .......
> > NSD:FFFFFFC0848C6BB0| 0000000000000040 FFFFFFC0836DC431 @.......1.m.....
> > NSD:FFFFFFC0848C6BC0| FFFFFFC082EEDA80 0000000000000000 ................
> > NSD:FFFFFFC0848C6BD0| 0000000000000000 FFFFFFFFFFFFFFFF ................
> > The address of the global is 0xFFFFFFC082EECA80 which value is 0 and its viewinfo is
> '<&usize_as_core::f..vmlinux\kernel_9a6cb9fd7c8dfd66_cgu\<&usize_as_core::fmt::Debug>::{vtable}'
> > The original size of the global is 0x20 The name of the global is
> > kmalloc-2k The module name of the global is
> > 'kernel.9a6cb9fd7c8dfd66-cgu.o'
> >
> > > Cheers,
> > > Miguel
>
> We have KASAN builds with android16-6.12 and haven't seen this issue.
> Can you share your entire config file, so we can try to reproduce?
The config file is included in the compressed file kernel_artifacts.tgz which can get from ' http://artifactory.unisoc.com/ui/native/VERIFY_ANDROID/1746740/PAC/sprdroid15_sys_dev_plus_sprdroid15_vnd_dev_plus_sprdlinux6.12_kernel_dev/ums9632_1h10_64only_k612-userdebug-gms/sprdlinux6.12_kernel_dev/ums9632_1h10_64only_k612-userdebug/' . The path is 'kernel_artifacts/ums9632_arm64_kernel6.12-userdebug/kernel'.
Can you get it?
> Cc: Alice Ryhl <aliceryhl@google.com>
> Cc: Matthew Maurer <mmaurer@google.com>
>
> Alice, Matthew, have you seen this before?
>
> --
> Carlos Llamas
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS on
2025-07-17 1:34 ` 答复: " 刘海燕 (Haiyan Liu)
@ 2025-07-17 7:29 ` Miguel Ojeda
0 siblings, 0 replies; 16+ messages in thread
From: Miguel Ojeda @ 2025-07-17 7:29 UTC (permalink / raw)
To: 刘海燕 (Haiyan Liu)
Cc: Carlos Llamas, Alice Ryhl, Matthew Maurer, Miguel Ojeda,
周平 (Ping Zhou/9032),
代子为 (Ziwei Dai),
杨丽娜 (Lina Yang),
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
王双 (Shuang Wang), Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, kasan-dev@googlegroups.com, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Martijn Coenen,
Joel Fernandes, Christian Brauner, Suren Baghdasaryan,
Jamie Cunliffe, Catalin Marinas
On Thu, Jul 17, 2025 at 3:35 AM 刘海燕 (Haiyan Liu) <haiyan.liu@unisoc.com> wrote:
>
> The config file is included in the compressed file kernel_artifacts.tgz which can get from ' http://artifactory.unisoc.com/ui/native/VERIFY_ANDROID/1746740/PAC/sprdroid15_sys_dev_plus_sprdroid15_vnd_dev_plus_sprdlinux6.12_kernel_dev/ums9632_1h10_64only_k612-userdebug-gms/sprdlinux6.12_kernel_dev/ums9632_1h10_64only_k612-userdebug/' . The path is 'kernel_artifacts/ums9632_arm64_kernel6.12-userdebug/kernel'.
>
> Can you get it?
If you mean to report upstream, then please post the config as a
simple text attachment here and clarify how to reproduce the issue
with an upstream kernel, as I and others have mentioned since the
first reply.
Cheers,
Miguel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS on
2025-07-14 3:12 Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS on 刘海燕 (Haiyan Liu)
2025-07-14 20:04 ` Miguel Ojeda
[not found] ` <202507150830.56F8U908028199@SHSPAM01.spreadtrum.com>
@ 2025-07-17 10:38 ` Mark Rutland
2025-07-21 6:10 ` Ard Biesheuvel
2 siblings, 1 reply; 16+ messages in thread
From: Mark Rutland @ 2025-07-17 10:38 UTC (permalink / raw)
To: 刘海燕 (Haiyan Liu)
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
rust-for-linux@vger.kernel.org,
代子为 (Ziwei Dai),
周平 (Ping Zhou/9032),
杨丽娜 (Lina Yang),
王双 (Shuang Wang), Alice Ryhl, Miguel Ojeda,
Matthew Maurer, Ard Biesheuvel, Sami Tolvanen
Hi,
From a quick scan, I think this might have something to do with
UNWIND_PATCH_PAC_INTO_SCS, notes below.
On Mon, Jul 14, 2025 at 03:12:33AM +0000, 刘海燕 (Haiyan Liu) wrote:
> I am enabling generic kasan feature in kernel 6.12, and met kernel boot crash.
> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
> pc : do_basic_setup+0x6c/0xac
> lr : do_basic_setup+0x88/0xac
> sp : ffffffc080087e40
Can you say which hardware this is on? Given this is a NULL-dereference,
this looks ike a dodgy pointer (or memory corruption) rather than a PAC
failure.
> After debug, I find some error in do_ctors().
> Normally, the complier should insert the paciasp instruction at the function entry so that its corresponding autiasp instruction is used to validate the return address when the function returns.
> NSX:FFFFFFC0800A840C|F800865E asan.module_ctor: str x30,[x18],#0x8；x30,[x18],#8
> NSX:FFFFFFC0800A8410|A9BF7BFD stp x29,x30,[sp,#-0x10]! ; x29,x30,[sp,#-16]!
> NSX:FFFFFFC0800A8414|910003FD mov x29,sp
> NSX:FFFFFFC0800A8418|B0023420 adrp x0,0xFFFFFFC08472D000
> NSX:FFFFFFC0800A841C|91390000 add x0,x0,#0xE40 ; x0,x0,#3648
> NSX:FFFFFFC0800A8420|528000A1 mov w1,#0x5 ; w1,#5
> NSX:FFFFFFC0800A8424|9422AF50 bl 0xFFFFFFC080954164 ; __asan_register_globals
> NSX:FFFFFFC0800A8428|A8C17BFD ldp x29,x30,[sp],#0x10 ; x29,x30,[sp],#16
> NSX:FFFFFFC0800A842C|F85F8E5E ldr x30,[x18,#-0x8]! ; x30,[x18,#-8]!
> NSX:FFFFFFC0800A8430|D65F03C0 ret
Here you evidently have shadow call stack enabled...
> NSX:FFFFFFC0800A8478|D503233F asan.module_ctor: paciasp
> NSX:FFFFFFC0800A847C|A9BF7BFD stp x29,x30,[sp,#-0x10]! ; x29,x30,[sp,#-16]!
> NSX:FFFFFFC0800A8480|910003FD mov x29,sp
> NSX:FFFFFFC0800A8484|B0023420 adrp x0,0xFFFFFFC08472D000
> NSX:FFFFFFC0800A8488|913E0000 add x0,x0,#0xF80 ; x0,x0,#3968
> NSX:FFFFFFC0800A848C|52800021 mov w1,#0x1 ; w1,#1
> NSX:FFFFFFC0800A8490|9422AF35 bl 0xFFFFFFC080954164 ; __asan_register_globals
> NSX:FFFFFFC0800A8494|A8C17BFD ldp x29,x30,[sp],#0x10 ; x29,x30,[sp],#16
> NSX:FFFFFFC0800A8498|D50323BF autiasp
> NSX:FFFFFFC0800A849C|D65F03C0 ret
... but here you evidently don't, and have PAC instead.
Are these from the same kernel Image?
Are these decoded from the static kernel binary, or are these dumps from
memory once a kernel has booted (or is in the process of booting)?
> But actually, in two asan.module_ctor functions, there is only autiasp instruction inserted before return, for validation of return address, while paciasp instruction is missing before.
> NSX:FFFFFFC0800A72D8|F800865E asan.module_ctor: str x30,[x18],#0x8 ; x30,[x18],#8
> NSX:FFFFFFC0800A72DC|F81F0FFE str x30,[sp,#-0x10]! ; x30,[sp,#-16]!
> NSX:FFFFFFC0800A72E0|B00233C0 adrp x0,0xFFFFFFC084720000
> NSX:FFFFFFC0800A72E4|91350000 add x0,x0,#0xD40 ; x0,x0,#3392
> NSX:FFFFFFC0800A72E8|52803D61 mov w1,#0x1EB ; w1,#491
> NSX:FFFFFFC0800A72EC|9422B39E bl 0xFFFFFFC080954164 ; __asan_register_globals
> NSX:FFFFFFC0800A72F0|F84107FE ldr x30,[sp],#0x10 ; x30,[sp],#16
> NSX:FFFFFFC0800A72F4|D50323BF autiasp
> NSX:FFFFFFC0800A72F8|D65F03C0 ret
Thas has a mixture of SCS and PAC; there's a shadow call stack prologue
but a PAC epilogue:
str x30, [x18], #8 // SCS
...
autiasp // PAC
... so I'll hazard a guess that these are dumps from memory, and you
have UNWIND_PATCH_PAC_INTO_SCS selected. Assuming that is the case,
either this dump has been made mid-patching, or the patching has gone
wrong somehow and left the prologues/epilogues in an inconsistent state
(and the NULL dereference could be a secondary effect of that).
Ard, does that sound plausible to you?
I can't see why that would depend on KBUILD_RUSTFLAGS, but maybe the
DWARF generated by rustc has confused the patching code somehow, or the
linker has aggregated that in a suprising way.
Mark.
> NSX:FFFFFFC0800A7390|F800865E asan.module_ctor: str x30,[x18],#0x8 ; x30,[x18],#8
> NSX:FFFFFFC0800A7394|F81F0FFE str x30,[sp,#-0x10]! ; x30,[sp,#-16]!
> NSX:FFFFFFC0800A7398|B0023400 adrp x0,0xFFFFFFC084728000
> NSX:FFFFFFC0800A739C|91210000 add x0,x0,#0x840 ; x0,x0,#2112
> NSX:FFFFFFC0800A73A0|528006E1 mov w1,#0x37 ; w1,#55
> NSX:FFFFFFC0800A73A4|9422B370 bl 0xFFFFFFC080954164 ; __asan_register_globals
> NSX:FFFFFFC0800A73A8|F84107FE ldr x30,[sp],#0x10 ; x30,[sp],#16
> NSX:FFFFFFC0800A73AC|D50323BF autiasp
> NSX:FFFFFFC0800A73B0|D65F03C0 ret
>
> I compare kernel 6.6 and kernel 6.12 ARM Makefile, and find the difference.
> Kernel6.6 Makefile
> 66 ifeq ($(CONFIG_ARM64_BTI_KERNEL),y)
> 67 KBUILD_CFLAGS += -mbranch-protection=pac-ret+bti
> 68 else ifeq ($(CONFIG_ARM64_PTR_AUTH_KERNEL),y)
> 69 ifeq ($(CONFIG_CC_HAS_BRANCH_PROT_PAC_RET),y)
> 70 KBUILD_CFLAGS += -mbranch-protection=pac-ret
> 71 else
> 72 KBUILD_CFLAGS += -msign-return-address=non-leaf
> 73 endif
> 74 else
> 75 KBUILD_CFLAGS += $(call cc-option,-mbranch-protection=none)
> 76 endif
>
> Kernel6.12 Makefile
> 81 ifeq ($(CONFIG_ARM64_BTI_KERNEL),y)
> 82 KBUILD_CFLAGS += -mbranch-protection=pac-ret+bti
> 83 KBUILD_RUSTFLAGS += -Zbranch-protection=bti,pac-ret
> 84 else ifeq ($(CONFIG_ARM64_PTR_AUTH_KERNEL),y)
> 85 KBUILD_RUSTFLAGS += -Zbranch-protection=pac-ret
> 86 ifeq ($(CONFIG_CC_HAS_BRANCH_PROT_PAC_RET),y)
> 87 KBUILD_CFLAGS += -mbranch-protection=pac-ret
> 88 else
> 89 KBUILD_CFLAGS += -msign-return-address=non-leaf
> 90 endif
> 91 else
> 92 KBUILD_CFLAGS += $(call cc-option,-mbranch-protection=none)
> 93 endif
>
> After I delete the rust build flags, the asan.module_ctor binary is right and kasan feature works fine.Could you help check why KBUILD_RUSTFLAGS impacts kernel complication with kasan feature enabled and how can this issue fixed?
>
> I use the build.config.constants:
> BRANCH=android16-6.12
> KMI_GENERATION=4
> CLANG_VERSION=r536225
> RUSTC_VERSION=1.82.0
> AARCH64_NDK_TRIPLE=aarch64-linux-android31
> X86_64_NDK_TRIPLE=x86_64-linux-android31
> ARM_NDK_TRIPLE=arm-linux-androideabi31
>
> compile configuration is :
> CONFIG_GCC_VERSION=0
> CONFIG_CC_IS_CLANG=y
> CONFIG_CLANG_VERSION=190001
> CONFIG_AS_IS_LLVM=y
> CONFIG_AS_VERSION=190001
> CONFIG_LD_VERSION=0
> CONFIG_LD_IS_LLD=y
> CONFIG_LLD_VERSION=190001
> CONFIG_RUSTC_VERSION=108200
> CONFIG_RUST_IS_AVAILABLE=y
> CONFIG_RUSTC_LLVM_VERSION=190001
> CONFIG_CC_CAN_LINK=y
> CONFIG_CC_CAN_LINK_STATIC=y
> CONFIG_CC_HAS_ASM_GOTO_OUTPUT=y
> CONFIG_CC_HAS_ASM_GOTO_TIED_OUTPUT=y
> CONFIG_TOOLS_SUPPORT_RELR=y
> CONFIG_CC_HAS_ASM_INLINE=y
> CONFIG_CC_HAS_NO_PROFILE_FN_ATTR=y
> CONFIG_PAHOLE_VERSION=125
> CONFIG_IRQ_WORK=y
> CONFIG_BUILDTIME_TABLE_SORT=y
> CONFIG_THREAD_INFO_IN_TASK=y
>
> Thank you
^ permalink raw reply [flat|nested] 16+ messages in thread
* Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS on
@ 2025-07-17 11:25 刘海燕 (Haiyan Liu)
2025-07-17 13:06 ` Mark Rutland
0 siblings, 1 reply; 16+ messages in thread
From: 刘海燕 (Haiyan Liu) @ 2025-07-17 11:25 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
rust-for-linux@vger.kernel.org,
代子为 (Ziwei Dai),
周平 (Ping Zhou/9032),
杨丽娜 (Lina Yang),
王双 (Shuang Wang), Alice Ryhl, Miguel Ojeda,
Matthew Maurer, Ard Biesheuvel, Sami Tolvanen
> -----邮件原件-----
> 发件人: Mark Rutland <mark.rutland@arm.com>
> 发送时间: 2025年7月17日 18:39
> 收件人: 刘海燕 (Haiyan Liu) <haiyan.liu@unisoc.com>
> 抄送: linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; rust-for-linux@vger.kernel.org; 代子为 (Ziwei Dai)
> <Ziwei.Dai@unisoc.com>; 周平 (Ping Zhou/9032) <Ping.Zhou1@unisoc.com>; 杨丽娜 (Lina Yang) <lina.yang@unisoc.com>; 王双
> (Shuang Wang) <shuang.wang@unisoc.com>; Alice Ryhl <aliceryhl@google.com>; Miguel Ojeda <ojeda@kernel.org>; Matthew Maurer
> <mmaurer@google.com>; Ard Biesheuvel <ardb@kernel.org>; Sami Tolvanen <samitolvanen@google.com>
> 主题: Re: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS
> on
>
>
> 注意: 这封邮件来自于外部。除非你确定邮件内容安全，否则不要点击任何链接和附件。
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender
> and know the content is safe.
>
>
>
> Hi,
>
> From a quick scan, I think this might have something to do with UNWIND_PATCH_PAC_INTO_SCS, notes below.
>
> On Mon, Jul 14, 2025 at 03:12:33AM +0000, 刘海燕 (Haiyan Liu) wrote:
> > I am enabling generic kasan feature in kernel 6.12, and met kernel boot crash.
> > Unable to handle kernel NULL pointer dereference at virtual address
> > 0000000000000008 pc : do_basic_setup+0x6c/0xac lr :
> > do_basic_setup+0x88/0xac sp : ffffffc080087e40
>
> Can you say which hardware this is on? Given this is a NULL-dereference, this looks ike a dodgy pointer (or memory corruption) rather than
> a PAC failure.
>
> > After debug, I find some error in do_ctors().
> > Normally, the complier should insert the paciasp instruction at the function entry so that its corresponding autiasp instruction is used to
> validate the return address when the function returns.
> > NSX:FFFFFFC0800A840C|F800865E asan.module_ctor: str x30,[x18],#0x8；x30,[x18],#8
> > NSX:FFFFFFC0800A8410|A9BF7BFD stp x29,x30,[sp,#-0x10]! ; x29,x30,[sp,#-16]!
> > NSX:FFFFFFC0800A8414|910003FD mov x29,sp
> > NSX:FFFFFFC0800A8418|B0023420 adrp x0,0xFFFFFFC08472D000
> > NSX:FFFFFFC0800A841C|91390000 add x0,x0,#0xE40 ; x0,x0,#3648
> > NSX:FFFFFFC0800A8420|528000A1 mov w1,#0x5 ; w1,#5
> > NSX:FFFFFFC0800A8424|9422AF50 bl 0xFFFFFFC080954164 ; __asan_register_globals
> > NSX:FFFFFFC0800A8428|A8C17BFD ldp x29,x30,[sp],#0x10 ; x29,x30,[sp],#16
> > NSX:FFFFFFC0800A842C|F85F8E5E ldr x30,[x18,#-0x8]! ; x30,[x18,#-8]!
> > NSX:FFFFFFC0800A8430|D65F03C0 ret
>
> Here you evidently have shadow call stack enabled...
>
> > NSX:FFFFFFC0800A8478|D503233F asan.module_ctor: paciasp
> > NSX:FFFFFFC0800A847C|A9BF7BFD stp x29,x30,[sp,#-0x10]! ; x29,x30,[sp,#-16]!
> > NSX:FFFFFFC0800A8480|910003FD mov x29,sp
> > NSX:FFFFFFC0800A8484|B0023420 adrp x0,0xFFFFFFC08472D000
> > NSX:FFFFFFC0800A8488|913E0000 add x0,x0,#0xF80 ; x0,x0,#3968
> > NSX:FFFFFFC0800A848C|52800021 mov w1,#0x1 ; w1,#1
> > NSX:FFFFFFC0800A8490|9422AF35 bl 0xFFFFFFC080954164 ; __asan_register_globals
> > NSX:FFFFFFC0800A8494|A8C17BFD ldp x29,x30,[sp],#0x10 ; x29,x30,[sp],#16
> > NSX:FFFFFFC0800A8498|D50323BF autiasp
> > NSX:FFFFFFC0800A849C|D65F03C0 ret
>
> ... but here you evidently don't, and have PAC instead.
>
> Are these from the same kernel Image?
Yes, they are from the same kernel image but not the same asan.module_ctor function. The GlobalVariable are different.
> Are these decoded from the static kernel binary, or are these dumps from memory once a kernel has booted (or is in the process of
> booting)?
These are dumped from memory during the kernel booted by trace32.
> > But actually, in two asan.module_ctor functions, there is only autiasp instruction inserted before return, for validation of return address,
> while paciasp instruction is missing before.
> > NSX:FFFFFFC0800A72D8|F800865E asan.module_ctor: str x30,[x18],#0x8 ; x30,[x18],#8
> > NSX:FFFFFFC0800A72DC|F81F0FFE str x30,[sp,#-0x10]! ; x30,[sp,#-16]!
> > NSX:FFFFFFC0800A72E0|B00233C0 adrp x0,0xFFFFFFC084720000
> > NSX:FFFFFFC0800A72E4|91350000 add x0,x0,#0xD40 ; x0,x0,#3392
> > NSX:FFFFFFC0800A72E8|52803D61 mov w1,#0x1EB ; w1,#491
> > NSX:FFFFFFC0800A72EC|9422B39E bl 0xFFFFFFC080954164 ; __asan_register_globals
> > NSX:FFFFFFC0800A72F0|F84107FE ldr x30,[sp],#0x10 ; x30,[sp],#16
> > NSX:FFFFFFC0800A72F4|D50323BF autiasp
> > NSX:FFFFFFC0800A72F8|D65F03C0 ret
>
> Thas has a mixture of SCS and PAC; there's a shadow call stack prologue but a PAC epilogue:
>
> str x30, [x18], #8 // SCS
> ...
> autiasp // PAC
Yes, this is my issue and I wanted to resolve.
> ... so I'll hazard a guess that these are dumps from memory, and you have UNWIND_PATCH_PAC_INTO_SCS selected. Assuming that is the
> case, either this dump has been made mid-patching, or the patching has gone wrong somehow and left the prologues/epilogues in an
> inconsistent state (and the NULL dereference could be a secondary effect of that).
>
> Ard, does that sound plausible to you?
>
> I can't see why that would depend on KBUILD_RUSTFLAGS, but maybe the DWARF generated by rustc has confused the patching code
> somehow, or the linker has aggregated that in a suprising way.
> Mark.
Yes, Thank you. What can cause this issue? Can you give some directions so that we can gradually investigate.
>
> > NSX:FFFFFFC0800A7390|F800865E asan.module_ctor: str x30,[x18],#0x8 ; x30,[x18],#8
> > NSX:FFFFFFC0800A7394|F81F0FFE str x30,[sp,#-0x10]! ; x30,[sp,#-16]!
> > NSX:FFFFFFC0800A7398|B0023400 adrp x0,0xFFFFFFC084728000
> > NSX:FFFFFFC0800A739C|91210000 add x0,x0,#0x840 ; x0,x0,#2112
> > NSX:FFFFFFC0800A73A0|528006E1 mov w1,#0x37 ; w1,#55
> > NSX:FFFFFFC0800A73A4|9422B370 bl 0xFFFFFFC080954164 ; __asan_register_globals
> > NSX:FFFFFFC0800A73A8|F84107FE ldr x30,[sp],#0x10 ; x30,[sp],#16
> > NSX:FFFFFFC0800A73AC|D50323BF autiasp
> > NSX:FFFFFFC0800A73B0|D65F03C0 ret
> >
> > I compare kernel 6.6 and kernel 6.12 ARM Makefile, and find the difference.
> > Kernel6.6 Makefile
> > 66 ifeq ($(CONFIG_ARM64_BTI_KERNEL),y)
> > 67 KBUILD_CFLAGS += -mbranch-protection=pac-ret+bti
> > 68 else ifeq ($(CONFIG_ARM64_PTR_AUTH_KERNEL),y)
> > 69 ifeq ($(CONFIG_CC_HAS_BRANCH_PROT_PAC_RET),y)
> > 70 KBUILD_CFLAGS += -mbranch-protection=pac-ret
> > 71 else
> > 72 KBUILD_CFLAGS += -msign-return-address=non-leaf
> > 73 endif
> > 74 else
> > 75 KBUILD_CFLAGS += $(call cc-option,-mbranch-protection=none)
> > 76 endif
> >
> > Kernel6.12 Makefile
> > 81 ifeq ($(CONFIG_ARM64_BTI_KERNEL),y)
> > 82 KBUILD_CFLAGS += -mbranch-protection=pac-ret+bti
> > 83 KBUILD_RUSTFLAGS += -Zbranch-protection=bti,pac-ret
> > 84 else ifeq ($(CONFIG_ARM64_PTR_AUTH_KERNEL),y)
> > 85 KBUILD_RUSTFLAGS += -Zbranch-protection=pac-ret
> > 86 ifeq ($(CONFIG_CC_HAS_BRANCH_PROT_PAC_RET),y)
> > 87 KBUILD_CFLAGS += -mbranch-protection=pac-ret
> > 88 else
> > 89 KBUILD_CFLAGS += -msign-return-address=non-leaf
> > 90 endif
> > 91 else
> > 92 KBUILD_CFLAGS += $(call cc-option,-mbranch-protection=none)
> > 93 endif
> >
> > After I delete the rust build flags, the asan.module_ctor binary is right and kasan feature works fine.Could you help check why
> KBUILD_RUSTFLAGS impacts kernel complication with kasan feature enabled and how can this issue fixed?
> >
> > I use the build.config.constants:
> > BRANCH=android16-6.12
> > KMI_GENERATION=4
> > CLANG_VERSION=r536225
> > RUSTC_VERSION=1.82.0
> > AARCH64_NDK_TRIPLE=aarch64-linux-android31
> > X86_64_NDK_TRIPLE=x86_64-linux-android31
> > ARM_NDK_TRIPLE=arm-linux-androideabi31
> >
> > compile configuration is :
> > CONFIG_GCC_VERSION=0
> > CONFIG_CC_IS_CLANG=y
> > CONFIG_CLANG_VERSION=190001
> > CONFIG_AS_IS_LLVM=y
> > CONFIG_AS_VERSION=190001
> > CONFIG_LD_VERSION=0
> > CONFIG_LD_IS_LLD=y
> > CONFIG_LLD_VERSION=190001
> > CONFIG_RUSTC_VERSION=108200
> > CONFIG_RUST_IS_AVAILABLE=y
> > CONFIG_RUSTC_LLVM_VERSION=190001
> > CONFIG_CC_CAN_LINK=y
> > CONFIG_CC_CAN_LINK_STATIC=y
> > CONFIG_CC_HAS_ASM_GOTO_OUTPUT=y
> > CONFIG_CC_HAS_ASM_GOTO_TIED_OUTPUT=y
> > CONFIG_TOOLS_SUPPORT_RELR=y
> > CONFIG_CC_HAS_ASM_INLINE=y
> > CONFIG_CC_HAS_NO_PROFILE_FN_ATTR=y
> > CONFIG_PAHOLE_VERSION=125
> > CONFIG_IRQ_WORK=y
> > CONFIG_BUILDTIME_TABLE_SORT=y
> > CONFIG_THREAD_INFO_IN_TASK=y
> >
> > Thank you
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS on
2025-07-17 11:25 刘海燕 (Haiyan Liu)
@ 2025-07-17 13:06 ` Mark Rutland
0 siblings, 0 replies; 16+ messages in thread
From: Mark Rutland @ 2025-07-17 13:06 UTC (permalink / raw)
To: 刘海燕 (Haiyan Liu)
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
rust-for-linux@vger.kernel.org,
代子为 (Ziwei Dai),
周平 (Ping Zhou/9032),
杨丽娜 (Lina Yang),
王双 (Shuang Wang), Alice Ryhl, Miguel Ojeda,
Matthew Maurer, Ard Biesheuvel, Sami Tolvanen
On Thu, Jul 17, 2025 at 11:25:00AM +0000, 刘海燕 (Haiyan Liu) wrote:
> > -----邮件原件-----
> > 发件人: Mark Rutland <mark.rutland@arm.com>
> > From a quick scan, I think this might have something to do with UNWIND_PATCH_PAC_INTO_SCS, notes below.
> >
> > On Mon, Jul 14, 2025 at 03:12:33AM +0000, 刘海燕 (Haiyan Liu) wrote:
> > > I am enabling generic kasan feature in kernel 6.12, and met kernel boot crash.
> > > Unable to handle kernel NULL pointer dereference at virtual address
> > > 0000000000000008 pc : do_basic_setup+0x6c/0xac lr :
> > > do_basic_setup+0x88/0xac sp : ffffffc080087e40
> > Here you evidently have shadow call stack enabled...
> >
> > > NSX:FFFFFFC0800A8478|D503233F asan.module_ctor: paciasp
> > > NSX:FFFFFFC0800A847C|A9BF7BFD stp x29,x30,[sp,#-0x10]! ; x29,x30,[sp,#-16]!
> > > NSX:FFFFFFC0800A8480|910003FD mov x29,sp
> > > NSX:FFFFFFC0800A8484|B0023420 adrp x0,0xFFFFFFC08472D000
> > > NSX:FFFFFFC0800A8488|913E0000 add x0,x0,#0xF80 ; x0,x0,#3968
> > > NSX:FFFFFFC0800A848C|52800021 mov w1,#0x1 ; w1,#1
> > > NSX:FFFFFFC0800A8490|9422AF35 bl 0xFFFFFFC080954164 ; __asan_register_globals
> > > NSX:FFFFFFC0800A8494|A8C17BFD ldp x29,x30,[sp],#0x10 ; x29,x30,[sp],#16
> > > NSX:FFFFFFC0800A8498|D50323BF autiasp
> > > NSX:FFFFFFC0800A849C|D65F03C0 ret
> >
> > ... but here you evidently don't, and have PAC instead.
> > Are these decoded from the static kernel binary, or are these dumps
> > from memory once a kernel has booted (or is in the process of
> > booting)?
>
> These are dumped from memory during the kernel booted by trace32.
At which point have you dumped the memory contents? e.g. has the kernel
booted to a prompt before you make the dump, or have you stopped the
kernel early during the boot process?
Are you certain this is dumped *after* scs_patch() has run?
> > > But actually, in two asan.module_ctor functions, there is only autiasp instruction inserted before return, for validation of return address,
> > while paciasp instruction is missing before.
> > > NSX:FFFFFFC0800A72D8|F800865E asan.module_ctor: str x30,[x18],#0x8 ; x30,[x18],#8
> > > NSX:FFFFFFC0800A72DC|F81F0FFE str x30,[sp,#-0x10]! ; x30,[sp,#-16]!
> > > NSX:FFFFFFC0800A72E0|B00233C0 adrp x0,0xFFFFFFC084720000
> > > NSX:FFFFFFC0800A72E4|91350000 add x0,x0,#0xD40 ; x0,x0,#3392
> > > NSX:FFFFFFC0800A72E8|52803D61 mov w1,#0x1EB ; w1,#491
> > > NSX:FFFFFFC0800A72EC|9422B39E bl 0xFFFFFFC080954164 ; __asan_register_globals
> > > NSX:FFFFFFC0800A72F0|F84107FE ldr x30,[sp],#0x10 ; x30,[sp],#16
> > > NSX:FFFFFFC0800A72F4|D50323BF autiasp
> > > NSX:FFFFFFC0800A72F8|D65F03C0 ret
> >
> > Thas has a mixture of SCS and PAC; there's a shadow call stack prologue but a PAC epilogue:
> >
> > str x30, [x18], #8 // SCS
> > ...
> > autiasp // PAC
>
> Yes, this is my issue and I wanted to resolve.
>
> > ... so I'll hazard a guess that these are dumps from memory,
This was confirmed above...
> > and you have UNWIND_PATCH_PAC_INTO_SCS selected.
... can you please confirm this? i.e. does your config have
CONFIG_UNWIND_PATCH_PAC_INTO_SCS selected?
> > Assuming that is the case, either this dump has been made
> > mid-patching, or the patching has gone wrong somehow and left the
> > prologues/epilogues in an inconsistent state (and the NULL
> > dereference could be a secondary effect of that).
> >
> > Ard, does that sound plausible to you?
> >
> > I can't see why that would depend on KBUILD_RUSTFLAGS, but maybe the DWARF generated by rustc has confused the patching code
> > somehow, or the linker has aggregated that in a suprising way.
> > Mark.
>
> Yes, Thank you. What can cause this issue? Can you give some
> directions so that we can gradually investigate.
Find out specifically where the affected asan.module_ctor functions are
from, i.e. whether they're generated by rustc or the C compiler that
you're using.
Go and read scs_patch(), see what it does, and check the data it
consumes.
See if rustc is generating DWARF as we expect or not.
See if the linker is combining that correctly into the resulting
vmlinux, and that this correctly propagates into the resulting Image.
Mark.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS on
2025-07-17 10:38 ` Mark Rutland
@ 2025-07-21 6:10 ` Ard Biesheuvel
2025-07-30 9:44 ` 答复: " 刘海燕 (Haiyan Liu)
2025-07-31 0:57 ` 刘海燕 (Haiyan Liu)
0 siblings, 2 replies; 16+ messages in thread
From: Ard Biesheuvel @ 2025-07-21 6:10 UTC (permalink / raw)
To: Mark Rutland
Cc: 刘海燕 (Haiyan Liu),
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
rust-for-linux@vger.kernel.org,
代子为 (Ziwei Dai),
周平 (Ping Zhou/9032),
杨丽娜 (Lina Yang),
王双 (Shuang Wang), Alice Ryhl, Miguel Ojeda,
Matthew Maurer, Sami Tolvanen
On Thu, 17 Jul 2025 at 20:39, Mark Rutland <mark.rutland@arm.com> wrote:
>
> Hi,
>
> From a quick scan, I think this might have something to do with
> UNWIND_PATCH_PAC_INTO_SCS, notes below.
>
> On Mon, Jul 14, 2025 at 03:12:33AM +0000, 刘海燕 (Haiyan Liu) wrote:
> > I am enabling generic kasan feature in kernel 6.12, and met kernel boot crash.
> > Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
> > pc : do_basic_setup+0x6c/0xac
> > lr : do_basic_setup+0x88/0xac
> > sp : ffffffc080087e40
>
> Can you say which hardware this is on? Given this is a NULL-dereference,
> this looks ike a dodgy pointer (or memory corruption) rather than a PAC
> failure.
>
> > After debug, I find some error in do_ctors().
> > Normally, the complier should insert the paciasp instruction at the function entry so that its corresponding autiasp instruction is used to validate the return address when the function returns.
> > NSX:FFFFFFC0800A840C|F800865E asan.module_ctor: str x30,[x18],#0x8；x30,[x18],#8
> > NSX:FFFFFFC0800A8410|A9BF7BFD stp x29,x30,[sp,#-0x10]! ; x29,x30,[sp,#-16]!
> > NSX:FFFFFFC0800A8414|910003FD mov x29,sp
> > NSX:FFFFFFC0800A8418|B0023420 adrp x0,0xFFFFFFC08472D000
> > NSX:FFFFFFC0800A841C|91390000 add x0,x0,#0xE40 ; x0,x0,#3648
> > NSX:FFFFFFC0800A8420|528000A1 mov w1,#0x5 ; w1,#5
> > NSX:FFFFFFC0800A8424|9422AF50 bl 0xFFFFFFC080954164 ; __asan_register_globals
> > NSX:FFFFFFC0800A8428|A8C17BFD ldp x29,x30,[sp],#0x10 ; x29,x30,[sp],#16
> > NSX:FFFFFFC0800A842C|F85F8E5E ldr x30,[x18,#-0x8]! ; x30,[x18,#-8]!
> > NSX:FFFFFFC0800A8430|D65F03C0 ret
>
> Here you evidently have shadow call stack enabled...
>
> > NSX:FFFFFFC0800A8478|D503233F asan.module_ctor: paciasp
> > NSX:FFFFFFC0800A847C|A9BF7BFD stp x29,x30,[sp,#-0x10]! ; x29,x30,[sp,#-16]!
> > NSX:FFFFFFC0800A8480|910003FD mov x29,sp
> > NSX:FFFFFFC0800A8484|B0023420 adrp x0,0xFFFFFFC08472D000
> > NSX:FFFFFFC0800A8488|913E0000 add x0,x0,#0xF80 ; x0,x0,#3968
> > NSX:FFFFFFC0800A848C|52800021 mov w1,#0x1 ; w1,#1
> > NSX:FFFFFFC0800A8490|9422AF35 bl 0xFFFFFFC080954164 ; __asan_register_globals
> > NSX:FFFFFFC0800A8494|A8C17BFD ldp x29,x30,[sp],#0x10 ; x29,x30,[sp],#16
> > NSX:FFFFFFC0800A8498|D50323BF autiasp
> > NSX:FFFFFFC0800A849C|D65F03C0 ret
>
> ... but here you evidently don't, and have PAC instead.
>
> Are these from the same kernel Image?
>
> Are these decoded from the static kernel binary, or are these dumps from
> memory once a kernel has booted (or is in the process of booting)?
>
> > But actually, in two asan.module_ctor functions, there is only autiasp instruction inserted before return, for validation of return address, while paciasp instruction is missing before.
> > NSX:FFFFFFC0800A72D8|F800865E asan.module_ctor: str x30,[x18],#0x8 ; x30,[x18],#8
> > NSX:FFFFFFC0800A72DC|F81F0FFE str x30,[sp,#-0x10]! ; x30,[sp,#-16]!
> > NSX:FFFFFFC0800A72E0|B00233C0 adrp x0,0xFFFFFFC084720000
> > NSX:FFFFFFC0800A72E4|91350000 add x0,x0,#0xD40 ; x0,x0,#3392
> > NSX:FFFFFFC0800A72E8|52803D61 mov w1,#0x1EB ; w1,#491
> > NSX:FFFFFFC0800A72EC|9422B39E bl 0xFFFFFFC080954164 ; __asan_register_globals
> > NSX:FFFFFFC0800A72F0|F84107FE ldr x30,[sp],#0x10 ; x30,[sp],#16
> > NSX:FFFFFFC0800A72F4|D50323BF autiasp
> > NSX:FFFFFFC0800A72F8|D65F03C0 ret
>
> Thas has a mixture of SCS and PAC; there's a shadow call stack prologue
> but a PAC epilogue:
>
> str x30, [x18], #8 // SCS
> ...
> autiasp // PAC
>
> ... so I'll hazard a guess that these are dumps from memory, and you
> have UNWIND_PATCH_PAC_INTO_SCS selected. Assuming that is the case,
> either this dump has been made mid-patching, or the patching has gone
> wrong somehow and left the prologues/epilogues in an inconsistent state
> (and the NULL dereference could be a secondary effect of that).
>
> Ard, does that sound plausible to you?
>
Yes, that is definitely possible.
Since commit 54c968bec344 ("arm64: Apply dynamic shadow call stack
patching in two passes") we are more careful about patching a function
in its entirety or not at all if any of the DWARF metadata is
misunderstood (or invalid). However, if the DWARF metadata is
inaccurate, but does not trigger an error, the patching will happen
and an error such as this one is likely to occur as a result.
Note that PACIASP and AUTIASP do not necessarily occur in pairs, so it
is not generally feasible to validate the DWARF against the code,
especially at runtime. However, a function (or FDE frame) that has one
PACIASP should at least have one AUTIASP too.
> I can't see why that would depend on KBUILD_RUSTFLAGS, but maybe the
> DWARF generated by rustc has confused the patching code somehow, or the
> linker has aggregated that in a suprising way.
>
I would suspect the DWARF metadata in this case. There are valid cases
where the DW_CFA_negate_ra_state annotation is attached to an
instruction other than PACIASP or AUTIASP, and so we are not able to
detect the case where the annotation is misplaced (i.e., attached to
the preceding or subsequent instruction).
So the important thing to check here is whether the objects in
question have the correct DWARF annotations for these
asan.module_ctor() routines. This can be done using 'llvm-readelf
--unwind' (example below, using an arbitrary object from a defconfig
build with kasan, rust and dynamic shadow call stack enabled): in this
case, both routines are correctly annotated, i.e., that the return
address (RA) state toggles to signed at offset 0x4 and toggles back to
unsigned/authenticated at 0x24.
$ llvm-objdump -d kernel/seccomp.o
Disassembly of section .text.asan.module_ctor:
0000000000000000 <asan.module_ctor>:
0: d503233f paciasp
4: a9bf7bfd stp x29, x30, [sp, #-0x10]!
8: 910003fd mov x29, sp
c: 90000000 adrp x0, 0x0 <asan.module_ctor>
10: 91000000 add x0, x0, #0x0
14: 528003c1 mov w1, #0x1e // =30
18: 94000000 bl 0x18 <asan.module_ctor+0x18>
1c: a8c17bfd ldp x29, x30, [sp], #0x10
20: d50323bf autiasp
24: d65f03c0 ret
Disassembly of section .text.asan.module_dtor:
0000000000000000 <asan.module_dtor>:
0: d503233f paciasp
4: a9bf7bfd stp x29, x30, [sp, #-0x10]!
8: 910003fd mov x29, sp
c: 90000000 adrp x0, 0x0 <asan.module_dtor>
10: 91000000 add x0, x0, #0x0
14: 528003c1 mov w1, #0x1e // =30
18: 94000000 bl 0x18 <asan.module_dtor+0x18>
1c: a8c17bfd ldp x29, x30, [sp], #0x10
20: d50323bf autiasp
24: d65f03c0 ret
$ llvm-readelf -u kernel/seccomp.o
(this requires a bit of manual inspection, given that readelf does not
take the .rela.eh_frame section into account, and so the initial
locations are section relative, and you're looking for FDE frames that
have initial location 0x0)
...
[0x58c] FDE length=40 cie=[0x0]
initial_location: 0x0
address_range: 0x28 (end : 0x28)
Program:
DW_CFA_advance_loc: 4 to 0x4
DW_CFA_AARCH64_negate_ra_state:
DW_CFA_advance_loc: 4 to 0x8
DW_CFA_def_cfa_offset: +16
DW_CFA_advance_loc: 4 to 0xc
DW_CFA_def_cfa: reg29 +16
DW_CFA_offset: reg30 -8
DW_CFA_offset: reg29 -16
DW_CFA_advance_loc: 16 to 0x1c
DW_CFA_def_cfa: reg31 +16
DW_CFA_advance_loc: 4 to 0x20
DW_CFA_def_cfa_offset: +0
DW_CFA_advance_loc: 4 to 0x24
DW_CFA_AARCH64_negate_ra_state:
DW_CFA_restore: reg30
DW_CFA_restore: reg29
DW_CFA_nop:
DW_CFA_nop:
DW_CFA_nop:
[0x5b8] FDE length=44 cie=[0x0]
initial_location: 0x0
address_range: 0x28 (end : 0x28)
Program:
DW_CFA_advance_loc: 4 to 0x4
DW_CFA_AARCH64_negate_ra_state:
DW_CFA_advance_loc: 4 to 0x8
DW_CFA_def_cfa_offset: +16
DW_CFA_advance_loc: 4 to 0xc
DW_CFA_def_cfa: reg29 +16
DW_CFA_offset: reg30 -8
DW_CFA_offset: reg29 -16
DW_CFA_advance_loc: 16 to 0x1c
DW_CFA_def_cfa: reg31 +16
DW_CFA_advance_loc: 4 to 0x20
DW_CFA_def_cfa_offset: +0
DW_CFA_advance_loc: 4 to 0x24
DW_CFA_AARCH64_negate_ra_state:
DW_CFA_restore: reg30
DW_CFA_restore: reg29
DW_CFA_nop:
DW_CFA_nop:
DW_CFA_nop:
DW_CFA_nop:
DW_CFA_nop:
DW_CFA_nop:
DW_CFA_nop:
^ permalink raw reply [flat|nested] 16+ messages in thread
* 答复: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS on
2025-07-21 6:10 ` Ard Biesheuvel
@ 2025-07-30 9:44 ` 刘海燕 (Haiyan Liu)
2025-07-31 0:57 ` 刘海燕 (Haiyan Liu)
1 sibling, 0 replies; 16+ messages in thread
From: 刘海燕 (Haiyan Liu) @ 2025-07-30 9:44 UTC (permalink / raw)
To: Ard Biesheuvel, Mark Rutland
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
rust-for-linux@vger.kernel.org,
代子为 (Ziwei Dai),
周平 (Ping Zhou/9032),
杨丽娜 (Lina Yang),
王双 (Shuang Wang), Alice Ryhl, Miguel Ojeda,
Matthew Maurer, Sami Tolvanen
> -----邮件原件-----
> 发件人: Ard Biesheuvel <ardb@kernel.org>
> 发送时间: 2025年7月21日 14:10
> 收件人: Mark Rutland <mark.rutland@arm.com>
> 抄送: 刘海燕 (Haiyan Liu) <haiyan.liu@unisoc.com>; linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> rust-for-linux@vger.kernel.org; 代子为 (Ziwei Dai) <Ziwei.Dai@unisoc.com>; 周平 (Ping Zhou/9032) <Ping.Zhou1@unisoc.com>; 杨丽
> 娜 (Lina Yang) <lina.yang@unisoc.com>; 王双 (Shuang Wang) <shuang.wang@unisoc.com>; Alice Ryhl <aliceryhl@google.com>; Miguel
> Ojeda <ojeda@kernel.org>; Matthew Maurer <mmaurer@google.com>; Sami Tolvanen <samitolvanen@google.com>
> 主题: Re: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS
> on
>
>
> 注意: 这封邮件来自于外部。除非你确定邮件内容安全，否则不要点击任何链接和附件。
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender
> and know the content is safe.
>
>
>
> On Thu, 17 Jul 2025 at 20:39, Mark Rutland <mark.rutland@arm.com> wrote:
> >
> > Hi,
> >
> > From a quick scan, I think this might have something to do with
> > UNWIND_PATCH_PAC_INTO_SCS, notes below.
> >
> > On Mon, Jul 14, 2025 at 03:12:33AM +0000, 刘海燕 (Haiyan Liu) wrote:
> > > I am enabling generic kasan feature in kernel 6.12, and met kernel boot crash.
> > > Unable to handle kernel NULL pointer dereference at virtual address
> > > 0000000000000008 pc : do_basic_setup+0x6c/0xac lr :
> > > do_basic_setup+0x88/0xac sp : ffffffc080087e40
> >
> > Can you say which hardware this is on? Given this is a
> > NULL-dereference, this looks ike a dodgy pointer (or memory
> > corruption) rather than a PAC failure.
> >
> > > After debug, I find some error in do_ctors().
> > > Normally, the complier should insert the paciasp instruction at the function entry so that its corresponding autiasp instruction is used to
> validate the return address when the function returns.
> > > NSX:FFFFFFC0800A840C|F800865E asan.module_ctor: str x30,[x18],#0x8；x30,[x18],#8
> > > NSX:FFFFFFC0800A8410|A9BF7BFD stp x29,x30,[sp,#-0x10]! ; x29,x30,[sp,#-16]!
> > > NSX:FFFFFFC0800A8414|910003FD mov x29,sp
> > > NSX:FFFFFFC0800A8418|B0023420 adrp x0,0xFFFFFFC08472D000
> > > NSX:FFFFFFC0800A841C|91390000 add x0,x0,#0xE40 ; x0,x0,#3648
> > > NSX:FFFFFFC0800A8420|528000A1 mov w1,#0x5 ; w1,#5
> > > NSX:FFFFFFC0800A8424|9422AF50 bl 0xFFFFFFC080954164 ; __asan_register_globals
> > > NSX:FFFFFFC0800A8428|A8C17BFD ldp x29,x30,[sp],#0x10 ; x29,x30,[sp],#16
> > > NSX:FFFFFFC0800A842C|F85F8E5E ldr x30,[x18,#-0x8]! ; x30,[x18,#-8]!
> > > NSX:FFFFFFC0800A8430|D65F03C0 ret
> >
> > Here you evidently have shadow call stack enabled...
> >
> > > NSX:FFFFFFC0800A8478|D503233F asan.module_ctor: paciasp
> > > NSX:FFFFFFC0800A847C|A9BF7BFD stp x29,x30,[sp,#-0x10]! ; x29,x30,[sp,#-16]!
> > > NSX:FFFFFFC0800A8480|910003FD mov x29,sp
> > > NSX:FFFFFFC0800A8484|B0023420 adrp x0,0xFFFFFFC08472D000
> > > NSX:FFFFFFC0800A8488|913E0000 add x0,x0,#0xF80 ; x0,x0,#3968
> > > NSX:FFFFFFC0800A848C|52800021 mov w1,#0x1 ; w1,#1
> > > NSX:FFFFFFC0800A8490|9422AF35 bl 0xFFFFFFC080954164 ; __asan_register_globals
> > > NSX:FFFFFFC0800A8494|A8C17BFD ldp x29,x30,[sp],#0x10 ; x29,x30,[sp],#16
> > > NSX:FFFFFFC0800A8498|D50323BF autiasp
> > > NSX:FFFFFFC0800A849C|D65F03C0 ret
> >
> > ... but here you evidently don't, and have PAC instead.
> >
> > Are these from the same kernel Image?
> >
> > Are these decoded from the static kernel binary, or are these dumps
> > from memory once a kernel has booted (or is in the process of booting)?
> >
> > > But actually, in two asan.module_ctor functions, there is only autiasp instruction inserted before return, for validation of return
> address, while paciasp instruction is missing before.
> > > NSX:FFFFFFC0800A72D8|F800865E asan.module_ctor: str x30,[x18],#0x8 ; x30,[x18],#8
> > > NSX:FFFFFFC0800A72DC|F81F0FFE str x30,[sp,#-0x10]! ; x30,[sp,#-16]!
> > > NSX:FFFFFFC0800A72E0|B00233C0 adrp x0,0xFFFFFFC084720000
> > > NSX:FFFFFFC0800A72E4|91350000 add x0,x0,#0xD40 ; x0,x0,#3392
> > > NSX:FFFFFFC0800A72E8|52803D61 mov w1,#0x1EB ; w1,#491
> > > NSX:FFFFFFC0800A72EC|9422B39E bl 0xFFFFFFC080954164 ; __asan_register_globals
> > > NSX:FFFFFFC0800A72F0|F84107FE ldr x30,[sp],#0x10 ; x30,[sp],#16
> > > NSX:FFFFFFC0800A72F4|D50323BF autiasp
> > > NSX:FFFFFFC0800A72F8|D65F03C0 ret
> >
> > Thas has a mixture of SCS and PAC; there's a shadow call stack
> > prologue but a PAC epilogue:
> >
> > str x30, [x18], #8 // SCS
> > ...
> > autiasp // PAC
> >
> > ... so I'll hazard a guess that these are dumps from memory, and you
> > have UNWIND_PATCH_PAC_INTO_SCS selected. Assuming that is the case,
> > either this dump has been made mid-patching, or the patching has gone
> > wrong somehow and left the prologues/epilogues in an inconsistent
> > state (and the NULL dereference could be a secondary effect of that).
> >
> > Ard, does that sound plausible to you?
> >
>
> Yes, that is definitely possible.
>
> Since commit 54c968bec344 ("arm64: Apply dynamic shadow call stack patching in two passes") we are more careful about patching a
> function in its entirety or not at all if any of the DWARF metadata is misunderstood (or invalid). However, if the DWARF metadata is
> inaccurate, but does not trigger an error, the patching will happen and an error such as this one is likely to occur as a result.
>
> Note that PACIASP and AUTIASP do not necessarily occur in pairs, so it is not generally feasible to validate the DWARF against the code,
> especially at runtime. However, a function (or FDE frame) that has one PACIASP should at least have one AUTIASP too.
>
> > I can't see why that would depend on KBUILD_RUSTFLAGS, but maybe the
> > DWARF generated by rustc has confused the patching code somehow, or
> > the linker has aggregated that in a suprising way.
> >
>
> I would suspect the DWARF metadata in this case. There are valid cases where the DW_CFA_negate_ra_state annotation is attached to an
> instruction other than PACIASP or AUTIASP, and so we are not able to detect the case where the annotation is misplaced (i.e., attached to
> the preceding or subsequent instruction).
>
> So the important thing to check here is whether the objects in question have the correct DWARF annotations for these
> asan.module_ctor() routines. This can be done using 'llvm-readelf --unwind' (example below, using an arbitrary object from a defconfig
> build with kasan, rust and dynamic shadow call stack enabled): in this case, both routines are correctly annotated, i.e., that the return
> address (RA) state toggles to signed at offset 0x4 and toggles back to unsigned/authenticated at 0x24.
>
>
>
>
> $ llvm-objdump -d kernel/seccomp.o
>
> Disassembly of section .text.asan.module_ctor:
>
> 0000000000000000 <asan.module_ctor>:
> 0: d503233f paciasp
> 4: a9bf7bfd stp x29, x30, [sp, #-0x10]!
> 8: 910003fd mov x29, sp
> c: 90000000 adrp x0, 0x0 <asan.module_ctor>
> 10: 91000000 add x0, x0, #0x0
> 14: 528003c1 mov w1, #0x1e // =30
> 18: 94000000 bl 0x18 <asan.module_ctor+0x18>
> 1c: a8c17bfd ldp x29, x30, [sp], #0x10
> 20: d50323bf autiasp
> 24: d65f03c0 ret
>
> Disassembly of section .text.asan.module_dtor:
>
> 0000000000000000 <asan.module_dtor>:
> 0: d503233f paciasp
> 4: a9bf7bfd stp x29, x30, [sp, #-0x10]!
> 8: 910003fd mov x29, sp
> c: 90000000 adrp x0, 0x0 <asan.module_dtor>
> 10: 91000000 add x0, x0, #0x0
> 14: 528003c1 mov w1, #0x1e // =30
> 18: 94000000 bl 0x18 <asan.module_dtor+0x18>
> 1c: a8c17bfd ldp x29, x30, [sp], #0x10
> 20: d50323bf autiasp
> 24: d65f03c0 ret
>
>
> $ llvm-readelf -u kernel/seccomp.o
>
> (this requires a bit of manual inspection, given that readelf does not take the .rela.eh_frame section into account, and so the initial
> locations are section relative, and you're looking for FDE frames that have initial location 0x0)
>
> ...
> [0x58c] FDE length=40 cie=[0x0]
> initial_location: 0x0
> address_range: 0x28 (end : 0x28)
>
> Program:
> DW_CFA_advance_loc: 4 to 0x4
> DW_CFA_AARCH64_negate_ra_state:
> DW_CFA_advance_loc: 4 to 0x8
> DW_CFA_def_cfa_offset: +16
> DW_CFA_advance_loc: 4 to 0xc
> DW_CFA_def_cfa: reg29 +16
> DW_CFA_offset: reg30 -8
> DW_CFA_offset: reg29 -16
> DW_CFA_advance_loc: 16 to 0x1c
> DW_CFA_def_cfa: reg31 +16
> DW_CFA_advance_loc: 4 to 0x20
> DW_CFA_def_cfa_offset: +0
> DW_CFA_advance_loc: 4 to 0x24
> DW_CFA_AARCH64_negate_ra_state:
> DW_CFA_restore: reg30
> DW_CFA_restore: reg29
> DW_CFA_nop:
> DW_CFA_nop:
> DW_CFA_nop:
>
> [0x5b8] FDE length=44 cie=[0x0]
> initial_location: 0x0
> address_range: 0x28 (end : 0x28)
>
> Program:
> DW_CFA_advance_loc: 4 to 0x4
> DW_CFA_AARCH64_negate_ra_state:
> DW_CFA_advance_loc: 4 to 0x8
> DW_CFA_def_cfa_offset: +16
> DW_CFA_advance_loc: 4 to 0xc
> DW_CFA_def_cfa: reg29 +16
> DW_CFA_offset: reg30 -8
> DW_CFA_offset: reg29 -16
> DW_CFA_advance_loc: 16 to 0x1c
> DW_CFA_def_cfa: reg31 +16
> DW_CFA_advance_loc: 4 to 0x20
> DW_CFA_def_cfa_offset: +0
> DW_CFA_advance_loc: 4 to 0x24
> DW_CFA_AARCH64_negate_ra_state:
> DW_CFA_restore: reg30
> DW_CFA_restore: reg29
> DW_CFA_nop:
> DW_CFA_nop:
> DW_CFA_nop:
> DW_CFA_nop:
> DW_CFA_nop:
> DW_CFA_nop:
> DW_CFA_nop:
I find two question :
1. too many __unnamed global value in system.map, such as :
ffffffc082e63ba0 d _RNvNtNtNtCs3o2tGsuHyou_4core7unicode12unicode_data5cased17SHORT_OFFSET_RUNS
ffffffc082e63c20 d _RNvNtNtNtCs3o2tGsuHyou_4core7unicode12unicode_data5cased7OFFSETS
ffffffc082e63da0 d _RNvNtNtNtCs3o2tGsuHyou_4core7unicode12unicode_data15grapheme_extend17SHORT_OFFSET_RUNS
ffffffc082e63e60 d _RNvNtNtNtCs3o2tGsuHyou_4core7unicode12unicode_data15grapheme_extend7OFFSETS
ffffffc082e641e0 d __unnamed_340
ffffffc082e64280 d __unnamed_341
ffffffc082e64400 d __unnamed_342u
ffffffc082e64620 d __unnamed_343
ffffffc082e64680 d _RNvNtNtNtCs3o2tGsuHyou_4core7unicode12unicode_data1n17SHORT_OFFSET_RUNS
ffffffc082e64740 d _RNvNtNtNtCs3o2tGsuHyou_4core7unicode12unicode_data1n7OFFSETS
and I found the global values defined in '1.82.0/lib/rustlib/src/rust/library/core/src/unicode/Unicode_data.rs':
#[rustfmt::skip]
pub mod lowercase {
const BITSET_CHUNKS_MAP: &'static [u8; 123] = &[
14, 17, 0, 0, 9, 0, 0, 12, 13, 10, 0, 16, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 6, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 4, 1, 0, 15, 0, 8, 0, 0, 11, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 5, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 19, 0,
3, 18, 0, 7,
];
const BITSET_INDEX_CHUNKS: &'static [[u8; 16]; 20] = &[
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 59, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 16, 14, 55, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 40, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 44, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0, 9, 0, 0, 0, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0, 65, 43, 0, 51, 47, 49, 33],
[0, 0, 0, 0, 10, 56, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[0, 0, 0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[0, 0, 0, 19, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 27],
[0, 0, 0, 60, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[0, 0, 0, 69, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[0, 0, 57, 0, 55, 55, 55, 0, 22, 22, 67, 22, 36, 25, 24, 37],
[0, 5, 68, 0, 29, 15, 73, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[0, 64, 34, 17, 23, 52, 53, 48, 46, 8, 35, 42, 0, 28, 13, 31],
[11, 58, 0, 6, 0, 0, 30, 0, 0, 0, 0, 0, 0, 0, 32, 0],
[16, 26, 22, 38, 39, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[16, 50, 2, 21, 66, 9, 57, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[16, 70, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[63, 41, 54, 12, 75, 61, 18, 1, 7, 62, 74, 20, 71, 72, 4, 45],
];
const BITSET_CANONICAL: &'static [u64; 55] = &[
0b0000000000000000000000000000000000000000000000000000000000000000,
0b1111111111111111110000000000000000000000000011111111111111111111,
0b1010101010101010101010101010101010101010101010101010100000000010,
0b0000000000000111111111111111111111111111111111111111111111111111,
0b1111111111111111111111000000000000000000000000001111110111111111,
0b1000000000000010000000000000000000000000000000000000000000000000,
0b0000111111111111111111111111111111111111000000000000000000000000,
0b0000111111111111111111111111110000000000000000000000000011111111,
0b1111111111111111111111111111111111111111111111111010101010000101,
0b1111111111111111111111111111111100000000000000000000000000000000,
0b1111111111111111111111111111110000000000000000000000000000000000,
0b1111111111111111111111110000000000000000000000000000000000000000,
0b1111111111111111111111000000000000000000000000001111111111101111,
0b1111111111111111111100000000000000000000000000010000000000000000,
0b1111111111111111000000111111111111110111111111111111111111111111,
0b1111111111111111000000000000000000000000000000000100001111000000,
0b1111111111111111000000000000000000000000000000000000000000000000,
0b1111111101111111111111111111111110000000000000000000000000000000,
0b1111110000000000000000000000000011111111111111111111111111000000,
0b1111011111111111111111111111111111111111111111110000000000000000,
0b1111000000000000000000000000001111110111111111111111111111111100,
0b1010101010101010101010101010101010101010101010101101010101010100,
0b1010101010101010101010101010101010101010101010101010101010101010,
0b0101010110101010101010101010101010101010101010101010101010101010,
0b0100000011011111000000001111111100000000111111110000000011111111,
0b0011111111111111000000001111111100000000111111110000000000111111,
0b0011111111011010000101010110001011111111111111111111111111111111,
0b0011111100000000000000000000000000000000000000000000000000000000,
0b0011110010001010000000000000000000000000000000000000000000100000,
0b0011001000010000100000000000000000000000000010001100010000000000,
0b0001101111111011111111111111101111111111100000000000000000000000,
0b0001100100101111101010101010101010101010111000110111111111111111,
0b0000011111111101111111111111111111111111111111111111111110111001,
0b0000011101011100000000000000000000000010101010100000010100001010,
0b0000010000100000000001000000000000000000000000000000000000000000,
0b0000000111111111111111111111111111111111111011111111111111111111,
0b0000000011111111000000001111111100000000001111110000000011111111,
0b0000000011011100000000001111111100000000110011110000000011011100,
0b0000000000001000010100000001101010101010101010101010101010101010,
0b0000000000000000001000001011111111111111111111111111111111111111,
0b0000000000000000000001111110000001111111111111111111101111111111,
0b0000000000000000000000001111111111111111110111111100000000000000,
0b0000000000000000000000000001111100000000000000000000000000000011,
0b0000000000000000000000000000000000111010101010101010101010101010,
0b0000000000000000000000000000000000000000111110000000000001111111,
0b0000000000000000000000000000000000000000000000000000101111110111,
0b1001001111111010101010101010101010101010101010101010101010101010,
0b1001010111111111101010101010101010101010101010101010101010101010,
0b1010101000101001101010101010101010110101010101010101001001000000,
0b1010101010100000100000101010101010101010101110100101000010101010,
0b1010101010101010101010101010101011111111111111111111111111111111,
0b1010101010101011101010101010100000000000000000000000000000000000,
0b1101010010101010101010101010101010101010101010101010101101010101,
0b1110011001010001001011010010101001001110001001000011000100101001,
0b1110101111000000000000000000000000001111111111111111111111111100,
];
const BITSET_MAPPING: &'static [(u8, u8); 21] = &[
(0, 64), (1, 188), (1, 183), (1, 176), (1, 109), (1, 124), (1, 126), (1, 66), (1, 70),
(1, 77), (2, 146), (2, 144), (2, 83), (3, 93), (3, 147), (3, 133), (4, 12), (4, 6),
(5, 187), (6, 78), (7, 132),
];
#[rustc_const_unstable(feature = "const_unicode_case_lookup", issue = "101400")]
pub const fn lookup(c: char) -> bool {
super::bitset_search(
c as u32,
&BITSET_CHUNKS_MAP,
&BITSET_INDEX_CHUNKS,
&BITSET_CANONICAL,
&BITSET_MAPPING,
)
}
}
I want to know the rust value becomed unnamed after compilation is valid or not.
2.I find the wrong global value ffffffc08483e560 d __unnamed_356:
llvm-objdump disassemble:
Disassembly of section .text.asan.module_ctor:
0000000000000000 <.text.asan.module_ctor>:
0: 60 7d c4 e5 .word 0xe5c47d60
0000000000000004 <asan.module_ctor>:
4: d503233f paciasp
8: f81f0ffe str x30, [sp, #-0x10]!
c: 90000000 adrp x0, 0x0 <.text.asan.module_ctor>
10: 91000000 add x0, x0, #0x0
14: 52803d61 mov w1, #0x1eb // =491
18: 94000000 bl 0x18 <asan.module_ctor+0x14>
1c: f84107fe ldr x30, [sp], #0x10
20: d50323bf autiasp
24: d65f03c0 ret
But when the software running, I dump the disassemble using the TRACE32 is：
______________addr/line|code_____|label____|mnemonic________________|comment
NSX:FFFFFFC0800A7C40|F800865E asan.mod.:str x30,[x18],#0x8 ; x30,[x18],#8
NSX:FFFFFFC0800A7C44|F81F0FFE str x30,[sp,#-0x10]! ; x30,[sp,#-16]!
NSX:FFFFFFC0800A7C48|F00240A0 adrp x0,0xFFFFFFC0848BE000
NSX:FFFFFFC0800A7C4C|91158000 add x0,x0,#0x560 ; x0,x0,#1376
NSX:FFFFFFC0800A7C50|52803D61 mov w1,#0x1EB ; w1,#491
NSX:FFFFFFC0800A7C54|94233646 bl 0xFFFFFFC08097556C ; __asan_register_globals
NSX:FFFFFFC0800A7C58|F84107FE ldr x30,[sp],#0x10 ; x30,[sp],#16
___NSX:FFFFFFC0800A7C5C|D50323BF____________autiasp
NSX:FFFFFFC0800A7C60|D65F03C0 ret
And llvm-readdlf -u disassembly:
[0x14] FDE length=52 cie=[0x0]
initial_location: 0x4
address_range: 0x78 (end : 0x7c)
Program:
DW_CFA_advance_loc: 4 to 0x8
DW_CFA_AARCH64_negate_ra_state:
DW_CFA_advance_loc: 4 to 0xc
DW_CFA_def_cfa_offset: +48
DW_CFA_advance_loc: 12 to 0x18
DW_CFA_def_cfa: reg29 +48
DW_CFA_offset: reg19 -8
DW_CFA_offset: reg20 -16
DW_CFA_offset: reg21 -24
DW_CFA_offset: reg22 -32
DW_CFA_offset: reg30 -40
DW_CFA_offset: reg29 -48
DW_CFA_advance_loc1: 80 to 0x68
DW_CFA_def_cfa: reg31 +48
DW_CFA_advance_loc: 12 to 0x74
DW_CFA_def_cfa_offset: +0
DW_CFA_advance_loc: 4 to 0x78
DW_CFA_AARCH64_negate_ra_state:
DW_CFA_restore: reg19
DW_CFA_restore: reg20
DW_CFA_restore: reg21
DW_CFA_restore: reg22
DW_CFA_restore: reg30
DW_CFA_restore: reg29
DW_CFA_nop:
DW_CFA_nop:
I can't find something wrong in the disassemble.
3.I disable CONFIG_UNWIND_PATCH_PAC_INTO_SCS , I dump the disassemble using the TRACE32 as the same as the objdump disassemble. Can the config be disabled in 6.12?
Thank you.
^ permalink raw reply [flat|nested] 16+ messages in thread
* 答复: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS on
2025-07-21 6:10 ` Ard Biesheuvel
2025-07-30 9:44 ` 答复: " 刘海燕 (Haiyan Liu)
@ 2025-07-31 0:57 ` 刘海燕 (Haiyan Liu)
1 sibling, 0 replies; 16+ messages in thread
From: 刘海燕 (Haiyan Liu) @ 2025-07-31 0:57 UTC (permalink / raw)
To: Ard Biesheuvel, Mark Rutland
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
rust-for-linux@vger.kernel.org,
代子为 (Ziwei Dai),
周平 (Ping Zhou/9032),
杨丽娜 (Lina Yang),
王双 (Shuang Wang), Alice Ryhl, Miguel Ojeda,
Matthew Maurer, Sami Tolvanen
> -----邮件原件-----
> 发件人: 刘海燕 (Haiyan Liu)
> 发送时间: 2025年7月30日 17:45
> 收件人: 'Ard Biesheuvel' <ardb@kernel.org>; Mark Rutland <mark.rutland@arm.com>
> 抄送: linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; rust-for-linux@vger.kernel.org; 代子为 (Ziwei Dai)
> <Ziwei.Dai@unisoc.com>; 周平 (Ping Zhou/9032) <Ping.Zhou1@unisoc.com>; 杨丽娜 (Lina Yang) <Lina.Yang@unisoc.com>; 王双
> (Shuang Wang) <Shuang.Wang@unisoc.com>; Alice Ryhl <aliceryhl@google.com>; Miguel Ojeda <ojeda@kernel.org>; Matthew Maurer
> <mmaurer@google.com>; Sami Tolvanen <samitolvanen@google.com>
> 主题: 答复: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default
> KBUILD_RUSTFLAGS on
>
>
>
> > -----邮件原件-----
> > 发件人: Ard Biesheuvel <ardb@kernel.org>
> > 发送时间: 2025年7月21日 14:10
> > 收件人: Mark Rutland <mark.rutland@arm.com>
> > 抄送: 刘海燕 (Haiyan Liu) <haiyan.liu@unisoc.com>;
> > linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> > rust-for-linux@vger.kernel.org; 代子为 (Ziwei Dai)
> > <Ziwei.Dai@unisoc.com>; 周平 (Ping Zhou/9032) <Ping.Zhou1@unisoc.com>;
> > 杨丽
> > 娜 (Lina Yang) <lina.yang@unisoc.com>; 王双 (Shuang Wang)
> > <shuang.wang@unisoc.com>; Alice Ryhl <aliceryhl@google.com>; Miguel
> > Ojeda <ojeda@kernel.org>; Matthew Maurer <mmaurer@google.com>; Sami
> > Tolvanen <samitolvanen@google.com>
> > 主题: Re: Meet compiled kernel binaray abnormal issue while enabling
> > generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS on
> >
> >
> > 注意: 这封邮件来自于外部。除非你确定邮件内容安全，否则不要点击任何链接和附件。
> > CAUTION: This email originated from outside of the organization. Do
> > not click links or open attachments unless you recognize the sender and know the content is safe.
> >
> >
> >
> > On Thu, 17 Jul 2025 at 20:39, Mark Rutland <mark.rutland@arm.com> wrote:
> > >
> > > Hi,
> > >
> > > From a quick scan, I think this might have something to do with
> > > UNWIND_PATCH_PAC_INTO_SCS, notes below.
> > >
> > > On Mon, Jul 14, 2025 at 03:12:33AM +0000, 刘海燕 (Haiyan Liu) wrote:
> > > > I am enabling generic kasan feature in kernel 6.12, and met kernel boot crash.
> > > > Unable to handle kernel NULL pointer dereference at virtual
> > > > address
> > > > 0000000000000008 pc : do_basic_setup+0x6c/0xac lr :
> > > > do_basic_setup+0x88/0xac sp : ffffffc080087e40
> > >
> > > Can you say which hardware this is on? Given this is a
> > > NULL-dereference, this looks ike a dodgy pointer (or memory
> > > corruption) rather than a PAC failure.
> > >
> > > > After debug, I find some error in do_ctors().
> > > > Normally, the complier should insert the paciasp instruction at
> > > > the function entry so that its corresponding autiasp instruction
> > > > is used to
> > validate the return address when the function returns.
> > > > NSX:FFFFFFC0800A840C|F800865E asan.module_ctor: str x30,[x18],#0x8；x30,[x18],#8
> > > > NSX:FFFFFFC0800A8410|A9BF7BFD stp x29,x30,[sp,#-0x10]! ; x29,x30,[sp,#-16]!
> > > > NSX:FFFFFFC0800A8414|910003FD mov x29,sp
> > > > NSX:FFFFFFC0800A8418|B0023420 adrp x0,0xFFFFFFC08472D000
> > > > NSX:FFFFFFC0800A841C|91390000 add x0,x0,#0xE40 ; x0,x0,#3648
> > > > NSX:FFFFFFC0800A8420|528000A1 mov w1,#0x5 ; w1,#5
> > > > NSX:FFFFFFC0800A8424|9422AF50 bl 0xFFFFFFC080954164 ; __asan_register_globals
> > > > NSX:FFFFFFC0800A8428|A8C17BFD ldp x29,x30,[sp],#0x10 ; x29,x30,[sp],#16
> > > > NSX:FFFFFFC0800A842C|F85F8E5E ldr x30,[x18,#-0x8]! ; x30,[x18,#-8]!
> > > > NSX:FFFFFFC0800A8430|D65F03C0 ret
> > >
> > > Here you evidently have shadow call stack enabled...
> > >
> > > > NSX:FFFFFFC0800A8478|D503233F asan.module_ctor: paciasp
> > > > NSX:FFFFFFC0800A847C|A9BF7BFD stp x29,x30,[sp,#-0x10]! ; x29,x30,[sp,#-16]!
> > > > NSX:FFFFFFC0800A8480|910003FD mov x29,sp
> > > > NSX:FFFFFFC0800A8484|B0023420 adrp x0,0xFFFFFFC08472D000
> > > > NSX:FFFFFFC0800A8488|913E0000 add x0,x0,#0xF80 ; x0,x0,#3968
> > > > NSX:FFFFFFC0800A848C|52800021 mov w1,#0x1 ; w1,#1
> > > > NSX:FFFFFFC0800A8490|9422AF35 bl 0xFFFFFFC080954164 ; __asan_register_globals
> > > > NSX:FFFFFFC0800A8494|A8C17BFD ldp x29,x30,[sp],#0x10 ; x29,x30,[sp],#16
> > > > NSX:FFFFFFC0800A8498|D50323BF autiasp
> > > > NSX:FFFFFFC0800A849C|D65F03C0 ret
> > >
> > > ... but here you evidently don't, and have PAC instead.
> > >
> > > Are these from the same kernel Image?
> > >
> > > Are these decoded from the static kernel binary, or are these dumps
> > > from memory once a kernel has booted (or is in the process of booting)?
> > >
> > > > But actually, in two asan.module_ctor functions, there is only
> > > > autiasp instruction inserted before return, for validation of
> > > > return
> > address, while paciasp instruction is missing before.
> > > > NSX:FFFFFFC0800A72D8|F800865E asan.module_ctor: str x30,[x18],#0x8 ; x30,[x18],#8
> > > > NSX:FFFFFFC0800A72DC|F81F0FFE str x30,[sp,#-0x10]! ; x30,[sp,#-16]!
> > > > NSX:FFFFFFC0800A72E0|B00233C0 adrp x0,0xFFFFFFC084720000
> > > > NSX:FFFFFFC0800A72E4|91350000 add x0,x0,#0xD40 ; x0,x0,#3392
> > > > NSX:FFFFFFC0800A72E8|52803D61 mov w1,#0x1EB ; w1,#491
> > > > NSX:FFFFFFC0800A72EC|9422B39E bl 0xFFFFFFC080954164 ; __asan_register_globals
> > > > NSX:FFFFFFC0800A72F0|F84107FE ldr x30,[sp],#0x10 ; x30,[sp],#16
> > > > NSX:FFFFFFC0800A72F4|D50323BF autiasp
> > > > NSX:FFFFFFC0800A72F8|D65F03C0 ret
> > >
> > > Thas has a mixture of SCS and PAC; there's a shadow call stack
> > > prologue but a PAC epilogue:
> > >
> > > str x30, [x18], #8 // SCS
> > > ...
> > > autiasp // PAC
> > >
> > > ... so I'll hazard a guess that these are dumps from memory, and you
> > > have UNWIND_PATCH_PAC_INTO_SCS selected. Assuming that is the case,
> > > either this dump has been made mid-patching, or the patching has
> > > gone wrong somehow and left the prologues/epilogues in an
> > > inconsistent state (and the NULL dereference could be a secondary effect of that).
> > >
> > > Ard, does that sound plausible to you?
> > >
> >
> > Yes, that is definitely possible.
> >
> > Since commit 54c968bec344 ("arm64: Apply dynamic shadow call stack
> > patching in two passes") we are more careful about patching a function
> > in its entirety or not at all if any of the DWARF metadata is misunderstood (or invalid). However, if the DWARF metadata is inaccurate, but
> does not trigger an error, the patching will happen and an error such as this one is likely to occur as a result.
> >
> > Note that PACIASP and AUTIASP do not necessarily occur in pairs, so it
> > is not generally feasible to validate the DWARF against the code, especially at runtime. However, a function (or FDE frame) that has one
> PACIASP should at least have one AUTIASP too.
> >
> > > I can't see why that would depend on KBUILD_RUSTFLAGS, but maybe the
> > > DWARF generated by rustc has confused the patching code somehow, or
> > > the linker has aggregated that in a suprising way.
> > >
> >
> > I would suspect the DWARF metadata in this case. There are valid cases
> > where the DW_CFA_negate_ra_state annotation is attached to an
> > instruction other than PACIASP or AUTIASP, and so we are not able to detect the case where the annotation is misplaced (i.e., attached to
> the preceding or subsequent instruction).
> >
> > So the important thing to check here is whether the objects in
> > question have the correct DWARF annotations for these
> > asan.module_ctor() routines. This can be done using 'llvm-readelf
> > --unwind' (example below, using an arbitrary object from a defconfig
> > build with kasan, rust and dynamic shadow call stack enabled): in this case, both routines are correctly annotated, i.e., that the return
> address (RA) state toggles to signed at offset 0x4 and toggles back to unsigned/authenticated at 0x24.
> >
> >
> >
> >
> > $ llvm-objdump -d kernel/seccomp.o
> >
> > Disassembly of section .text.asan.module_ctor:
> >
> > 0000000000000000 <asan.module_ctor>:
> > 0: d503233f paciasp
> > 4: a9bf7bfd stp x29, x30, [sp, #-0x10]!
> > 8: 910003fd mov x29, sp
> > c: 90000000 adrp x0, 0x0 <asan.module_ctor>
> > 10: 91000000 add x0, x0, #0x0
> > 14: 528003c1 mov w1, #0x1e // =30
> > 18: 94000000 bl 0x18 <asan.module_ctor+0x18>
> > 1c: a8c17bfd ldp x29, x30, [sp], #0x10
> > 20: d50323bf autiasp
> > 24: d65f03c0 ret
> >
> > Disassembly of section .text.asan.module_dtor:
> >
> > 0000000000000000 <asan.module_dtor>:
> > 0: d503233f paciasp
> > 4: a9bf7bfd stp x29, x30, [sp, #-0x10]!
> > 8: 910003fd mov x29, sp
> > c: 90000000 adrp x0, 0x0 <asan.module_dtor>
> > 10: 91000000 add x0, x0, #0x0
> > 14: 528003c1 mov w1, #0x1e // =30
> > 18: 94000000 bl 0x18 <asan.module_dtor+0x18>
> > 1c: a8c17bfd ldp x29, x30, [sp], #0x10
> > 20: d50323bf autiasp
> > 24: d65f03c0 ret
> >
> >
> > $ llvm-readelf -u kernel/seccomp.o
> >
> > (this requires a bit of manual inspection, given that readelf does not
> > take the .rela.eh_frame section into account, and so the initial
> > locations are section relative, and you're looking for FDE frames that
> > have initial location 0x0)
> >
> > ...
> > [0x58c] FDE length=40 cie=[0x0]
> > initial_location: 0x0
> > address_range: 0x28 (end : 0x28)
> >
> > Program:
> > DW_CFA_advance_loc: 4 to 0x4
> > DW_CFA_AARCH64_negate_ra_state:
> > DW_CFA_advance_loc: 4 to 0x8
> > DW_CFA_def_cfa_offset: +16
> > DW_CFA_advance_loc: 4 to 0xc
> > DW_CFA_def_cfa: reg29 +16
> > DW_CFA_offset: reg30 -8
> > DW_CFA_offset: reg29 -16
> > DW_CFA_advance_loc: 16 to 0x1c
> > DW_CFA_def_cfa: reg31 +16
> > DW_CFA_advance_loc: 4 to 0x20
> > DW_CFA_def_cfa_offset: +0
> > DW_CFA_advance_loc: 4 to 0x24
> > DW_CFA_AARCH64_negate_ra_state:
> > DW_CFA_restore: reg30
> > DW_CFA_restore: reg29
> > DW_CFA_nop:
> > DW_CFA_nop:
> > DW_CFA_nop:
> >
> > [0x5b8] FDE length=44 cie=[0x0]
> > initial_location: 0x0
> > address_range: 0x28 (end : 0x28)
> >
> > Program:
> > DW_CFA_advance_loc: 4 to 0x4
> > DW_CFA_AARCH64_negate_ra_state:
> > DW_CFA_advance_loc: 4 to 0x8
> > DW_CFA_def_cfa_offset: +16
> > DW_CFA_advance_loc: 4 to 0xc
> > DW_CFA_def_cfa: reg29 +16
> > DW_CFA_offset: reg30 -8
> > DW_CFA_offset: reg29 -16
> > DW_CFA_advance_loc: 16 to 0x1c
> > DW_CFA_def_cfa: reg31 +16
> > DW_CFA_advance_loc: 4 to 0x20
> > DW_CFA_def_cfa_offset: +0
> > DW_CFA_advance_loc: 4 to 0x24
> > DW_CFA_AARCH64_negate_ra_state:
> > DW_CFA_restore: reg30
> > DW_CFA_restore: reg29
> > DW_CFA_nop:
> > DW_CFA_nop:
> > DW_CFA_nop:
> > DW_CFA_nop:
> > DW_CFA_nop:
> > DW_CFA_nop:
> > DW_CFA_nop:
>
> I find two question :
> 1. too many __unnamed global value in system.map, such as :
> ffffffc082e63ba0 d _RNvNtNtNtCs3o2tGsuHyou_4core7unicode12unicode_data5cased17SHORT_OFFSET_RUNS
> ffffffc082e63c20 d _RNvNtNtNtCs3o2tGsuHyou_4core7unicode12unicode_data5cased7OFFSETS
> ffffffc082e63da0 d _RNvNtNtNtCs3o2tGsuHyou_4core7unicode12unicode_data15grapheme_extend17SHORT_OFFSET_RUNS
> ffffffc082e63e60 d _RNvNtNtNtCs3o2tGsuHyou_4core7unicode12unicode_data15grapheme_extend7OFFSETS
> ffffffc082e641e0 d __unnamed_340
> ffffffc082e64280 d __unnamed_341
> ffffffc082e64400 d __unnamed_342u
> ffffffc082e64620 d __unnamed_343
> ffffffc082e64680 d _RNvNtNtNtCs3o2tGsuHyou_4core7unicode12unicode_data1n17SHORT_OFFSET_RUNS
> ffffffc082e64740 d _RNvNtNtNtCs3o2tGsuHyou_4core7unicode12unicode_data1n7OFFSETS
>
> and I found the global values defined in '1.82.0/lib/rustlib/src/rust/library/core/src/unicode/Unicode_data.rs':
> #[rustfmt::skip]
> pub mod lowercase {
> const BITSET_CHUNKS_MAP: &'static [u8; 123] = &[
> 14, 17, 0, 0, 9, 0, 0, 12, 13, 10, 0, 16, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 6, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 4, 1, 0, 15, 0, 8, 0, 0, 11, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 5, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 19, 0,
> 3, 18, 0, 7,
> ];
> const BITSET_INDEX_CHUNKS: &'static [[u8; 16]; 20] = &[
> [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
> [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 59, 0, 0],
> [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 16, 14, 55, 0],
> [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 40, 0, 0, 0],
> [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 44, 0, 0, 0],
> [0, 0, 0, 0, 0, 0, 0, 0, 0, 9, 0, 0, 0, 0, 0, 0],
> [0, 0, 0, 0, 0, 0, 0, 0, 0, 65, 43, 0, 51, 47, 49, 33],
> [0, 0, 0, 0, 10, 56, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
> [0, 0, 0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
> [0, 0, 0, 19, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 27],
> [0, 0, 0, 60, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
> [0, 0, 0, 69, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
> [0, 0, 57, 0, 55, 55, 55, 0, 22, 22, 67, 22, 36, 25, 24, 37],
> [0, 5, 68, 0, 29, 15, 73, 0, 0, 0, 0, 0, 0, 0, 0, 0],
> [0, 64, 34, 17, 23, 52, 53, 48, 46, 8, 35, 42, 0, 28, 13, 31],
> [11, 58, 0, 6, 0, 0, 30, 0, 0, 0, 0, 0, 0, 0, 32, 0],
> [16, 26, 22, 38, 39, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
> [16, 50, 2, 21, 66, 9, 57, 0, 0, 0, 0, 0, 0, 0, 0, 0],
> [16, 70, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
> [63, 41, 54, 12, 75, 61, 18, 1, 7, 62, 74, 20, 71, 72, 4, 45],
> ];
> const BITSET_CANONICAL: &'static [u64; 55] = &[
> 0b0000000000000000000000000000000000000000000000000000000000000000,
> 0b1111111111111111110000000000000000000000000011111111111111111111,
> 0b1010101010101010101010101010101010101010101010101010100000000010,
> 0b0000000000000111111111111111111111111111111111111111111111111111,
> 0b1111111111111111111111000000000000000000000000001111110111111111,
> 0b1000000000000010000000000000000000000000000000000000000000000000,
> 0b0000111111111111111111111111111111111111000000000000000000000000,
> 0b0000111111111111111111111111110000000000000000000000000011111111,
> 0b1111111111111111111111111111111111111111111111111010101010000101,
> 0b1111111111111111111111111111111100000000000000000000000000000000,
> 0b1111111111111111111111111111110000000000000000000000000000000000,
> 0b1111111111111111111111110000000000000000000000000000000000000000,
> 0b1111111111111111111111000000000000000000000000001111111111101111,
> 0b1111111111111111111100000000000000000000000000010000000000000000,
> 0b1111111111111111000000111111111111110111111111111111111111111111,
> 0b1111111111111111000000000000000000000000000000000100001111000000,
> 0b1111111111111111000000000000000000000000000000000000000000000000,
> 0b1111111101111111111111111111111110000000000000000000000000000000,
> 0b1111110000000000000000000000000011111111111111111111111111000000,
> 0b1111011111111111111111111111111111111111111111110000000000000000,
> 0b1111000000000000000000000000001111110111111111111111111111111100,
> 0b1010101010101010101010101010101010101010101010101101010101010100,
> 0b1010101010101010101010101010101010101010101010101010101010101010,
> 0b0101010110101010101010101010101010101010101010101010101010101010,
> 0b0100000011011111000000001111111100000000111111110000000011111111,
> 0b0011111111111111000000001111111100000000111111110000000000111111,
> 0b0011111111011010000101010110001011111111111111111111111111111111,
> 0b0011111100000000000000000000000000000000000000000000000000000000,
> 0b0011110010001010000000000000000000000000000000000000000000100000,
> 0b0011001000010000100000000000000000000000000010001100010000000000,
> 0b0001101111111011111111111111101111111111100000000000000000000000,
> 0b0001100100101111101010101010101010101010111000110111111111111111,
> 0b0000011111111101111111111111111111111111111111111111111110111001,
> 0b0000011101011100000000000000000000000010101010100000010100001010,
> 0b0000010000100000000001000000000000000000000000000000000000000000,
> 0b0000000111111111111111111111111111111111111011111111111111111111,
> 0b0000000011111111000000001111111100000000001111110000000011111111,
> 0b0000000011011100000000001111111100000000110011110000000011011100,
> 0b0000000000001000010100000001101010101010101010101010101010101010,
> 0b0000000000000000001000001011111111111111111111111111111111111111,
> 0b0000000000000000000001111110000001111111111111111111101111111111,
> 0b0000000000000000000000001111111111111111110111111100000000000000,
> 0b0000000000000000000000000001111100000000000000000000000000000011,
> 0b0000000000000000000000000000000000111010101010101010101010101010,
> 0b0000000000000000000000000000000000000000111110000000000001111111,
> 0b0000000000000000000000000000000000000000000000000000101111110111,
> 0b1001001111111010101010101010101010101010101010101010101010101010,
> 0b1001010111111111101010101010101010101010101010101010101010101010,
> 0b1010101000101001101010101010101010110101010101010101001001000000,
> 0b1010101010100000100000101010101010101010101110100101000010101010,
> 0b1010101010101010101010101010101011111111111111111111111111111111,
> 0b1010101010101011101010101010100000000000000000000000000000000000,
> 0b1101010010101010101010101010101010101010101010101010101101010101,
> 0b1110011001010001001011010010101001001110001001000011000100101001,
> 0b1110101111000000000000000000000000001111111111111111111111111100,
> ];
> const BITSET_MAPPING: &'static [(u8, u8); 21] = &[
> (0, 64), (1, 188), (1, 183), (1, 176), (1, 109), (1, 124), (1, 126), (1, 66), (1, 70),
> (1, 77), (2, 146), (2, 144), (2, 83), (3, 93), (3, 147), (3, 133), (4, 12), (4, 6),
> (5, 187), (6, 78), (7, 132),
> ];
>
> #[rustc_const_unstable(feature = "const_unicode_case_lookup", issue = "101400")]
> pub const fn lookup(c: char) -> bool {
> super::bitset_search(
> c as u32,
> &BITSET_CHUNKS_MAP,
> &BITSET_INDEX_CHUNKS,
> &BITSET_CANONICAL,
> &BITSET_MAPPING,
> )
> }
> }
>
> I want to know the rust value becomed unnamed after compilation is valid or not.
>
> 2.I find the wrong global value ffffffc08483e560 d __unnamed_356:
> llvm-objdump disassemble:
> Disassembly of section .text.asan.module_ctor:
>
> 0000000000000000 <.text.asan.module_ctor>:
> 0: 60 7d c4 e5 .word 0xe5c47d60
>
> 0000000000000004 <asan.module_ctor>:
> 4: d503233f paciasp
> 8: f81f0ffe str x30, [sp, #-0x10]!
> c: 90000000 adrp x0, 0x0 <.text.asan.module_ctor>
> 10: 91000000 add x0, x0, #0x0
> 14: 52803d61 mov w1, #0x1eb // =491
> 18: 94000000 bl 0x18 <asan.module_ctor+0x14>
> 1c: f84107fe ldr x30, [sp], #0x10
> 20: d50323bf autiasp
> 24: d65f03c0 ret
> But when the software running, I dump the disassemble using the TRACE32 is：
> ______________addr/line|code_____|label____|mnemonic________________|comment
> NSX:FFFFFFC0800A7C40|F800865E asan.mod.:str x30,[x18],#0x8 ; x30,[x18],#8
> NSX:FFFFFFC0800A7C44|F81F0FFE str x30,[sp,#-0x10]! ; x30,[sp,#-16]!
> NSX:FFFFFFC0800A7C48|F00240A0 adrp x0,0xFFFFFFC0848BE000
> NSX:FFFFFFC0800A7C4C|91158000 add x0,x0,#0x560 ; x0,x0,#1376
> NSX:FFFFFFC0800A7C50|52803D61 mov w1,#0x1EB ; w1,#491
> NSX:FFFFFFC0800A7C54|94233646 bl 0xFFFFFFC08097556C ; __asan_register_globals
> NSX:FFFFFFC0800A7C58|F84107FE ldr x30,[sp],#0x10 ; x30,[sp],#16
> ___NSX:FFFFFFC0800A7C5C|D50323BF____________autiasp
> NSX:FFFFFFC0800A7C60|D65F03C0 ret
>
> And llvm-readdlf -u disassembly:
> [0x14] FDE length=52 cie=[0x0]
> initial_location: 0x4
> address_range: 0x78 (end : 0x7c)
>
> Program:
> DW_CFA_advance_loc: 4 to 0x8
> DW_CFA_AARCH64_negate_ra_state:
> DW_CFA_advance_loc: 4 to 0xc
> DW_CFA_def_cfa_offset: +48
> DW_CFA_advance_loc: 12 to 0x18
> DW_CFA_def_cfa: reg29 +48
> DW_CFA_offset: reg19 -8
> DW_CFA_offset: reg20 -16
> DW_CFA_offset: reg21 -24
> DW_CFA_offset: reg22 -32
> DW_CFA_offset: reg30 -40
> DW_CFA_offset: reg29 -48
> DW_CFA_advance_loc1: 80 to 0x68
> DW_CFA_def_cfa: reg31 +48
> DW_CFA_advance_loc: 12 to 0x74
> DW_CFA_def_cfa_offset: +0
> DW_CFA_advance_loc: 4 to 0x78
> DW_CFA_AARCH64_negate_ra_state:
> DW_CFA_restore: reg19
> DW_CFA_restore: reg20
> DW_CFA_restore: reg21
> DW_CFA_restore: reg22
> DW_CFA_restore: reg30
> DW_CFA_restore: reg29
> DW_CFA_nop:
> DW_CFA_nop:
>
> I can't find something wrong in the disassemble.
I search the initial_location：0x4，and find 3 DRAWF FDE analysis. I think the below is corresponding:
[0x59cc] FDE length=20 cie=[0x0]
initial_location: 0x4
address_range: 0x24 (end : 0x28)
Program:
DW_CFA_advance_loc: 4 to 0x8
DW_CFA_AARCH64_negate_ra_state:
DW_CFA_advance_loc: 4 to 0xc
DW_CFA_def_cfa_offset: +16
DW_CFA_offset: reg30 -16
> 3.I disable CONFIG_UNWIND_PATCH_PAC_INTO_SCS , I dump the disassemble using the TRACE32 as the same as the objdump disassemble.
> Can the config be disabled in 6.12?
>
> Thank you.
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2025-07-31 0:57 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-07-14 3:12 Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS on 刘海燕 (Haiyan Liu)
2025-07-14 20:04 ` Miguel Ojeda
[not found] ` <202507150830.56F8U908028199@SHSPAM01.spreadtrum.com>
2025-07-15 9:40 ` 答复: " 刘海燕 (Haiyan Liu)
2025-07-15 17:50 ` Miguel Ojeda
2025-07-16 7:01 ` 刘海燕 (Haiyan Liu)
2025-07-16 18:21 ` Carlos Llamas
2025-07-16 20:07 ` Alice Ryhl
2025-07-16 23:19 ` Matthew Maurer
2025-07-17 1:34 ` 答复: " 刘海燕 (Haiyan Liu)
2025-07-17 7:29 ` Miguel Ojeda
2025-07-17 10:38 ` Mark Rutland
2025-07-21 6:10 ` Ard Biesheuvel
2025-07-30 9:44 ` 答复: " 刘海燕 (Haiyan Liu)
2025-07-31 0:57 ` 刘海燕 (Haiyan Liu)
-- strict thread matches above, loose matches on Subject: below --
2025-07-17 11:25 刘海燕 (Haiyan Liu)
2025-07-17 13:06 ` Mark Rutland
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).