On Fri, Dec 06, 2024 at 10:24:27AM +0100, Gerd Hoffmann 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. > I beg to differ. This apporoach just reuses signing method used by the kernel module. > 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. > Yes, that is a significant challenge. For UKI, in another rely, I mentioned about the solution of "UKI format parser in linux kernel". This series of approaches is specifically targeted at the zboot format in the absence of a kernel zboot format parser. for zboot format if there is no kernel zboot format parser. (That is the 'kexec-related maintenance nightmare', which Ard mentioned.) In fact, there have been multiple attempts to address the kexec_file_load signature PE issue, but each of these approaches has inherent limitations Thanks, Pingfan > > 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) > > We have 7 meanwhile? Wow. That looks somewhat insane indeed. > > > 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. > > gzip was the only one for a looooong time, so we want probably keep > that. It also is somewhat dated and doesn't offer the best compression > rations, so I do the point in supporting some better alternative. But > can we settle on *one* gzip alternative, reducing the total number from > seven to two? Reasonable choice for the alternative would IMHO be: > > (1) xz - that seems to have established as *the* gzip alternative, > release tarballs are either .gz or .xz these days, everything > else is rather exotic. > > (2) zstd - typical distro kernels need that *anyway* because there > are more in-kernel users, btrfs uses zstd compression for example. > > distro data points: fedora/x64 used gzip in the past and uses zstd > compression today. fedora/aa64 uses gzip for zboot. > > take care, > Gerd >
