| Message ID | 20241206021000.8953-1-piliu@redhat.com |
|---|---|
| Headers | show |
| Series | Kexec: Sign Image before packing into EFI STUB | expand |
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. 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
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 >
Hi, On Fri, 6 Dec 2024 at 17:24, Gerd Hoffmann <kraxel@redhat.com> 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. > > 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