[RFCv2 0/9] UEFI emulator for kexec

[Jan Hendrik Farr]

Hi Dave,

> I forgot why we can not just extract the kernel from UKI and then load
> it directly,  if the embedded kernel is also signed it should be good?

The problem is that in the basic usecase for UKI you only sign the entire
UKI PE file and not the included kernel, because you only want that kernel
to be run with that one initrd and that one kernel cmdline.

So at a minimum you have to have the signature on the whole UKI checked by
the kernel and than have the kernel extract UKI into its parts unless you
somehow want to extent trust into userspace to have a helper program do that.

That's what my UKI support implementation from last year did.

v1: https://lore.kernel.org/lkml/20230909161851.223627-1-kernel@jfarr.cc/
v2: https://lore.kernel.org/lkml/20230911052535.335770-1-kernel@jfarr.cc/
v3-wip: https://github.com/Cydox/linux/blob/2908db6d8556fa617298cfb713355edaa9e4b095/arch/x86/kernel/kexec-uki.c

It however also lacks support for the "side-car" files. One option to add them
would be to load them using subsequent calls to kexec_file_load with a special
flag maybe.

TPM measurements are also not done although they are way easier to
implement with this approach as we still have the rest of the kernel around.

However TPM measurements in this case would be implemented by the kexec loader
in the kernel not by the UKI deciding what to measure. So we would have to
have a very firm agreement on what to measure.

Going the UEFI emulator route gives the UKI format (and other (future) formats)
way more flexibility. The cost is to potentially implementing a large portion
of the UEFI spec, especially if the goal is to support future unknown formats
which IIRC was one of the reasons this approach was suggested.

Kind regards,
Jan