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

[Ard Biesheuvel]

On Wed, 9 Nov 2022 at 12:21, Leif Lindholm <quic_llindhol@quicinc.com> wrote:
>
> On Tue, Nov 08, 2022 at 17:36:51 +0100, Ard Biesheuvel wrote:
> > > I can agree that hdr_offset makes more sense but
> > > Documentation/riscv/boot-image-header.rst names this member as res3.
> > > So, I would rename hdr_offset to res3 too. Or fix
> > > Documentation/riscv/boot-image-header.rst in the kernel. Or, least
> > > preferred, explain in the commit message why you do not rename this
> > > member and add to the comment that this member is named res3 in the
> > > documentation.
> >
> > 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, 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.