Re: [PATCH 1/2] Makefile.zboot: Sign Image before packing into EFI-STUB shell

[Pingfan Liu <piliu@redhat.com>]

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@redhat.com> 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
>