linux-kernel - Re: [PATCH v2 3/3] arm64/boot: Disallow BSS exports to startup code

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMj1kXE-VbdniRZ9Y+u9eaw9JM_qot+TJkQkfULX548YvKD4Ww@mail.gmail.com>
Date: Fri, 9 May 2025 08:43:03 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Yeoreum Yun <yeoreum.yun@....com>
Cc: Ard Biesheuvel <ardb+git@...gle.com>, linux-arm-kernel@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, will@...nel.org, catalin.marinas@....com, 
	mark.rutland@....com
Subject: Re: [PATCH v2 3/3] arm64/boot: Disallow BSS exports to startup code

On Thu, 8 May 2025 at 15:34, Yeoreum Yun <yeoreum.yun@....com> wrote:
>
> Hi Ard,
>
> > From: Ard Biesheuvel <ardb@...nel.org>
> >
> > BSS might be uninitialized when entering the startup code, so forbid the
> > use by the startup code of any variables that live after __bss_start in
> > the linker map.
> >
> > Signed-off-by: Ard Biesheuvel <ardb@...nel.org>
> > ---
> >  arch/arm64/kernel/image-vars.h  | 62 +++++++++++---------
> >  arch/arm64/kernel/vmlinux.lds.S |  2 +
> >  2 files changed, 35 insertions(+), 29 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/image-vars.h b/arch/arm64/kernel/image-vars.h
> > index c3b4c0479d5c..a928e0c0b45a 100644
> > --- a/arch/arm64/kernel/image-vars.h
> > +++ b/arch/arm64/kernel/image-vars.h
> > @@ -10,6 +10,12 @@
> >  #error This file should only be included in vmlinux.lds.S
> >  #endif
> >
> > +#define PI_EXPORT_SYM(sym)           \
> > +     __PI_EXPORT_SYM(sym, __pi_ ## sym, Cannot export BSS symbol sym to startup code)
> > +#define __PI_EXPORT_SYM(sym, pisym, msg)\
> > +     PROVIDE(pisym = sym);           \
> > +     ASSERT((sym - KIMAGE_VADDR) < (__bss_start - KIMAGE_VADDR), #msg)
> > +
> >  PROVIDE(__efistub_primary_entry              = primary_entry);
> >
> >  /*
> > @@ -36,37 +42,35 @@ PROVIDE(__pi___memcpy                     = __pi_memcpy);
> >  PROVIDE(__pi___memmove                       = __pi_memmove);
> >  PROVIDE(__pi___memset                        = __pi_memset);
> >
> > -PROVIDE(__pi_id_aa64isar1_override   = id_aa64isar1_override);
> > -PROVIDE(__pi_id_aa64isar2_override   = id_aa64isar2_override);
> > -PROVIDE(__pi_id_aa64mmfr0_override   = id_aa64mmfr0_override);
> > -PROVIDE(__pi_id_aa64mmfr1_override   = id_aa64mmfr1_override);
> > -PROVIDE(__pi_id_aa64mmfr2_override   = id_aa64mmfr2_override);
> > -PROVIDE(__pi_id_aa64pfr0_override    = id_aa64pfr0_override);
> > -PROVIDE(__pi_id_aa64pfr1_override    = id_aa64pfr1_override);
> > -PROVIDE(__pi_id_aa64smfr0_override   = id_aa64smfr0_override);
> > -PROVIDE(__pi_id_aa64zfr0_override    = id_aa64zfr0_override);
> > -PROVIDE(__pi_arm64_sw_feature_override       = arm64_sw_feature_override);
> > -PROVIDE(__pi_arm64_use_ng_mappings   = arm64_use_ng_mappings);
> > +PI_EXPORT_SYM(id_aa64isar1_override);
> > +PI_EXPORT_SYM(id_aa64isar2_override);
> > +PI_EXPORT_SYM(id_aa64mmfr0_override);
> > +PI_EXPORT_SYM(id_aa64mmfr1_override);
> > +PI_EXPORT_SYM(id_aa64mmfr2_override);
> > +PI_EXPORT_SYM(id_aa64pfr0_override);
> > +PI_EXPORT_SYM(id_aa64pfr1_override);
> > +PI_EXPORT_SYM(id_aa64smfr0_override);
> > +PI_EXPORT_SYM(id_aa64zfr0_override);
> > +PI_EXPORT_SYM(arm64_sw_feature_override);
> > +PI_EXPORT_SYM(arm64_use_ng_mappings);
> >  #ifdef CONFIG_CAVIUM_ERRATUM_27456
> > -PROVIDE(__pi_cavium_erratum_27456_cpus       = cavium_erratum_27456_cpus);
> > -PROVIDE(__pi_is_midr_in_range_list   = is_midr_in_range_list);
> > +PI_EXPORT_SYM(cavium_erratum_27456_cpus);
> > +PI_EXPORT_SYM(is_midr_in_range_list);
>
> small nit:
> Would you rebase this patchset after
> commit 117c3b21d3c7 ("arm64: Rework checks for broken Cavium HW in the PI code")?
> Otherwise, I experience boot failure because of SCS related code:
>
>   ffff80008009fbc0 <is_midr_in_range_list>:
>   ffff80008009fbc0: d503245f    bti     c
>   ffff80008009fbc4: d503201f    nop
>   ffff80008009fbc8: d503201f    nop
>   ffff80008009fbcc: f800865e    str     x30, [x18], #0x8 ---- (1)
>   ffff80008009fbd0: d503233f    paciasp
>   ...
>
> At pi phase, platform register initialized properly...
> So it makes panic on (1).
>

That commit is not in the arm64 tree, so it will be up to Marc and
Catalin to resolve the conflict.

Your commit

363cd2b81cfd arm64: cpufeature: Move arm64_use_ng_mappings to the
.data section to prevent wrong idmap generation

is not in the kvmarm tree, so the build will not even complete if you
rebase it on that.

For testing, please merge the kvmarm tree and resolve the conflict by hand.