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

[Dimitri John Ledkov]

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