| Message ID | 20241206021000.8953-2-piliu@redhat.com |
|---|---|
| State | New |
| 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: Also cc Jan, Philipp, who are also engaged in related topic (UKI) > (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. > > 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 remember that I sent out a zboot image parser in the kernel to tackle with this signature issue. But that will complicate the kernel image parser, as a result, we defer resolving it, and finally we have it implemented in the user space kexec-tools. The emergence of UKI makes things more complicated. Jan introduced "UKI format parser in linux kernel". For arm64, the UKI support in kernel means that a UKI format parser should be followed by a zboot format parser. So we tried emulator solution instead of parser. ( I have a summary on: https://github.com/rhkdump/kexec_uefi/blob/main/overview.md) But either of the emulator methods have their own drawback: -1.the purgatory-style method has trouble in the hardware scaling. -2.the user space emulator can not ensure the security. (also I think it can not resolve the hardware issue since at that time, it can not alter the hardware status arbitrarily) > 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. > It is always good to keep things simple. But this seems helpless to step around the kexec_file_load issue. > (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) > Although this issue has come full circle, we now have a clear understanding of its solutions' limitations, advantages, and disadvantages. Unlike the forecast of this issue about three years ago, we are now facing real customer pressure. Thanks, Pingfan > -- > Ard.
diff --git a/drivers/firmware/efi/libstub/Makefile.zboot b/drivers/firmware/efi/libstub/Makefile.zboot index 65ffd0b760b2..8852289f80e8 100644 --- a/drivers/firmware/efi/libstub/Makefile.zboot +++ b/drivers/firmware/efi/libstub/Makefile.zboot @@ -4,9 +4,22 @@ # EFI_ZBOOT_PAYLOAD, EFI_ZBOOT_BFD_TARGET, EFI_ZBOOT_MACH_TYPE and # EFI_ZBOOT_FORWARD_CFI +ifeq ($(filter pkcs11:%, $(CONFIG_MODULE_SIG_KEY)),) +sig-key := $(if $(wildcard $(CONFIG_MODULE_SIG_KEY)),,$(srctree)/)$(CONFIG_MODULE_SIG_KEY) +else +sig-key := $(CONFIG_MODULE_SIG_KEY) +endif + quiet_cmd_copy_and_pad = PAD $@ +ifeq ($(CONFIG_KEXEC_SIGN_IMAGE),y) + cmd_copy_and_pad = openssl x509 -in certs/signing_key.x509 -inform DER -outform PEM -out certs/signing_key_cert.pem; \ + sbsign --key "$(sig-key)" --cert certs/signing_key_cert.pem --output $<.signed $<; \ + cp $<.signed $@; \ + truncate -s $$(hexdump -s16 -n4 -e '"%u"' $<) $@ +else cmd_copy_and_pad = cp $< $@; \ truncate -s $$(hexdump -s16 -n4 -e '"%u"' $<) $@ +endif # Pad the file to the size of the uncompressed image in memory, including BSS $(obj)/vmlinux.bin: $(obj)/$(EFI_ZBOOT_PAYLOAD) FORCE
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 key used to sign is the same as module sign key, and the signing tool is sbsign. And the configure macro KEXEC_SIGN_IMAGE will be introduced in the next patch. (Hence actually this patch does not take effect) Signed-off-by: Pingfan Liu <piliu@redhat.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Will Deacon <will@kernel.org> Cc: Masahiro Yamada <masahiroy@kernel.org> To: linux-efi@vger.kernel.org --- drivers/firmware/efi/libstub/Makefile.zboot | 13 +++++++++++++ 1 file changed, 13 insertions(+)