[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMj1kXGmjVvNXk6QJON_Tb+ya6WAm6GrHm6=GD0K23rm+7uDNA@mail.gmail.com>
Date: Mon, 6 Mar 2023 09:08:03 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Pingfan Liu <kernelfans@...il.com>,
Mark Rutland <mark.rutland@....com>
Cc: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
kexec@...ts.infradead.org
Subject: Re: [PATCH 0/6] arm64: make kexec_file able to load zboot image
(cc Mark)
Hello Pingfan,
Thanks for working on this.
On Mon, 6 Mar 2023 at 04:03, Pingfan Liu <kernelfans@...il.com> wrote:
>
> After introducing zboot image, kexec_file can not load and jump to the
> new style image. Hence it demands a method to load the new kernel.
>
> The crux of the problem lies in when and how to decompress the Image.gz.
> There are three possible courses to take: -1. in user space, but hard to
> achieve due to the signature verification inside the kernel.
That depends. The EFI zboot image encapsulates another PE/COFF image,
which could be signed as well.
So there are at least three other options here:
- sign the encapsulated image with the same key as the zboot image
- sign the encapsulated image with a key that is only valid for kexec boot
- sign the encapsulated image with an ephemeral key that is only valid
for a kexec'ing an image that was produced by the same kernel build
> -2. at the
> boot time, let the efi_zboot_entry() handles it, which means a simulated
> EFI service should be provided to that entry, especially about how to be
> aware of the memory layout.
This is actually an idea I intend to explore: with the EFI runtime
services regions mapped 1:1, it wouldn't be too hard to implement a
minimal environment that can run the zboot image under the previous
kernel up to the point where it call ExitBootServices(), after which
kexec() would take over.
> -3. in kernel space, during the file load
> of the zboot image. At that point, the kernel masters the whole memory
> information, and easily allocates a suitable memory for the decompressed
> kernel image. (I think this is similar to what grub does today).
>
GRUB just calls LoadImage(), and the decompression code runs in the EFI context.
> The core of this series is [5/6]. [3,6/6] handles the config option.
> The assumption of [3/6] is kexec_file_load is independent of zboot,
> especially it can load kernel images compressed with different
> compression method. [6/6] is if EFI_ZBOOT, the corresponding
> decompression method should be included.
>
>
> Cc: Catalin Marinas <catalin.marinas@....com>
> Cc: Will Deacon <will@...nel.org>
> Cc: Andrew Morton <akpm@...ux-foundation.org>
> Cc: Ard Biesheuvel <ardb@...nel.org>
> Cc: kexec@...ts.infradead.org
> To: linux-arm-kernel@...ts.infradead.org
> To: linux-kernel@...r.kernel.org
>
> Pingfan Liu (6):
> arm64: kexec: Rename kexec_image.c to kexec_raw_image.c
> lib/decompress: Introduce decompress_method_by_name()
> arm64: Kconfig: Pick decompressing method for kexec file load
> lib/decompress: Keep decompress routines based on selection
> arm64: kexec: Introduce zboot image loader
> init/Kconfig: Select decompressing method if compressing kernel
>
> arch/arm64/Kconfig | 59 ++++++
> arch/arm64/include/asm/kexec.h | 4 +-
> arch/arm64/kernel/Makefile | 2 +-
> .../{kexec_image.c => kexec_raw_image.c} | 2 +-
> arch/arm64/kernel/kexec_zboot_image.c | 186 ++++++++++++++++++
> arch/arm64/kernel/machine_kexec.c | 1 +
> arch/arm64/kernel/machine_kexec_file.c | 3 +-
> include/linux/decompress/generic.h | 2 +
> include/linux/decompress/mm.h | 9 +-
> include/linux/zboot.h | 26 +++
> init/Kconfig | 7 +
> lib/Kconfig | 3 +
> lib/decompress.c | 17 +-
> 13 files changed, 314 insertions(+), 7 deletions(-)
> rename arch/arm64/kernel/{kexec_image.c => kexec_raw_image.c} (98%)
> create mode 100644 arch/arm64/kernel/kexec_zboot_image.c
> create mode 100644 include/linux/zboot.h
>
> --
> 2.31.1
>
Powered by blists - more mailing lists