Re: [v6 PATCH 2/3] RISC-V: Update image header

[Ard Biesheuvel]

On Wed, 9 Nov 2022 at 13:01, Leif Lindholm <quic_llindhol@quicinc.com> wrote:
>
> On Wed, Nov 09, 2022 at 12:33:58 +0100, Ard Biesheuvel wrote:
> > > > Can we get rid of these header definitions entirely?
> > > >
> > > > The only GRUB code that seems to care about the fields that are not
> > > > defined in the PE/COFF spec is grub_cmd_file(), which currently parses
> > > > the magic field, but given that we only support EFI boot anyway, that
> > > > code should just parse the PE machine type instead.
> > >
> > > Right, so your patch from August dropped that check in the loader
> > > itself. I missed that one.
> > >
> > > The drawback to that is that not all EFI executables are destined for
> > > the Linux loader. So while trying to boot them using the linux loader
> > > is definitely user error, that change removed a potentially useful
> > > user-visible error message.
> >
> > The new EFI zboot images don't have the arch specific magic numbers
> > either, and those are Linux images too.
> >
> > So pretending that Linux EFI PE/COFF images are always hybrid images
> > that could also boot in bare metal mode is no longer appropriate in
> > any case,
>
> Is that true for arm32 as well?
>

Is what true?

> Certainly for arm64, *a* change was needed.
>

RISC-V, arm64 and LoongArch now all use the same compressed format,
which can decompress itself when executed as a EFI binary, or be
decompressed by a non-EFI loader using the metadata in the header.

So it might make sense for GRUB to be able to identify this image type
specifically as well, but only if that information is useful in some
way.

> > and we should really just deal with the fact that the linux
> > loader and the chainloader are mostly the same thing on EFI-only
> > architectures.
>
> Architectures that only support *linux* booting via EFI.
> Which arm32 isn't.
>

I am not following you here.

> *Dealing* with that would mean merging the linux- and chain-
> loaders. Not dropping sanity checks and keeping both.
>

The sanity check had to be dropped because not all EFI Linux images
carry the magic number.

Whether or not the chainloader and the linux loader are the same thing
is a different matter.

> The change may have been the appropriate compromise, but it wasn't
> treated as one.
>

It is not a compromise. GRUB should not reason about whether or not a
Linux EFI image is also bootable via the bare metal boot protocol
which it does not implement.