[PATCH v2 3/3] arm64/boot: Disallow BSS exports to startup code

[Ard Biesheuvel]

On Thu, 8 May 2025 at 15:34, Yeoreum Yun <yeoreum.yun at arm.com> wrote:
>
> Hi Ard,
>
> > From: Ard Biesheuvel <ardb at kernel.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 at kernel.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.