Re: [PATCH 0/2] Sign the Image which is zboot's payload

[Jan Hendrik Farr <kernel@jfarr.cc>]

Hi Pingfan!

On 21 21:37:01, Pingfan Liu wrote:
> From: Pingfan Liu <piliu@redhat.com>
> 

> For security boot, the vmlinuz.efi will be signed so UEFI boot loader
> can check against it. But at present, there is no signature for kexec
> file load, this series makes a signature on the zboot's payload -- Image
> before it is compressed. As a result, the kexec-tools parses and
> decompresses the Image.gz to get the Image, which has signature and can
> be checked against during kexec file load

I missed some of the earlier discussion about this zboot kexec support.
So just let me know if I'm missing something here. You were exploring
these two options in getting this supported:

1. Making kexec_file_load do all the work.

This option makes the signature verification easy. kexec_file_load
checks the signature on the pe file and then extracts it and does the
kexec.

This is similar to how I'm approaching UKI support in [1].

2. Extract in userspace and pass decompressed kernel to kexec_file_load

This options requires the decompressed kernel to have a valid signature on
it. That's why this patch adds the ability to add that signature to the
kernel contained inside the zboot image.

This option would not make sense for UKI support as it would not
validate the signature with respect to the initrd and cmdline that it
contains. Am I correct in thinking that there is no similar issue with
zboot images? They don't contain any more information besides the kernel
that is intended to be securely signed, right? Do you have a reference
for the zboot image layout somewhere?

> I hesitate to post this series, 

I appreciate you sending it, it's helping the discussion along.

> [...] since Ard has recommended using an
> emulated UEFI boot service to resolve the UKI kexec load problem [1].
> since on aarch64, vmlinuz.efi has faced the similar issue at present.
> But anyway, I have a crude outline of it and am sending it out for
> discussion.

The more I'm thinking about it, the more I like Ard's idea. There's now
already two different formats trying to be added to kexec that are
pretty different from each other, yet they both have the UEFI interface
in common. I think if the kernel supported kexec'ing EFI applications
that would be a more flexible and forward-looking approach. It's a
standard that both zboot and UKI as well as all future formats for UEFI
platforms will support anyways. So while it's more work right now to
implement, I think it'll likely pay off.

It is significantly more work than the other options though. So I think
before work is started on it, it would be nice to get some type of
consensus on these things (not an exhaustive list, please feel free to
add to it):

1. Is it the right approach? It adds a significant amount of userspace
API.
2. What subset of the UEFI spec needs/should to be supported?
3. Can we let runtime services still be handled by the firmware after
exiting boot services?
4. How can we debug the stubs that are being invoked?
5. Can we let the EFI binary know that this is a kexec and not a normal
bootup. Potentially systemd-stub would want to change how/if it does TPM
PCR measurements.
...


[1] https://lore.kernel.org/kexec/20230911052535.335770-2-kernel@jfarr.cc/T/

Added some more CCs.