Re: [PATCH 0/1] x86/kexec: UKI support

["Jarkko Sakkinen" <jarkko@xxxxxxxxxx>]

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