From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from blyat.fensystems.co.uk (blyat.fensystems.co.uk [54.246.183.96]) by mx.groups.io with SMTP id smtpd.web09.22579.1622979583667570044 for ; Sun, 06 Jun 2021 04:39:44 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: ipxe.org, ip: 54.246.183.96, mailfrom: mcb30@ipxe.org) Received: from dolphin.home (unknown [IPv6:2a00:23c6:5495:5e00:72b3:d5ff:feb1:e101]) by blyat.fensystems.co.uk (Postfix) with ESMTPSA id 9F36440F27; Sun, 6 Jun 2021 11:39:39 +0000 (UTC) Subject: Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF To: devel@edk2.groups.io, min.m.xu@intel.com, "lersek@redhat.com" , "Yao, Jiewen" , "rfc@edk2.groups.io" Cc: "jejb@linux.ibm.com" , Brijesh Singh , Tom Lendacky , "erdemaktas@google.com" , "cho@microsoft.com" , "bret.barkelew@microsoft.com" , Jon Lange , Karen Noel , Paolo Bonzini , Nathaniel McCallum , "Dr. David Alan Gilbert" , "Ademar de Souza Reis Jr." References: From: "Michael Brown" Message-ID: <830485db-3210-54c0-8dda-893a5850b6c4@ipxe.org> Date: Sun, 6 Jun 2021 12:39:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on blyat.fensystems.co.uk Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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