Hi,
So this boots in my test environments, but has the usual set of issues
around various user-space utilities not recognizing it.
A couple things to think about:
Should the PE header 'zimg' type (or something else in the header) be
tweaked so that the payload PE vs ELF can be detected before the image
is decompressed? Right now for example, kexec-tools decompresses the
image and then tosses it because the resulting decompressed image isn't
understood as a loadable kernel. This is a trivial fix, but if in the
future the plan is to be able to load these images directly by
kexec_file_load() ideally kexec would know this before it attempts to
decompress the image.
I think this needs a Kconfig entry to enable/disable it until all the
userspace tools have been updated.
Thanks!
On 12/18/24 9:03 AM, Ard Biesheuvel wrote:
From: Ard Biesheuvel <ardb@xxxxxxxxxx>
The EFI zboot image format was introduced to provide a way to distribute
an EFI bootable image for architectures such as arm64, RISC-V and
Loongarch supporting both compression and EFI secure boot signing.
To make this format easy to digest for other consumers than EFI firmware
(e.g., qemu or kexec), the file header describes the compression type
and the offset and size of the compressed image inside the file.
Additional metadata of the payload is currently injected using ELF
symbols (currently, the size of the executable image's code region on
arm64), but this information is not accessible to other consumers unless
it is exposed either via the header, or via the payload itself.
It would be better to have a structured format inside the container, so
that any annotation can be added without the need to tweak the EFI zboot
header layout. On x86, the legacy decompressor encapsulates an ELF
image, so that ELF notes can be used for arbitrary metadata, and this
is heavily used by Xen.
Let's implement something similar for the generic EFI zboot format. This
removes the need for per-arch hacks to inject symbols, and makes a
future alignment of EFI zboot with x86 more feasible as well.
So switch to the ELF format for the EFI zboot payload, but implement it
in such a way that decompressing the entire ELF image is unnecessary.
Instead, decompress the ELF file header and program headers first, and
discard any file data that is not covered by a PT_LOAD program header
(and therefore not part of the executable's memory image).
The latter approach permits EFI zboot to be used with unstripped ELF
binaries, making EFI zboot suitable for future use as a hybrid bootable
image and debug symbol library for the running kernel.
Cc: Jeremy Linton <jeremy.linton@xxxxxxx>
Cc: Gerd Hoffmann <kraxel@xxxxxxxxxx>
Cc: Pingfan Liu <piliu@xxxxxxxxxx>
Cc: Dave Young <dyoung@xxxxxxxxxx>
Cc: Catalin Marinas <catalin.marinas@xxxxxxx>
Cc: Will Deacon <will@xxxxxxxxxx>
Cc: Mark Rutland <mark.rutland@xxxxxxx>
Cc: Kees Cook <kees@xxxxxxxxxx>
Ard Biesheuvel (4):
efi/libstub: Avoid legacy decompressor zlib/zstd wrappers
efi/zboot: Add support for ELF payloads
arm64/boot: Populate vmlinux ELF program headers
efi/arm64: Use ELF payload for EFI zboot
arch/arm64/boot/Makefile | 4 -
arch/arm64/include/asm/efi.h | 2 +-
arch/arm64/kernel/image-vars.h | 4 -
arch/arm64/kernel/vmlinux.lds.S | 33 ++--
drivers/firmware/efi/libstub/Makefile | 9 +-
drivers/firmware/efi/libstub/Makefile.zboot | 6 +
drivers/firmware/efi/libstub/arm64-stub.c | 2 +-
drivers/firmware/efi/libstub/arm64.c | 20 +--
drivers/firmware/efi/libstub/efistub.h | 9 ++
drivers/firmware/efi/libstub/zboot-decompress-gzip.c | 77 ++++++++++
drivers/firmware/efi/libstub/zboot-decompress-zstd.c | 91 +++++++++++
drivers/firmware/efi/libstub/zboot-decompress.c | 161 ++++++++++++++++++++
drivers/firmware/efi/libstub/zboot.c | 58 ++-----
drivers/firmware/efi/libstub/zboot.lds | 7 +-
14 files changed, 391 insertions(+), 92 deletions(-)
create mode 100644 drivers/firmware/efi/libstub/zboot-decompress-gzip.c
create mode 100644 drivers/firmware/efi/libstub/zboot-decompress-zstd.c
create mode 100644 drivers/firmware/efi/libstub/zboot-decompress.c
base-commit: 78d4f34e2115b517bcbfe7ec0d018bbbb6f9b0b8
