Why do you say that it would have to be a deprivileged kernel context though? In lockdown mode we would enforce a signature check on the PE file, so it shouldn't be any different from loading a signed kernel module from a kernel lockdown perspective, right? Using KVM is actually something I didn't consider yet, however it would not work in VMs without nested virtualization. > The advantage of this approach is that the whole concept of purgatory > can be avoided - the EFI boot phase runs in parallel with the previous > kernel, which has full control over authentication and [emulated] PCR > externsion, and has ultimate control over whether the kexec reboot is > permitted. I'm under the impression that we still need some code to run between the kernels to do two things: 1. Clean up the address space, so that it's what the EFI binary expects 2. Verify a checksum on the saved state in case a kernel panic is the result of memory corruption Sure, the majority of the work (running the EFI binary until EBS()) is done while the old kernel is still running. > > [...] > > I don't think intermediate kernels are the solution here. We need to > run as much as possible under the control of the preceding kernel, and > minimize the bare metal handover that occurs after EBS(). Adding more > code to the purgatory (as this series does) is not acceptable to me, > as it is extremely difficult to debug, and duplicates drivers and > other logic (making it an 'intermediate kernel' of sorts already) I agree > > Today, UKI functionality is implemented in terms of EFI API calls. Any > solution that needs either a parallel implementation (eBPF vs EFI) or > needs to unpack the UKI in order to perform the steps that the UKI > would perform itself if it were executed in an EFI environment is a > no-go in my opinion. > > So either we provide some EFI compatible runtime sufficient to run a > UKI, or we re-engineer UKI to be built on top of an abstraction that > can be implemented straight-forwardly both on system firmware and in > the EFI context. A solution that can boot UKIs as they exist today is definetly the right choice. Rewriting them for eBPF and maintaining two implementations is way less than ideal.
