[PATCH v6 3/6] arm64: head: record the MMU state at primary entry

[Will Deacon]

On Thu, Dec 01, 2022 at 10:18:50AM +0100, Ard Biesheuvel wrote:
> On Tue, 29 Nov 2022 at 17:14, Ard Biesheuvel <ardb at kernel.org> wrote:
> >
> > Prepare for being able to deal with primary entry with the MMU and
> > caches enabled, by recording whether or not we entered with the MMU on
> > in register x19 and in a global variable. (Note that writing to this
> > variable does not require cache invalidation, nor is it required for
> > storing the bootargs in that case, so omit the cache maintenance).
> >
> > Since boot with the MMU enabled is not permitted by the bare metal boot
> > protocol, ensure that a diagnostic is emitted and a taint bit set if
> > the MMU was found to be enabled on a non-EFI boot. We will make an
> > exception for EFI boot later, which has strict requirements for the
> > mapping of system memory, permitting us to relax the boot protocol and
> > hand over from the EFI stub to the core kernel with MMU and caches left
> > enabled. To reduce the likelihood that bare metal boot will violate this
> > requirement, introduce a separate entry point for EFI boot, which is
> > different from the one that is invoked by branching to offset #0 in the
> > image.
> >
> 
> This is actually much more fiddly than I though:
> - the existing arm64 stub can link to any symbol so there, it does not
> make any difference
> - the zboot stub needs to find the right entry point into the image,
> as the one pointed to by the header is no longer correct.
> 
> I confused myself into thinking that we can just grab it from the
> PE/COFF header, but that is the header point *into* the EFI stub, not
> the one that the stub calls on its way out.
> 
> Grabbing stuff from the PE/COFF header is needed anyway, and can be
> done in a generic manner.
> Grabbing a special EFI-only entry point means mangling the ELF to find
> the relative offset from the start of the binary representation of the
> image, and passing that information along with the compressed blob to
> the decompressor.
> 
> So the options are:
> - go back to the old approach (and add a panic() in the right place)

I'm ok with that, but I'd like an Ack from Mark as well.

Cheers,

Will