[PATCH v2 0/2] efi: Add generic magic number in header

[PATCH v2 0/2] efi: Add generic magic number in header

[Ard Biesheuvel]

This is a minimal respin of the RFC patch I sent out a few week ago. No
changes were applied except the /0x30/0x38 typo fix and some additional
wording in the commit log. I also added a patch to make the command line
initrd loader always built-in.

The purpose of all of this is to create *and document* a common baseline
for EFI booting of Linux. (I know I promised some documentation myself,
but I simply don't have time for that, so if anyone feels so inclined,
please go ahead).

The idea is that EFI images with the LINUX_PE_MAGIC number are
guaranteed to support:
- initrd loading via LoadFile2
- initrd loading via the command line
- (on x86) mixed mode boot via the .compat entry point
- other things I missed?

Architectures such as arm64 and RISC-V already have their own magic
numbers, in which case the PE/COFF major/minor image version should be
inspected, where 1.1 corresponds with the set described above.

If other architectures want to create hybrid images as well, it would be
better to use a different offset to store the magic number, so that the
generic EFI one can be carried as well. The reason for deviating from
this for arm64 and RISC-V is the simple fact that existing images
already exist, so for those architectures, we have to consider both
anyway.

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>

Ard Biesheuvel (2):
  efi: libstub: Always enable initrd command line loader and bump
    version
  efi: Put Linux specific magic number in the DOS header

 arch/loongarch/kernel/head.S                   |  3 ++-
 arch/x86/boot/header.S                         |  3 ++-
 drivers/firmware/efi/Kconfig                   | 15 ---------------
 drivers/firmware/efi/libstub/efi-stub-helper.c |  3 +--
 drivers/firmware/efi/libstub/zboot-header.S    |  3 ++-
 include/linux/pe.h                             |  9 ++++++++-
 6 files changed, 15 insertions(+), 21 deletions(-)

-- 
2.35.1

[PATCH v2 1/2] efi: libstub: Always enable initrd command line loader and bump version

[Ard Biesheuvel]

In preparation for setting a cross-architecture baseline for EFI boot
support, remove the Kconfig option that permits the command line initrd
loader to be disabled. Also, bump the minor version so that any image
built with the new version can be identified as supporting this.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
 drivers/firmware/efi/Kconfig                   | 15 ---------------
 drivers/firmware/efi/libstub/efi-stub-helper.c |  3 +--
 include/linux/pe.h                             |  2 +-
 3 files changed, 2 insertions(+), 18 deletions(-)

diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
index 08ed88e49ea307b0..043ca31c114ebf2a 100644
--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -106,21 +106,6 @@ config EFI_ARMSTUB_DTB_LOADER
 	  functionality for bootloaders that do not have such support
 	  this option is necessary.
 
-config EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER
-	bool "Enable the command line initrd loader" if !X86
-	depends on EFI_STUB && (EFI_GENERIC_STUB || X86)
-	default y if X86
-	help
-	  Select this config option to add support for the initrd= command
-	  line parameter, allowing an initrd to be loaded into memory that
-	  resides on a file system backed by an implementation of
-	  EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.
-
-	  This method has been superseded by the simpler LoadFile2 based
-	  initrd loading method, but the initrd= loader is retained as it
-	  can be used from the UEFI Shell or other generic loaders that
-	  don't implement the Linux specific LoadFile2 method.
-
 config EFI_BOOTLOADER_CONTROL
 	tristate "EFI Bootloader Control"
 	select UCS2_STRING
diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c b/drivers/firmware/efi/libstub/efi-stub-helper.c
index 739454d8063af8b1..f5a4bdacac642846 100644
--- a/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -538,8 +538,7 @@ efi_status_t efi_load_initrd_cmdline(efi_loaded_image_t *image,
 				     unsigned long soft_limit,
 				     unsigned long hard_limit)
 {
-	if (!IS_ENABLED(CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER) ||
-	    (IS_ENABLED(CONFIG_X86) && image == NULL))
+	if (image == NULL)
 		return EFI_UNSUPPORTED;
 
 	return handle_cmdline_files(image, L"initrd=", sizeof(L"initrd=") - 2,
diff --git a/include/linux/pe.h b/include/linux/pe.h
index 1d3836ef9d92dcd8..056a1762de904fc1 100644
--- a/include/linux/pe.h
+++ b/include/linux/pe.h
@@ -29,7 +29,7 @@
  * handover_offset and xloadflags fields in the bootparams structure.
  */
 #define LINUX_EFISTUB_MAJOR_VERSION		0x1
-#define LINUX_EFISTUB_MINOR_VERSION		0x0
+#define LINUX_EFISTUB_MINOR_VERSION		0x1
 
 #define MZ_MAGIC	0x5a4d	/* "MZ" */
 
-- 
2.35.1

[PATCH v2 2/2] efi: Put Linux specific magic number in the DOS header

[Ard Biesheuvel]

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
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
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
+ * 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" */
-- 
2.35.1

Re: [PATCH v2 0/2] efi: Add generic magic number in header

[Leif Lindholm]

On Tue, Nov 29, 2022 at 18:56:14 +0100, Ard Biesheuvel wrote:
> This is a minimal respin of the RFC patch I sent out a few week ago. No
> changes were applied except the /0x30/0x38 typo fix and some additional
> wording in the commit log. I also added a patch to make the command line
> initrd loader always built-in.
> 
> The purpose of all of this is to create *and document* a common baseline
> for EFI booting of Linux. (I know I promised some documentation myself,
> but I simply don't have time for that, so if anyone feels so inclined,
> please go ahead).
> 
> The idea is that EFI images with the LINUX_PE_MAGIC number are
> guaranteed to support:
> - initrd loading via LoadFile2
> - initrd loading via the command line
> - (on x86) mixed mode boot via the .compat entry point
> - other things I missed?
> 
> Architectures such as arm64 and RISC-V already have their own magic
> numbers, in which case the PE/COFF major/minor image version should be
> inspected, where 1.1 corresponds with the set described above.
> 
> If other architectures want to create hybrid images as well, it would be
> better to use a different offset to store the magic number, so that the
> generic EFI one can be carried as well. The reason for deviating from
> this for arm64 and RISC-V is the simple fact that existing images
> already exist, so for those architectures, we have to consider both
> anyway.
> 
> 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>

For the series:
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com>

Thanks!

> 
> Ard Biesheuvel (2):
>   efi: libstub: Always enable initrd command line loader and bump
>     version
>   efi: Put Linux specific magic number in the DOS header
> 
>  arch/loongarch/kernel/head.S                   |  3 ++-
>  arch/x86/boot/header.S                         |  3 ++-
>  drivers/firmware/efi/Kconfig                   | 15 ---------------
>  drivers/firmware/efi/libstub/efi-stub-helper.c |  3 +--
>  drivers/firmware/efi/libstub/zboot-header.S    |  3 ++-
>  include/linux/pe.h                             |  9 ++++++++-
>  6 files changed, 15 insertions(+), 21 deletions(-)
> 
> -- 
> 2.35.1
> 

Re: [PATCH v2 2/2] efi: Put Linux specific magic number in the DOS header

[Daniel Kiper]

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.

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?

Daniel

Re: [PATCH v2 2/2] efi: Put Linux specific magic number in the DOS header

[Ard Biesheuvel]

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

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

The patch is queued up for v6.2, so it should be in mainline by the
end of the year.

Re: [PATCH v2 2/2] efi: Put Linux specific magic number in the DOS header

[Daniel Kiper]

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

Re: [PATCH v2 2/2] efi: Put Linux specific magic number in the DOS header

[Daniel Kiper]

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 */

Sadly one more thing... :-(

s/0x20 ~ 0x38 reserved/0x20 ~ 0x37 reserved/

Daniel

Re: [PATCH v2 2/2] efi: Put Linux specific magic number in the DOS header

[Atish Patra]

On Thu, Dec 1, 2022 at 6:30 AM 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.
>
> 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?
>

Sure. We need to remove the arch specific header files in the next
version as well.
I am planning to revise the series before/during the holidays. Hope
that's fine w.r.t Grub release.
Otherwise, please let me know.

> Daniel



-- 
Regards,
Atish

Re: [PATCH v2 2/2] efi: Put Linux specific magic number in the DOS header

[Xiaotian Wu]

在 2022-11-29星期二的 18:56 +0100，Ard Biesheuvel写道：
> 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
> 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
> 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
> + * 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" */


As far as I know, Archlinux automatically generates initramfs according
to the version number in the kernel file. The latest generic compressed
EFI designs do not seem to provide kernel version number information.
This may change the usage habits of Archlinux users. Is it possible to
add the kernel version number to vmlinuz.efi?

https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/blob/master/functions#L209

-- 
Best Regards
Xiaotian Wu

Re: [PATCH v2 2/2] efi: Put Linux specific magic number in the DOS header

[Ard Biesheuvel]

On Wed, 7 Dec 2022 at 08:51, Xiaotian Wu <wuxiaotian@loongson.cn> wrote:
>
> 在 2022-11-29星期二的 18:56 +0100，Ard Biesheuvel写道：
> > 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
> > 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
> > 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
> > + * 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" */
>
>
> As far as I know, Archlinux automatically generates initramfs according
> to the version number in the kernel file. The latest generic compressed
> EFI designs do not seem to provide kernel version number information.

No, but nor do the gzip'ed images arm64 uses today, and the script
seems take care of that.

The EFI zboot image has metadata in the header, so the script can
decompress it and grep for the version number it it needs to.

> This may change the usage habits of Archlinux users. Is it possible to
> add the kernel version number to vmlinuz.efi?
>
> https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/blob/master/functions#L209
>

The current header doesn't have that so I don't think EFI zboot should
be adding it either.

Re: [PATCH v2 2/2] efi: Put Linux specific magic number in the DOS header

[Xiaotian Wu]

在 2022-12-07星期三的 09:06 +0100，Ard Biesheuvel写道：
> On Wed, 7 Dec 2022 at 08:51, Xiaotian Wu <wuxiaotian@loongson.cn>
> wrote:
> > 
> > 在 2022-11-29星期二的 18:56 +0100，Ard Biesheuvel写道：
> > > 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
> > > 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
> > > 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
> > > + * 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" */
> > 
> > 
> > As far as I know, Archlinux automatically generates initramfs
> > according
> > to the version number in the kernel file. The latest generic
> > compressed
> > EFI designs do not seem to provide kernel version number
> > information.
> 
> No, but nor do the gzip'ed images arm64 uses today, and the script
> seems take care of that.
> 
> The EFI zboot image has metadata in the header, so the script can
> decompress it and grep for the version number it it needs to.

I tested it, and the decompression can be completed, thank you.
> 
> > This may change the usage habits of Archlinux users. Is it possible
> > to
> > add the kernel version number to vmlinuz.efi?
> > 
> > https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/blob/master/functions#L209
> > 
> 
> The current header doesn't have that so I don't think EFI zboot
> should
> be adding it either.
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

-- 
Best Regards
Xiaotian Wu

Re: [PATCH v2 2/2] efi: Put Linux specific magic number in the DOS header

[Ard Biesheuvel]

On Wed, 7 Dec 2022 at 11:36, Xiaotian Wu <wuxiaotian@loongson.cn> wrote:
>
> 在 2022-12-07星期三的 09:06 +0100，Ard Biesheuvel写道：
> > On Wed, 7 Dec 2022 at 08:51, Xiaotian Wu <wuxiaotian@loongson.cn>
> > wrote:
> > >
> > > 在 2022-11-29星期二的 18:56 +0100，Ard Biesheuvel写道：
> > > > 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
> > > > 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
> > > > 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
> > > > + * 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" */
> > >
> > >
> > > As far as I know, Archlinux automatically generates initramfs
> > > according
> > > to the version number in the kernel file. The latest generic
> > > compressed
> > > EFI designs do not seem to provide kernel version number
> > > information.
> >
> > No, but nor do the gzip'ed images arm64 uses today, and the script
> > seems take care of that.
> >
> > The EFI zboot image has metadata in the header, so the script can
> > decompress it and grep for the version number it it needs to.
>
> I tested it, and the decompression can be completed, thank you.

Excellent! Thanks for confirming.