Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF

["Michael Brown" <mcb30@ipxe.org>]

On 06/06/2021 09:52, Min Xu wrote:
> On June 4, 2021 12:12 AM, Laszlo wrote:
>> (18) says "SMM is not supported in Td guest" -- how is the variable store
>> protected from direct hardware (pflash) access from the guest OS?
>> Without SMM, the guest OS need not go through gRT->SetVariable() to
>> update authenticated non-volatile UEFI variables, and that undermines
>> Secure Boot.
>>
> Let me explain the SMM and Secure boot in TDX like below:
> 1) TDX doesn't support virtual SMM in guest. Virtual SMI cannot be injected
>       into TD guest.
> 2) SMI/SMM is used to manage variable update to avoid expose Flash direct.
>      So SMM is not must-to-have for secure boot, but help to mitigate the security risk.
> 3) We don't trust VMM. That is why we need TDX.
> 4) If you trust VMM to emulate SMM, then you don't need TDX.

Secure Boot defines a security boundary between the firmware and the 
operating system: the operating system is not permitted to make 
arbitrary changes to firmware variables.

It sounds as though you have decided that the TDX security properties 
remove the need for the Secure Boot security properties.  That would be 
a viable conclusion: if the user is able to verify that the intended 
workload is running in the VM (and the VM is disposable anyway) then 
there is not much value added by also having Secure Boot.

However, it's not valid to pretend to also include Secure Boot, knowing 
that there is no way to actually provide the security properties of 
Secure Boot.

If TDX can't support SMM (or some equivalent way for the guest 
*firmware* to guarantee that the ring 0 guest OS cannot make arbitrary 
changes to UEFI variables), then TDX cannot support Secure Boot.

Thanks,

Michael