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

[Ard Biesheuvel]

On Wed, 9 Nov 2022 at 13:38, Leif Lindholm <quic_llindhol@quicinc.com> wrote:
>
> On Wed, Nov 09, 2022 at 13:10:29 +0100, Ard Biesheuvel wrote:
> > > > > 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?
>
> That arm32 linux images containing an EFI stub do not always contain
> the magic field?
>

No, but I'm not sure how that matters. We will have a generic EFI
loader for arm64, ARM and RISC-V, and shortly also for LoongArch.
Those images may not have magic numbers because they do not support
bare metal boot only EFI boot.

The fact that none of the images in the latter category happen to be
arm32 seems hardly relevant to me.

> > > 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.
>
> In order to be able to indicate to a user, who may *not* be a kernel
> developer, or even be aware of the concept of different types of
> kernel images, that they picked the wrong image some other way than
> the boot failing.
>

OK, so that information *is* useful in some way. Fair enough.

> > > > 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.
>
> No, the sanity check had to be *changed* because not all EFI Linux
> images carry the magic number.
>
> If there really is no way to tell the EFI xboot kernel from any other
> EFI executable for the same architecture, then:
> - that's going to be reasonably annoying also from within the OS when
>   using the file command.
> - we have lost the ability to warn users they (or their cross-upgrade)
>   picked the wrong file.
>

There is. The zboot image header clearly spells out 'zimg', the
compression type and the start and size of the compressed payload
inside the EFI binary.

> > Whether or not the chainloader and the linux loader are the same thing
> > is a different matter.
>
> You brought that point up, not me.
> I agree the chainloader should not go looking for further magic.
>

Ok, at least we agree on something :-)

> > > 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.
>
> GRUB should, where reasonable, provide helpful messages to end users.
>
> That means a loader for a specific operating system should do basic
> sanity checks to verify that the image is for that operating system
> where at all possible. Otherwise, it should not be using an
> os-specific loader.
>
> Of course, if the operating system decides that's an antifeature, it
> can always choose to not provide identifiable images.
>

In that case, we should add something to the PE headers of Linux
kernels built for any architecture to identify it as such. And we
should add the same thing to the zboot images, so they are
identifiable both as a zboot image and as a linux kernel.