(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. Now, we are back to signing the payload along with the full image using PE based tools, even though the payload is intended to be booted as a raw image. I'm not sure I see the point of this: EFI zboot is a trivial container format which records the compression type and the start and length of the payload in its header at a known offset. Perhaps we should just make EFI zboot gzip-only, rather than supporting 7 different compression methods because that is what the legacy decompressors on ARM and x86 support - I struggle to see the point of that tbh (even though I implemented that myself) That way, the kernel can authenticate the outer PE zboot image as usual, and perform the decompression itself, without having to carry code for all compression formats it might encounter. (Apologies if we are sending you in circles, but if we get this wrong now, we're stuck with another kexec-related maintenance nightmare so I really don't want to commit to something tooo hastily) -- Ard.
