On 01/07/21 18:26, James Bottomley wrote:
On Thu, 2021-01-07 at 11:50 +0100, Laszlo Ersek wrote:
(Adding James, David, Daniel)
Thanks. I'm missing a lot of context, so I'll try to answer the SEV case only. Except I will remark that if you boot without a separate vars and code OVMF, then you need the combined OVMF.fd which contains a non modifiable initial variable store
(If the guest owner provides a unified firmware image, including the executable and "static" (= pre-set) variable store, that's not a problem for the Kata use case per se, IIUC; Kata doesn't care about varstore longevity / permanence anyway. But, this is less important, let's continue below.)
[...]
Now, with SEV, Secure Boot gains *further* usefulness, but relatedly, it faces a new problem as well. Above, I mention "option ROM verification".
Actually, I'm not sure about this; I don't believe secure boot adds any real value and it introduces a problem: the current proposal has the grub component verified by hash and the kernel verified by being on the encrypted partition so there's no real additional security secure boot can provide.
Well, "OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c" still contains a call to EfiBootManagerDispatchDeferredImages(), at which point any option ROMs placed by QEMU in the PCI devices' ROM BARs will be executed. If we don't want that *ever*, in the remote attested boot platform, then we should likely remove this call. (Cf. commit 0f9395d7c5cc ("ArmPkg: Dispatch deferred images after EndOfDxe", 2019-12-05).) This "image deferral" is outlined in commit 8be37a5cee70 ("MdeModulePkg/SecurityStubDxe: Defer 3rd party image before EndOfDxe", 2016-11-10). The point of the feature is that, even if a 3rd party UEFI driver is properly signed, it should not be launched immediately when found in a PCI option ROM, that is, before "End of DXE" is reached. "End of DXE" is more or less when the platform locks itself down (= more or less when SMRAM gets closed and locked, for example), after everything has been dispatched from the firmware volume(s) -- so even "trusted" 3rd party drivers are not allowed to launch before that point. If we don't permit 3rd party UEFI binaries at all (incl. UEFI drivers in option ROMs) on the remote attested firmware platform, then the EfiBootManagerDispatchDeferredImages() call should be removed from this platform's BDS Library instance. In that case, a warning will be emitted to the firmware log during boot (about some deferred images left un-dispatched), but there should not be any ill effects. And then I do agree that SB may be considered an unnecessary complication. Thanks for following up! Laszlo
The problem is that if you provide the vars fd, it doesn't get attested, so effectively its a licence for the host owner to muck with your OVMF configuration which also isn't good for security and finally, as you discus below, SEV doesn't use SMI which means the vars fd doesn't operate safely.
James