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.
> 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
