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

[Pingfan Liu <piliu@redhat.com>]

On Fri, Sep 22, 2023 at 1:19 PM Jan Hendrik Farr <kernel@jfarr.cc> wrote:
>
> 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].
>

Yes, that is my original try.

> 2. Extract in userspace and pass decompressed kernel to kexec_file_load
>
> This option 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.
>

You got it.

> 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

If using my second method, it means to unpack the UKI image in user
space, and pass the kernel image, initrd and cmdline through
kexec_file_load interface. If the UKI can have signature on the initrd
and cmdline, we extend the capability of that interface to check those
verification.

> for the zboot image layout somewhere?
>

Sorry that maybe there is no document. I understand them through the code.
The zboot image, aka, vmlinuz.efi looks like:
PE header, which is formed manually in arch/arm64/kernel/head.S
EFI decompressor, which consists of
drivers/firmware/efi/libstub/zboot.c and libstub
Image.gz, which is formed by compressing Image as instructed in Makefile.zboot


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

Yes, I agree. That method is attractive, originally I had a try when
Ard suggested it but there was no clear boundary on which boot service
should be implemented for zboot, so I did not move on along that
direction.

Now, UKI poses another challenge to kexec_file_load, and seems to
require more than zboot. And it appears that Ard's approach is a
silver bullet for that issue.

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

I try to answer part of the questions.

> 1. Is it the right approach? It adds a significant amount of userspace
> API.

My crude assumption: this new stub will replace the purgatory, and I
am not sure whether kexec-tools source tree will accommodate it. It
can be signed and checked during the kexec_file_load.

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

I think the runtime services survive through the kexec process. It is
derived from the real firmware, not related with this stub

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

Besides these questions, I wonder whether a highly configured EDK2 can
be used as the stub (ArmVirtQemuKernel.dsc can be the start point).
But there should be efforts to exclude the drivers which have the MMIO
access. I saw Ard is active in EDK2, maybe that is the reason why he
did not pick up EDK2 to serve the stub.


Thanks,

Pingfan