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

Michael Brown

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.



Join to automatically receive all group messages.