[PATCH 0/2] Kexec: Sign Image before packing into EFI STUB

[PATCH 0/2] Kexec: Sign Image before packing into EFI STUB

[Pingfan Liu]

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.

Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: Masahiro Yamada <masahiroy@kernel.org>   
Cc: Baoquan He <bhe@redhat.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Eric Biederman <ebiederm@xmission.com>
To: kexec@lists.infradead.org
To: linux-efi@vger.kernel.org


Pingfan Liu (2):
  Makefile.zboot: Sign Image before packing into EFI-STUB shell
  kexec: Introduce KEXEC_SIGN_IMAGE config option

 drivers/firmware/efi/libstub/Makefile.zboot | 13 +++++++++++++
 kernel/Kconfig.kexec                        |  9 +++++++++
 2 files changed, 22 insertions(+)

-- 
2.41.0

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

[Pingfan Liu]

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(+)

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

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

[Ard Biesheuvel]

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

(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)

-- 
Ard.

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

[Gerd Hoffmann]

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

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

[Ard Biesheuvel]

On Fri, 6 Dec 2024 at 10:24, Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> On Fri, Dec 06, 2024 at 09:03:30AM +0100, Ard Biesheuvel wrote:
> > (cc Peter, Gerd)
> >
...
> > 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.
>

GZIP + ZSTD seems like a reasonable compromise to me - AIUI, xz offers
a marginal improvement in compression ratio but it is substantially
slower at decompression time.

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

[Pingfan Liu]

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
> 

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

[Dave Young]

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

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

[Pingfan Liu]

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.