On Fri, Sep 22, 2023 at 1:19 PM Jan Hendrik Farr <kernel@xxxxxxxx> wrote: > > Hi Pingfan! > > On 21 21:37:01, Pingfan Liu wrote: > > From: Pingfan Liu <piliu@xxxxxxxxxx> > > > > > 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 _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
