Re: [PATCH] arm64: mm: Defer read-only remap of data/bss linear alias
From: Ard Biesheuvel
Date: Mon Jun 22 2026 - 12:46:59 EST
Hi Kevin,
On Mon, Jun 22, 2026 at 5:23 PM Kevin Brodsky <kevin.brodsky@xxxxxxx> wrote:
>
> On 19/06/2026 18:39, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel <ardb@xxxxxxxxxx>
> >
> > Fuad reports that in some cases, the KVM init code may apply relocations
> > to variables that reside in .data, and does so via the linear map. This
> > means that remapping .data read-only beforehand is a bad idea, and
> > results in an early boot crash.
> >
> > These variables in .data are only present when CONFIG_NVHE_EL2_DEBUG or
> > CONFIG_NVHE_EL2_TRACING are enabled, which is why it was not spotted in
> > testing.
> >
> > So move the remap to mark_rodata_ro(), which is a reasonable place to
> > put this, and ensures that it happens much later during the boot. It
> > also means that rodata=off is now taken into account, and so the linear
> > alias will remain writable in that case.
> >
> > Cc: Fuad Tabba <fuad.tabba@xxxxxxxxx>
> > Fixes: f2ba877402e5 ("arm64: mm: Map the kernel data/bss read-only in the linear map")
> > Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx>
> > ---
> > arch/arm64/mm/mmu.c | 11 ++++++-----
> > 1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > index 9f354971b7e4..1f7eca86b5c1 100644
> > --- a/arch/arm64/mm/mmu.c
> > +++ b/arch/arm64/mm/mmu.c
> > @@ -1198,11 +1198,6 @@ static void __init map_mem(void)
> > __map_memblock(start, end, pgprot_tagged(PAGE_KERNEL),
> > flags);
> > }
> > -
> > - /* Map the kernel data/bss read-only in the linear map */
> > - __map_memblock(init_end, kernel_end, PAGE_KERNEL_RO, flags);
> > - flush_tlb_kernel_range((unsigned long)lm_alias(__init_end),
> > - (unsigned long)lm_alias(__bss_stop));
> > }
> >
> > void mark_rodata_ro(void)
> > @@ -1221,6 +1216,12 @@ void mark_rodata_ro(void)
> > update_mapping_prot(__pa_symbol(_text), (unsigned long)_text,
> > (unsigned long)_stext - (unsigned long)_text,
> > PAGE_KERNEL_RO);
> > +
> > + /* Map the kernel data/bss read-only in the linear map */
> > + update_mapping_prot(__pa_symbol(__init_end),
> > + (unsigned long)lm_alias(__init_end),
> > + (unsigned long)__bss_stop - (unsigned long)__init_end,
> > + PAGE_KERNEL_RO);
>
> I was rather confused by this patch until I saw in master:
>
> f102131c842d Revert "arm64: mm: Unmap kernel data/bss entirely from the
> linear map"
> 81479b6888f8 Revert "arm64: mm: Defer remap of linear alias of data/bss"
>
> ... which explains the diff, but it looks like there are multiple issues
> here. Is my understanding correct that these reverts fix kvm_arm_init()
> because it needs to *read* from the linear map, while this new patch
> fixes some KVM configurations that need to *write* to the linear map?
>
Basically, yes.
> If so it might be good to give a recap in the commit message, because
> the reverts are easy to miss.
>
Ok
> It would also be good to explain why we can't do this in
> mark_linear_text_alias_ro() (presumably because this is too early). I do
> agree that honouring rodata=off is a good thing, though.
>
I didn't consider that tbh - I'll check whether that is a more suitable
location. But generally, I think doing it later rather than earlier is
fine because it reduces the likelihood of hidden issues such as the one
being addressed by this patch, and I don't think doing this very early
makes a meaningful difference in terms of robustness.
> BTW, if only kvm_arm_init() needs to read the data/bss via the linear
> map, maybe we can still unmap it later?
>
Yes, it is still my intent to bring back the patches that unmap this alias
entirely, including some additional tweaks for the fixmap PTE level table
that I dropped after an earlier revision. But that will be 7.3 material,
whereas this fixes a regression due to the changes that were pulled for 7.2.