From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by mx.groups.io with SMTP id smtpd.web09.263.1622819067315394347 for ; Fri, 04 Jun 2021 08:04:28 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=okeFzm82; spf=pass (domain: linux.ibm.com, ip: 148.163.158.5, mailfrom: jejb@linux.ibm.com) Received: from pps.filterd (m0127361.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 154F4EAO133095; Fri, 4 Jun 2021 11:04:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : subject : from : reply-to : to : cc : date : in-reply-to : references : content-type : mime-version : content-transfer-encoding; s=pp1; bh=S51sXVAbTnb/5FzADDfdwA5D1+VRVVa7ZLWiTyjEcI4=; b=okeFzm82ZJjl/2xlOzazuVQEE7D3WmgFi9R/52K/tvRIUDaIhil+zXs3eA81gd5CiYf8 2svVDivbkPvBTovaS87vbU2TPhnxObWSSC7XQ7m7BNXJuVuyl/rgLM4r8w3lF9ktIb87 qMmx/ClFsDkirHzXLSmBq7M6cyzFiAuqkoYO5hVE0ONw6OAk6ZwpKz/d2/m1vxWWJGWl 25MDXL1ZmZsZxL+Anc4/cSe4GWMYiMICSlUiySHdYiocgAFdI0J5YcQJLLZQZs5slkvP EJd97wNtZWq34/xL1aNmS38M4zsVs9ElkrTfHxNSgrShoS29/JfliXGp0MUjiuFqHGKm EQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 38ynkesqa2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 04 Jun 2021 11:04:23 -0400 Received: from m0127361.ppops.net (m0127361.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 154F4M0M135576; Fri, 4 Jun 2021 11:04:23 -0400 Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0a-001b2d01.pphosted.com with ESMTP id 38ynkesq9d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 04 Jun 2021 11:04:22 -0400 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 154F2qZE010139; Fri, 4 Jun 2021 15:04:21 GMT Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by ppma01dal.us.ibm.com with ESMTP id 38ud8ad2y7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 04 Jun 2021 15:04:21 +0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 154F4KGa18612490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 4 Jun 2021 15:04:20 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4F1B97805F; Fri, 4 Jun 2021 15:04:20 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B4D917806B; Fri, 4 Jun 2021 15:04:17 +0000 (GMT) Received: from jarvis.int.hansenpartnership.com (unknown [9.85.146.92]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Fri, 4 Jun 2021 15:04:17 +0000 (GMT) Message-ID: <3014a3275fa2a99de4fb34ca81f45d27b1bcd802.camel@linux.ibm.com> Subject: Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF From: "James Bottomley" Reply-To: jejb@linux.ibm.com To: Michael Brown , devel@edk2.groups.io, lersek@redhat.com, "Yao, Jiewen" , "rfc@edk2.groups.io" Cc: 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." Date: Fri, 04 Jun 2021 08:04:16 -0700 In-Reply-To: References: <8bef0eb1-6e8f-83a7-3513-23ec59f56cde@ipxe.org> User-Agent: Evolution 3.34.4 MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-Proofpoint-GUID: Edfg8X9WV4PhZeBiwWMb593vRXNIM9gL X-Proofpoint-ORIG-GUID: zJ7rk30J5Q37Qn7mmulPuF53hNSqFvbo X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-06-04_08:2021-06-04,2021-06-04 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 suspectscore=0 lowpriorityscore=0 malwarescore=0 adultscore=0 mlxlogscore=999 impostorscore=0 spamscore=0 priorityscore=1501 clxscore=1011 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106040112 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Fri, 2021-06-04 at 15:52 +0100, Michael Brown wrote: > 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, > > > OvmfPkgX64 do not disappear. Regressing them, or making them > > > unmaintainable due to skyrocketing complexity, is not acceptable. > > > > Totally agree with this. Confidential Computing is a very niche > > use case, and there is no justification for exploding the > > complexity of the standard OVMF build. > > > > If, several years from now, it ever reaches the point that the > > majority of real-world workloads are using TDX, then there would be > > an argument that the complexity cost has to be paid and that the > > standard OVMF build should include TDX features. But that's > > several years away and may never happen. > > Out of interest: does Intel TDX provide any security benefits beyond > the (much simpler) Intel SGX? The main benefit is ease of deployment for unmodified applications. While you might argue this isn't a "security" benefit, remember that any security technology that is too complex for most people to deploy doesn't have much impact, so ease of use is a significant consideration in security technologies. > As far as I can tell from the various papers, the fundamental > difference between TDX and SGX seems to be that TDX deliberately > increases the attack surface from "just the application code" to > "entire guest VM, including OS kernel, runtime libraries, > etc". Increasing the attack surface while adding complexity is a > huge cost so I'm assuming that there must be some commensurate > benefit, but nothing in the documentation I've seen seems to describe > what this benefit actually is. The big problems of enclave technology like SGX is rewriting applications into secure and insecure parts and controlling information leak across the boundaries of the enclave ... even if you opt to run the application entirely within the enclave, you still get leaks into the kernel via syscalls and the machine owner still has a huge amount of leeway to exfiltrate any secrets in the enclave. The push towards VM based isolation is because all the handling of the technology can be done inside an enlightened guest kernel (so any application will run with no modification) and the guest to host boundary is a far easier to analyse being a hardware emulation vmexit/hypercall one rather than the huge and complex syscall interface. James