Re: [PATCH v4 6/9] arm64: efi: enable generic EFI compressed boot

[Jeremy Linton <jeremy.linton@arm.com>]

Hi,


On 8/27/22 03:38, Ard Biesheuvel wrote:
> Wire up the generic EFI zboot support for arm64.

Thanks for this series, its very helpful when using a boot manager that 
isn't grub (ex: systemd-boot, ipxe, etc) since those boot managers have 
the expectation that they are simply executing efi images. Given how 
large some of the uncompressed images get, and having a half dozen of 
them on a machine isn't ideal. So this series solves that problem, as 
well as cleans up some of the less than ideal grubisms that aren't 
needed on !x86 platforms.

So, I've been testing this series with a clean (as in grub/grubby/etc 
was never near the system) systemd-boot, which now works given the fixes 
to the initrd= option. It seems that the resulting boot path is 
noticeably faster as well. Given I've been testing both gziped and 
Lz4'ed images it could just be the latter option is faster, or it could 
be grubs decompressor/load sequence is just slow.

That said, I think there are a couple build tweaks in order. First, I 
would expect that just a normal 'make' (rather than 'make vmlinuz.efi') 
would make the resulting image when ZBOOT is enabled . Then I would 
expect 'make install' (or maybe a new 'make ezinstall?') to pass the new 
compressed efi to the installkernel utility. The install option would 
work without changes if the make pass just renames/creates the resulting 
vmlinuz.efi as Image. So.. there are a bunch of choices here, but my 
assumption is that the ZBOOT changes the resulting image, and the normal 
make/make install sequence just does the right thing.


So, now the fun bit. At the moment my shim->grub->efi-stubbed kernel 
path (which is the default fedora/rhel sequence) appears to be broken if 
I swap the compressed image (not the .gz version) in for a normal 
decompressed kernel. That appears to be a grub bug in fedora at the 
moment, but I've not fully tracked it down.

I was going to test secure boot, but the above problem has temporary 
stalled that, and I'm still cleaning up a few things on the sd-boot side 
(there isn't a shim in the path) before that is a workable testing path 
for anything other than a test signed kernel.


Thanks again for this, its extremely helpful.


> 
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
>   arch/arm64/Makefile      | 4 ++--
>   arch/arm64/boot/Makefile | 6 ++++++
>   2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 6d9d4a58b898..92676ccc6363 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -153,10 +153,10 @@ libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
>   boot		:= arch/arm64/boot
>   KBUILD_IMAGE	:= $(boot)/Image.gz
>   
> -all:	Image.gz
> +all:	$(notdir $(KBUILD_IMAGE))
>   
>   
> -Image: vmlinux
> +Image vmlinuz.efi: vmlinux
>   	$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
>   
>   Image.%: Image
> diff --git a/arch/arm64/boot/Makefile b/arch/arm64/boot/Makefile
> index a0e3dedd2883..c65aee088410 100644
> --- a/arch/arm64/boot/Makefile
> +++ b/arch/arm64/boot/Makefile
> @@ -38,3 +38,9 @@ $(obj)/Image.lzo: $(obj)/Image FORCE
>   
>   $(obj)/Image.zst: $(obj)/Image FORCE
>   	$(call if_changed,zstd)
> +
> +EFI_ZBOOT_PAYLOAD	:= Image
> +EFI_ZBOOT_BFD_TARGET	:= elf64-littleaarch64
> +EFI_ZBOOT_MACH_TYPE	:= ARM64
> +
> +include $(srctree)/drivers/firmware/efi/libstub/Makefile.zboot