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.web08.62.1622818367797706608 for ; Fri, 04 Jun 2021 07:52:49 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: ipxe.org, ip: 54.246.183.96, mailfrom: mcb30@ipxe.org) Received: from pudding.home (unknown [213.205.240.106]) by blyat.fensystems.co.uk (Postfix) with ESMTPSA id 7269544193; Fri, 4 Jun 2021 14:52:43 +0000 (UTC) Subject: Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF From: "Michael Brown" To: devel@edk2.groups.io, 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: <8bef0eb1-6e8f-83a7-3513-23ec59f56cde@ipxe.org> Message-ID: Date: Fri, 4 Jun 2021 15:52:42 +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: <8bef0eb1-6e8f-83a7-3513-23ec59f56cde@ipxe.org> 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: quoted-printable On 04/06/2021 11:43, Michael Brown wrote: > On 04/06/2021 11:11, Laszlo Ersek wrote: >> And, to reiterate, just because Confidential Computing is the >> new hot thing, the use cases for OvmfPkgIa32, OvmfPkgIa32X64, OvmfPkgX= 64 >> do not disappear. Regressing them, or making them unmaintainable due t= o >> skyrocketing complexity, is not acceptable. >=20 > Totally agree with this.=C2=A0 Confidential Computing is a very niche u= se=20 > case, and there is no justification for exploding the complexity of the= =20 > standard OVMF build. >=20 > If, several years from now, it ever reaches the point that the majority= =20 > of real-world workloads are using TDX, then there would be an argument=20 > that the complexity cost has to be paid and that the standard OVMF buil= d=20 > should include TDX features.=C2=A0 But that's several years away and ma= y=20 > never happen. Out of interest: does Intel TDX provide any security benefits beyond the=20 (much simpler) Intel SGX? As far as I can tell from the various papers, the fundamental difference=20 between TDX and SGX seems to be that TDX deliberately increases the=20 attack surface from "just the application code" to "entire guest VM,=20 including OS kernel, runtime libraries, etc". Increasing the attack=20 surface while adding complexity is a huge cost so I'm assuming that=20 there must be some commensurate benefit, but nothing in the=20 documentation I've seen seems to describe what this benefit actually is. Thanks, Michael