Hi Dave, Thanks for your suggestion. Please see the comment inlined. On Wed, Mar 22, 2023 at 11:44:52AM +0800, Dave Young wrote: > On Fri, 10 Mar 2023 at 12:18, Pingfan Liu <kernelfans@xxxxxxxxx> wrote: > > > > On Tue, Mar 07, 2023 at 04:08:55PM +0800, Pingfan Liu wrote: > > > Hi Ard, > > > > > > Thanks for sharing your idea. Please see the comment. > > > > > > On Mon, Mar 06, 2023 at 09:08:03AM +0100, Ard Biesheuvel wrote: > > > > (cc Mark) > > > > > > > > Hello Pingfan, > > > > > > > > Thanks for working on this. > > > > > > > > On Mon, 6 Mar 2023 at 04:03, Pingfan Liu <kernelfans@xxxxxxxxx> 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 > > > > > > The idea of the minimal environment lools amazing. After digging > > > more deeply into it, I think it means to implement most of the function > > > members in efi_boot_services, besides that, some UEFI protocols due to > > > the reference of efi_call_proto(). So a clear boundary between zboot and > > > its dependent EFI service is demanded before the work. > > > > > > > Looking deeper into it. This approach may be splitted into the following > > chunks: > > -1. Estimation the memory demanded by the decompression of zboot, which > > roughly includes the size of Image, the size of the emulated service and > > the stack used by zboot. Finally we need a kexec_add_buffer() for this > > range. > > > > -2. The emulated EFI services and some initial data such as the physical > > address of dtb, the usable memory start address and size should be set > > by kexec_purgatory_get_set_symbol() > > > > -3. Set up an identity mapping of the usable memory by zboot, prepare > > stack and turn on MMU at the last point just before 'br efi_zboot_entry' > > in relocate_kernel.S, which means relocate_kernel.S should support two > > kinds of payload. > > > > -4. For efi_zboot_entry(), if jumping from kexec, limit its requirement > > to only a few boot services: e.g. allocate_pages, allocate_pool. So the > > emulated services can be deduced. > > Hi Pingfan, > > I'm not sure how hard it will be although Ard thinks it could be > doable. If it is not easy I suspect it is not worth the effort. > Yes, it is a little hard comparing to the original patch. But I am also trying in that direction. > For your current series, my suggestion is you can try to move the > major code in the generic code path in kernel/kexec_file.c and keep > the arch code minimum so that in the future other arches can avoid > redundant code. > OK. I will do it. > Otherwise a fallback solution could be using the same key to sign both > the zboot image and the internal kernel image like below: > 1. sign the kernel with the same key twice (kernel image and zboot > image) in distro kernel > 2. introduce a kconfig in mainline to sign the kernel image with an > ephemeral key same to kernel modules. Distro can disable the config > option. (in this way kexec can only load the same kernel, it is not > useful if people want to load older/newer kernels) > 3. patch kexec-tools to decompress the zboot image and load the kernel image > Yes, this is also a doable way. I will try it if more votes for it. Thanks, Pingfan > > > > > > kernel up to the point where it call ExitBootServices(), after which > > > > kexec() would take over. > > > > > > > > > > IIUC, after kexec switches to efi_zboot_entry(), it will not return, > > > right? > > > > > > > I have this assumption because letting the control path switch between > > kernel and non-kernel code is not a good idea. > > > > > > Thanks, > > > > Pingfan > > > > > > > -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. > > > > > > > > > > Ah, thanks for the correcting. I had made an wrong assumption of grub > > > based on [1], from which, I thought that grub is the case "For > > > compatibility with non-EFI loaders, the payload can be decompressed and > > > executed by the loader as well, provided that the loader implements the > > > decompression algorithm and that non-EFI boot is supported by the > > > encapsulated image" > > > > > > > > > [1]: https://www.phoronix.com/news/Linux-6.1-Generic-EFI-Zboot > > > > > > > > > Eager to find a solution to kexec a zboot image. Hope it will come soon. > > > > > > > > > Thanks, > > > > > > Pingfan > > > > > 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@xxxxxxx> > > > > > Cc: Will Deacon <will@xxxxxxxxxx> > > > > > Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > > > > > Cc: Ard Biesheuvel <ardb@xxxxxxxxxx> > > > > > Cc: kexec@xxxxxxxxxxxxxxxxxxx > > > > > To: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > > > > > To: linux-kernel@xxxxxxxxxxxxxxx > > > > > > > > > > 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 > > > > > > > > > _______________________________________________ > > kexec mailing list > > kexec@xxxxxxxxxxxxxxxxxxx > > http://lists.infradead.org/mailman/listinfo/kexec > > > _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
