Hi, On Fri, 6 Dec 2024 at 17:24, Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: > > On Fri, Dec 06, 2024 at 09:03:30AM +0100, Ard Biesheuvel wrote: > > (cc Peter, Gerd) > > > > On Fri, 6 Dec 2024 at 03:10, Pingfan Liu <piliu@xxxxxxxxxx> wrote: > > > > > > At present, the kexec_file_load of either zboot or UKI kernel relies on > > > the user space to parse and extract the Image, and then pass the Image > > > through that syscall. During this process, the outmost signature on > > > zboot or UKI kernel is stripped and discarded. > > > > > > On the other hand, a secure boot platform enforces the signature > > > verfiication on the kernel image passed through the kexec_file_load > > > syscall. To cater to this requirement, this patch applies signature on > > > the PE format 'Image' before padding. > > > > The whole point of the EFI zboot format was avoiding the need to sign > > the compressed payload. > > Also note that signing things that way does not work with the usual > distro signing workflows They typically do first the whole build > process, then go sign the final kernel image with a somewhat evolved > process because the signing keys are kept on secure hardware tokens. > > When it comes to UKIs discarding the outmost signature is bad from a > security point of view, because that is the only signature which also > covers the initrd data. > As long as the signature can be verified with a trusted key it should be good, also not everyone uses initrd, a kernel without initrd and with embedded cmdline works just fine. So I would support that for the mainline no need to care too much about UKI format. For the different approaches we already see, it is not possible to have something ready soon in the near future so I would support either Pingfan's solution here or the original patches to uncompress the zboot in kernel code. Thanks Dave
