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@xxxxxxxx/ v2: https://lore.kernel.org/lkml/20230911052535.335770-1-kernel@xxxxxxxx/ 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 _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
