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]. 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@xxxxxxxx/T/ Added some more CCs.
