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.