On Tue, 12 Sept 2023 at 11:38, Jarkko Sakkinen <jarkko@xxxxxxxxxx> wrote: > > On Tue Sep 12, 2023 at 2:20 AM EEST, Neal Gompa wrote: > On Mon, Sep 11, 2023 at 7:15 PM Jarkko Sakkinen <jarkko@xxxxxxxxxx> wrote: > > > On Sat Sep 9, 2023 at 7:18 PM EEST, Jan Hendrik Farr wrote: > > > > Hello, > > > > > > > > this patch implements UKI support for kexec_file_load. It will require support > > > > in the kexec-tools userspace utility. For testing purposes the following can be used: > > > > https://github.com/Cydox/kexec-test/ > > > > > > > > There has been discussion on this topic in an issue on GitHub that is linked below > > > > for reference. > > > > > > > > > > > > Some links: > > > > - Related discussion: https://github.com/systemd/systemd/issues/28538 > > > > - Documentation of UKIs: https://uapi-group.org/specifications/specs/unified_kernel_image/ > > > > > > > > Jan Hendrik Farr (1): > > > > x86/kexec: UKI support > > > > > > > > arch/x86/include/asm/kexec-uki.h | 7 ++ > > > > arch/x86/include/asm/parse_pefile.h | 32 +++++++ > > > > arch/x86/kernel/Makefile | 2 + > > > > arch/x86/kernel/kexec-uki.c | 113 +++++++++++++++++++++++++ > > > > arch/x86/kernel/machine_kexec_64.c | 2 + > > > > arch/x86/kernel/parse_pefile.c | 110 ++++++++++++++++++++++++ > > > > crypto/asymmetric_keys/mscode_parser.c | 2 +- > > > > crypto/asymmetric_keys/verify_pefile.c | 110 +++--------------------- > > > > crypto/asymmetric_keys/verify_pefile.h | 16 ---- > > > > 9 files changed, 278 insertions(+), 116 deletions(-) > > > > create mode 100644 arch/x86/include/asm/kexec-uki.h > > > > create mode 100644 arch/x86/include/asm/parse_pefile.h > > > > create mode 100644 arch/x86/kernel/kexec-uki.c > > > > create mode 100644 arch/x86/kernel/parse_pefile.c > > > > > > > > -- > > > > 2.40.1 > > > > > > What the heck is UKI? > > > > Unified Kernel Images. More details available here: > > https://uapi-group.org/specifications/specs/unified_kernel_image/ > > > > It's a way of creating initramfs-style images as fully generic, > > reproducible images that can be built server-side. > > You can build today a kernel with these compiled in: > > 1. EFI stub > 2. initeramfs > 3. cmdline > > Why another way (and label 'UKI') for a pre-existing feature? > In Ubuntu, we have considered to use the existing kernel features before going off to use UKI. Here are some of the reasons why we didn't opt to use the kernel builtin things: 1) we wanted to have ability to have TPM measured kernel commandline performed before kernel is being executed, which is what sd-stub provides us 2) we wanted to have ability to update / regenerate initrd, without rebuilding kernel. Thus whenever userspace in the initrd needs updating, we can generate new initrd for existing kernel build, create new kernel.efi, whilst using existing .linux / vmlinuz build. I don't believe it is currently trivial to relink vmlinuz with builtin initrd. 3) licensing wise it was not clear if initrd has to be GPLv2 compatible when linked inside vmlinuz, or if it can contain GPLv3 / LGPLv3 userspace code - with UKI it is believed unambigiously true, because vmlinuz boots by itself standalone and is compiled separately of the UKI. 4) we wanted to have ability to override cmdline via kernel args without secureboot, and use stock cmdline args under secureboot, to allow debugging & production behaviour from a single signed kernel.efi (that was custom development, and could be done in the stock vmlinuz too). 5) obvious mention, the intention here is to have TPM PCR measurements and Secureboot signature for vmlinuz and initrd and cmdline and dtb. There is otherwise no support for standalone signed initrd, cmdline, dtb today. Nor does vendoring it into vmlinuz achieves this to the same extent (and ease of predicting for sealing / resealing purposes). 6) in Ubuntu kernel.efi also has sbat section for targeted revocations (discussed separately elsewhere) Overall, it is mostly about flexibility to be able to reuse the same initrd against multiple kernel builds, or update use multiple initrd against the same kernel build. This is imho the biggest issue with using initrd built-into the vmlinuz itself. Resource wise, the initrd passed in via kernel.efi can be freed, as far as I understand. I don't know if the one built-into the vmlinuz is freeable. Improving design to do something else instead of UKI would be welcomed. Or for example improving the zimg linus upstream format to be a partial or a valid UKI would help as well. For example, building the kernel built-in initrd as a .initrd section that is replacable would be nice, or allowing to preload zimg with .dtb or .cmdline sections would help, and appropriately improve the linux efi stab to do measurements and loading of .dtb / .initrd from itself would be nice. Because then all the benefits / requirements described above could be made available out of the box and be trivially updatable. The biggest one being splitting out things into sections that can be updated with objcopy. > BR, Jarkko -- okurrr, Dimitri _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
