From: Daniel Kiper <daniel.kiper@oracle.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-efi@vger.kernel.org, grub-devel@gnu.org,
Huacai Chen <chenhuacai@kernel.org>,
Atish Patra <atishp@rivosinc.com>,
Heinrich Schuchardt <heinrich.schuchardt@canonical.com>,
Leif Lindholm <quic_llindhol@quicinc.com>
Subject: Re: [PATCH v2 2/2] efi: Put Linux specific magic number in the DOS header
Date: Thu, 1 Dec 2022 15:58:09 +0100 [thread overview]
Message-ID: <Y4jBATz+P0gxtoD0@tomti.i.net-space.pl> (raw)
In-Reply-To: <CAMj1kXEzzicO_V=ZKBgvWWFAoa1XNSO5KRZaCPYO1boT9s+Vig@mail.gmail.com>
On Thu, Dec 01, 2022 at 03:48:12PM +0100, Ard Biesheuvel wrote:
> On Thu, 1 Dec 2022 at 15:30, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> > On Tue, Nov 29, 2022 at 06:56:16PM +0100, Ard Biesheuvel wrote:
> > > GRUB currently relies on the magic number in the image header of ARM and
> > > arm64 EFI kernel images to decide whether or not the image in question
> > > is a bootable kernel.
> > >
> > > However, the purpose of the magic number is to identify the image as one
> > > that implements the bare metal boot protocol, and so GRUB, which only
> > > does EFI boot, can only boot images that could potentially be booted in
> > > a non-EFI manner as well.
> > >
> > > This is problematic for the new zboot decompressor image format, as it
> > > can only boot in EFI mode, and must therefore not use the bare metal
> > > boot magic number in its header.
> > >
> > > For this reason, the strict magic number was dropped from GRUB, to
> > > permit essentially any kind of EFI executable to be booted via the
> > > 'linux' command, blurring the line between the linux loader and the
> > > chainloader.
> > >
> > > So let's use the same field in the DOS header that RISC-V and arm64
> > > already use for their 'bare metal' magic numbers to store a 'generic
> > > Linux kernel' magic number, which can be used to identify bootable
> > > kernel images in PE format which don't necessarily implement a bare
> > > metal boot protocol in the same binary. Note that, in the context of
> > > EFI, the MSDOS header is only described in terms of the fields that it
> >
> > s/MSDOS/MS-DOS/ to be consistent with other places in the patch...
> >
> > > shares with the hybrid PE/COFF image format, (i.e., the magic number at
> > > offset #0 and the PE header offset at byte offset #0x3c). Since we aim
> >
> > s/the magic number at offset #0/MS-DOS EXE magic number at offset #0/?
> >
> > "the magic number at offset #0" itself is confusing in the context of
> > number of "magic number" phrases in the patch... :-)
> >
> > > for compatibility with EFI only, and not with MS-DOS or MS-Windows, we
> > > can use the remaining space in the MS-DOS header however we want.
> > >
> > > Let's set the generic magic number for x86 images as well: existing
> > > bootloaders already have their own methods to identify x86 Linux images
> > > that can be booted in a non-EFI manner, and having the magic number in
> > > place there will ease any future transitions in loader implementations
> > > to merge the x86 and non-x86 EFI boot paths.
> > >
> > > Note that 32-bit ARM already uses the same location in the header for a
> > > different purpose, but the ARM support is already widely implemented and
> > > the EFI zboot decompressor is not available on ARM anyway, so we just
> > > disregard it here.
> > >
> > > Cc: Huacai Chen <chenhuacai@kernel.org>
> > > Cc: Atish Patra <atishp@rivosinc.com>
> > > Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> > > Cc: Daniel Kiper <daniel.kiper@oracle.com>
> > > Cc: Leif Lindholm <quic_llindhol@quicinc.com>
> > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> > > ---
> > > arch/loongarch/kernel/head.S | 3 ++-
> > > arch/x86/boot/header.S | 3 ++-
> > > drivers/firmware/efi/libstub/zboot-header.S | 3 ++-
> > > include/linux/pe.h | 7 +++++++
> > > 4 files changed, 13 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/loongarch/kernel/head.S b/arch/loongarch/kernel/head.S
> > > index 84970e2666588963..caa74439700eee93 100644
> > > --- a/arch/loongarch/kernel/head.S
> > > +++ b/arch/loongarch/kernel/head.S
> > > @@ -25,7 +25,8 @@ _head:
> > > .dword kernel_entry /* Kernel entry point */
> > > .dword _end - _text /* Kernel image effective size */
> > > .quad 0 /* Kernel image load offset from start of RAM */
> > > - .org 0x3c /* 0x20 ~ 0x3b reserved */
> > > + .org 0x38 /* 0x20 ~ 0x38 reserved */
> > > + .long LINUX_PE_MAGIC
> > > .long pe_header - _head /* Offset to the PE header */
> > >
> > > pe_header:
> > > diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
> > > index f912d777013052ea..be8f78a7ee325475 100644
> > > --- a/arch/x86/boot/header.S
> > > +++ b/arch/x86/boot/header.S
> > > @@ -80,10 +80,11 @@ bs_die:
> > > ljmp $0xf000,$0xfff0
> > >
> > > #ifdef CONFIG_EFI_STUB
> > > - .org 0x3c
> > > + .org 0x38
> > > #
> > > # Offset to the PE header.
> > > #
> > > + .long LINUX_PE_MAGIC
> > > .long pe_header
> > > #endif /* CONFIG_EFI_STUB */
> > >
> > > diff --git a/drivers/firmware/efi/libstub/zboot-header.S b/drivers/firmware/efi/libstub/zboot-header.S
> > > index bc2d7750d7f14174..ec4525d40e0cf6d6 100644
> > > --- a/drivers/firmware/efi/libstub/zboot-header.S
> > > +++ b/drivers/firmware/efi/libstub/zboot-header.S
> > > @@ -20,7 +20,8 @@ __efistub_efi_zboot_header:
> > > .long __efistub__gzdata_size - 12 // payload size
> > > .long 0, 0 // reserved
> > > .asciz COMP_TYPE // compression type
> > > - .org .Ldoshdr + 0x3c
> > > + .org .Ldoshdr + 0x38
> > > + .long LINUX_PE_MAGIC
> > > .long .Lpehdr - .Ldoshdr // PE header offset
> > >
> > > .Lpehdr:
> > > diff --git a/include/linux/pe.h b/include/linux/pe.h
> > > index 056a1762de904fc1..1db4c944efd78f51 100644
> > > --- a/include/linux/pe.h
> > > +++ b/include/linux/pe.h
> > > @@ -31,6 +31,13 @@
> > > #define LINUX_EFISTUB_MAJOR_VERSION 0x1
> > > #define LINUX_EFISTUB_MINOR_VERSION 0x1
> > >
> > > +/*
> > > + * LINUX_PE_MAGIC appears at offset 0x38 into the MSDOS header of EFI bootable
> >
> > s/MSDOS/MS-DOS/
> >
> > > + * Linux kernel images that target the architecture as specified by the PE/COFF
> > > + * header machine type field.
> > > + */
> > > +#define LINUX_PE_MAGIC 0x818223cd
> > > +
> > > #define MZ_MAGIC 0x5a4d /* "MZ" */
> > >
> > > #define PE_MAGIC 0x00004550 /* "PE\0\0" */
> >
> > If you take into account these minor things mentioned above you can add
> > Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> to your both patches.
>
> Thanks
You are welcome!
> > Atish, could you respin your GRUB "Unify ARM64 & RISC-V Linux Loader"
> > patch set when both Ard's patches are in at least "efi" Linux kernel
> > branch? Hmmm... I am not sure it will go through "efi" branch. Ard?
>
> Yes, I already pushed a version, but I will update the patch to take
> your feedback into account.
Great!
> The patch is queued up for v6.2, so it should be in mainline by the
> end of the year.
Cool! Thanks a lot!
Daniel
next prev parent reply other threads:[~2022-12-01 14:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-29 17:56 [PATCH v2 0/2] efi: Add generic magic number in header Ard Biesheuvel
2022-11-29 17:56 ` [PATCH v2 1/2] efi: libstub: Always enable initrd command line loader and bump version Ard Biesheuvel
2022-11-29 17:56 ` [PATCH v2 2/2] efi: Put Linux specific magic number in the DOS header Ard Biesheuvel
2022-12-01 14:29 ` Daniel Kiper
2022-12-01 14:48 ` Ard Biesheuvel
2022-12-01 14:58 ` Daniel Kiper [this message]
2022-12-01 19:25 ` Daniel Kiper
2022-12-06 9:52 ` Atish Patra
2022-12-07 7:51 ` Xiaotian Wu
2022-12-07 8:06 ` Ard Biesheuvel
2022-12-07 10:35 ` Xiaotian Wu
2022-12-07 14:06 ` Ard Biesheuvel
2022-11-29 19:58 ` [PATCH v2 0/2] efi: Add generic magic number in header Leif Lindholm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y4jBATz+P0gxtoD0@tomti.i.net-space.pl \
--to=daniel.kiper@oracle.com \
--cc=ardb@kernel.org \
--cc=atishp@rivosinc.com \
--cc=chenhuacai@kernel.org \
--cc=grub-devel@gnu.org \
--cc=heinrich.schuchardt@canonical.com \
--cc=linux-efi@vger.kernel.org \
--cc=quic_llindhol@quicinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox