| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <2a6c53dea2674536be64c4ea9cac8a59@BJMBX01.spreadtrum.com>
Date: Wed, 23 Jul 2025 06:46:07 +0000
From: 刘海燕 (Haiyan Liu) <haiyan.liu@...soc.com>
To: Mark Rutland <mark.rutland@....com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"rust-for-linux@...r.kernel.org"
<rust-for-linux@...r.kernel.org>,
代子为 (Ziwei Dai)
<Ziwei.Dai@...soc.com>,
周平 (Ping Zhou/9032)
<Ping.Zhou1@...soc.com>,
杨丽娜 (Lina Yang)
<lina.yang@...soc.com>,
王双 (Shuang Wang)
<shuang.wang@...soc.com>,
Alice Ryhl <aliceryhl@...gle.com>, Miguel Ojeda
<ojeda@...nel.org>,
Matthew Maurer <mmaurer@...gle.com>, Ard Biesheuvel
<ardb@...nel.org>,
Sami Tolvanen <samitolvanen@...gle.com>
Subject: 答复: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS on
> -----邮件原件-----
> 发件人: Mark Rutland <mark.rutland@....com>
> 发送时间: 2025年7月17日 21:07
> 收件人: 刘海燕 (Haiyan Liu) <haiyan.liu@...soc.com>
> 抄送: linux-kernel@...r.kernel.org; linux-arm-kernel@...ts.infradead.org; rust-for-linux@...r.kernel.org; 代子为 (Ziwei Dai)
> <Ziwei.Dai@...soc.com>; 周平 (Ping Zhou/9032) <Ping.Zhou1@...soc.com>; 杨丽娜 (Lina Yang) <lina.yang@...soc.com>; 王双
> (Shuang Wang) <shuang.wang@...soc.com>; Alice Ryhl <aliceryhl@...gle.com>; Miguel Ojeda <ojeda@...nel.org>; Matthew Maurer
> <mmaurer@...gle.com>; Ard Biesheuvel <ardb@...nel.org>; Sami Tolvanen <samitolvanen@...gle.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, Jul 17, 2025 at 11:25:00AM +0000, 刘海燕 (Haiyan Liu) wrote:
> > > -----邮件原件-----
> > > 发件人: Mark Rutland <mark.rutland@....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?
Yes, I stop the cpu after do_ctors() which run after scs_patch().
> > > > 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?
Yes, CONFIG_UNWIND_PATCH_PAC_INTO_SCS is selected and I try to set CONFIG_UNWIND_PATCH_PAC_INTO_SCS not set, this issue not happen.
> > > 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.
Thank you for you suggestion, I will go to find where the affected asan.module_ctor functions are from.
> Mark.
Powered by blists - more mailing lists