On Mon Sep 18, 2023 at 6:41 PM EEST, Dimitri John Ledkov wrote: > 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 OK this does make a lot of sense. > 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. Right UKI wraps kernel and kernel is a "leaf object". > 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). ok > 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 _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
