Open Stack

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