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@xxxxxxxxxx> 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@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 */ Sadly one more thing... :-( s/0x20 ~ 0x38 reserved/0x20 ~ 0x37 reserved/ Daniel
