答复: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS on

From: 刘海燕 (Haiyan Liu)
Date: Wed Jul 30 2025 - 20:57:45 EST

Next message: Jakub Kicinski: "Re: [PATCH net] kcm: Fix splice support"
Previous message: Jakub Kicinski: "Re: [PATCH v4 00/11] QRTR Multi-endpoint support"
In reply to: 刘海燕 (Haiyan Liu): "答复: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS on"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

> -----邮件原件-----
> 发件人: 刘海燕 (Haiyan Liu)
> 发送时间: 2025年7月30日 17:45
> 收件人: 'Ard Biesheuvel' <ardb@xxxxxxxxxx>; Mark Rutland <mark.rutland@xxxxxxx>
> 抄送: linux-kernel@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; rust-for-linux@xxxxxxxxxxxxxxx; 代子为 (Ziwei Dai)
> <Ziwei.Dai@xxxxxxxxxx>; 周平 (Ping Zhou/9032) <Ping.Zhou1@xxxxxxxxxx>; 杨丽娜 (Lina Yang) <Lina.Yang@xxxxxxxxxx>; 王双
> (Shuang Wang) <Shuang.Wang@xxxxxxxxxx>; Alice Ryhl <aliceryhl@xxxxxxxxxx>; Miguel Ojeda <ojeda@xxxxxxxxxx>; Matthew Maurer
> <mmaurer@xxxxxxxxxx>; Sami Tolvanen <samitolvanen@xxxxxxxxxx>
> 主题: 答复: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default
> KBUILD_RUSTFLAGS on
>
>
>
> > -----邮件原件-----
> > 发件人: Ard Biesheuvel <ardb@xxxxxxxxxx>
> > 发送时间: 2025年7月21日 14:10
> > 收件人: Mark Rutland <mark.rutland@xxxxxxx>
> > 抄送: 刘海燕 (Haiyan Liu) <haiyan.liu@xxxxxxxxxx>;
> > linux-kernel@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx;
> > rust-for-linux@xxxxxxxxxxxxxxx; 代子为 (Ziwei Dai)
> > <Ziwei.Dai@xxxxxxxxxx>; 周平 (Ping Zhou/9032) <Ping.Zhou1@xxxxxxxxxx>;
> > 杨丽
> > 娜 (Lina Yang) <lina.yang@xxxxxxxxxx>; 王双 (Shuang Wang)
> > <shuang.wang@xxxxxxxxxx>; Alice Ryhl <aliceryhl@xxxxxxxxxx>; Miguel
> > Ojeda <ojeda@xxxxxxxxxx>; Matthew Maurer <mmaurer@xxxxxxxxxx>; Sami
> > Tolvanen <samitolvanen@xxxxxxxxxx>
> > 主题: 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@xxxxxxx> 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.

Next message: Jakub Kicinski: "Re: [PATCH net] kcm: Fix splice support"
Previous message: Jakub Kicinski: "Re: [PATCH v4 00/11] QRTR Multi-endpoint support"
In reply to: 刘海燕 (Haiyan Liu): "答复: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS on"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]