在 2022-12-07星期三的 09:06 +0100，Ard Biesheuvel写道： > On Wed, 7 Dec 2022 at 08:51, Xiaotian Wu <wuxiaotian@xxxxxxxxxxx> > 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@xxxxxxxxxx> > > > Cc: Atish Patra <atishp@xxxxxxxxxxxx> > > > Cc: Heinrich Schuchardt <heinrich.schuchardt@xxxxxxxxxxxxx> > > > Cc: Daniel Kiper <daniel.kiper@xxxxxxxxxx> > > > Cc: Leif Lindholm <quic_llindhol@xxxxxxxxxxx> > > > Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx> > > > --- > > > 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@xxxxxxx > https://lists.gnu.org/mailman/listinfo/grub-devel -- Best Regards Xiaotian Wu
