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

[Leif Lindholm]

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?

> > 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.

> > > 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.

> 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.

> > 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.

/
    Leif