[PATCH] arm64/boot: Zero-initialize idmap PGDs before use

[Ard Biesheuvel]

On Sun, 24 Aug 2025 at 09:56, Sam Edwards <cfsworks at gmail.com> wrote:
>
> On Sat, Aug 23, 2025 at 3:25 PM Ard Biesheuvel <ardb at kernel.org> wrote:
> >
> > Hi Sam,
> >
> > On Fri, 22 Aug 2025 at 14:15, Sam Edwards <cfsworks at gmail.com> wrote:
> > >
> > > In early boot, Linux creates identity virtual->physical address mappings
> > > so that it can enable the MMU before full memory management is ready.
> > > To ensure some available physical memory to back these structures,
> > > vmlinux.lds reserves some space (and defines marker symbols) in the
> > > middle of the kernel image. However, because they are defined outside of
> > > PROGBITS sections, they aren't pre-initialized -- at least as far as ELF
> > > is concerned.
> > >
> > > In the typical case, this isn't actually a problem: the boot image is
> > > prepared with objcopy, which zero-fills the gaps, so these structures
> > > are incidentally zero-initialized (an all-zeroes entry is considered
> > > absent, so zero-initialization is appropriate).
> > >
> > > However, that is just a happy accident: the `vmlinux` ELF output
> > > authoritatively represents the state of memory at entry. If the ELF
> > > says a region of memory isn't initialized, we must treat it as
> > > uninitialized. Indeed, certain bootloaders (e.g. Broadcom CFE) ingest
> > > the ELF directly -- sidestepping the objcopy-produced image entirely --
> > > and therefore do not initialize the gaps. This results in the early boot
> > > code crashing when it attempts to create identity mappings.
> > >
> > > Therefore, add boot-time zero-initialization for the following:
> > > - __pi_init_idmap_pg_dir..__pi_init_idmap_pg_end
> > > - idmap_pg_dir
> > > - reserved_pg_dir
> >
> > I don't think this is the right approach.
> >
> > If the ELF representation is inaccurate, it should be fixed, and this
> > should be achievable without impacting the binary image at all.
>
> Hi Ard,
>
> I don't believe I can declare the ELF output "inaccurate" per se,
> since it's the linker's final determination about the state of memory
> at kernel entry -- including which regions are not the loader's
> responsibility to initialize (and should therefore be initialized at
> runtime, e.g. .bss). But, I think I understand your meaning: you would
> prefer consistent load-time zero-initialization over run-time. I'm
> open to that approach if that's the consensus here, but it will make
> `vmlinux` dozens of KBs larger (even though it keeps `Image` the same
> size).
>

Indeed, I'd like the ELF representation to be such that only the tail
end of the image needs explicit clearing. A bit of bloat of vmlinux is
tolerable IMO.

Note that your fix is not complete: stores to memory done with the MMU
and caches disabled need to be invalidated from the D-caches too, or
they could carry stale clean lines. This is precisely the reason why
manipulation of memory should be limited to the bare minimum until the
ID map is enabled in the MMU.


> >
> > > - tramp_pg_dir # Already done, but this patch corrects the size
> > >
> >
> > What is wrong with the size?
>
> On higher-VABIT targets, that memset is overflowing by writing
> PGD_SIZE bytes despite tramp_pg_dir being only PAGE_SIZE bytes in
> size.

Under which conditions would PGD_SIZE assume a value greater than PAGE_SIZE?

Note that at stage 1, arm64 does not support page table concatenation,
and so the root page table is never larger than a page.