From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from rn-mailsvcp-ppex-lapp45.apple.com (rn-mailsvcp-ppex-lapp45.apple.com [17.179.253.49]) by mx.groups.io with SMTP id smtpd.web10.647.1630524006219043697 for ; Wed, 01 Sep 2021 12:20:06 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=E9pzDSoU; spf=pass (domain: apple.com, ip: 17.179.253.49, mailfrom: afish@apple.com) Received: from pps.filterd (rn-mailsvcp-ppex-lapp45.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp45.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 181JHWj8002370; Wed, 1 Sep 2021 12:20:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=YXy5Tt8OhbNBpMex72USc9c7mN9aUpxOESYw+VHVfwU=; b=E9pzDSoUQAEbNEoOQiNBuMxoCJNtyVsTaFS0eSZQMUwXu+xFkLzJBXswKZ0GzppnahQI oYC/z1+zcpD9okFse9xNaIYaGJyyoKl0NSr6RpdMVM/4d8e3ijq5DKE66ZPRjPJlPz/C TIlqxdNisfgErnhXMqoSSDIn0K5rZA6aMHav/RcQ8FBxctdbJfRjbTeFBVH+Wd0ZM7Zy E8qJG64TVPjQ+y/KbHk75BNB1mMxqI9xq3zJQuwMKrWVQvnlH9SOUxuYMAg1zjRcd06l XjHa6CEu1PL2/Sal3j0Y5OzPYNjVXohcSfYK8xpO1VsL3P+HFCANeRyhlVUpXuD54B06 2Q== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by rn-mailsvcp-ppex-lapp45.rno.apple.com with ESMTP id 3atdxt1bdw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 01 Sep 2021 12:20:03 -0700 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QYR003F6SDFA030@rn-mailsvcp-mta-lapp04.rno.apple.com>; Wed, 01 Sep 2021 12:20:03 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0QYR00Y00ROPEJ00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 01 Sep 2021 12:20:03 -0700 (PDT) X-Va-A: X-Va-T-CD: 745aae7f955e5506e12ddd47e6120989 X-Va-E-CD: fb08368e5831c827fad41dabe25d145a X-Va-R-CD: 7452b59616108f6be96d40c2219898f0 X-Va-CD: 0 X-Va-ID: 07db6feb-287f-4ab5-b357-775a8392d199 X-V-A: X-V-T-CD: 745aae7f955e5506e12ddd47e6120989 X-V-E-CD: fb08368e5831c827fad41dabe25d145a X-V-R-CD: 7452b59616108f6be96d40c2219898f0 X-V-CD: 0 X-V-ID: 59705526-bf67-4793-9854-1122ef727d4f X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.790 definitions=2021-09-01_05:2021-09-01,2021-09-01 signatures=0 Received: from [17.235.62.22] (unknown [17.235.62.22]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QYR003K1SBSAE00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 01 Sep 2021 12:19:06 -0700 (PDT) MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) Subject: Re: [edk2-devel] [PATCH V5 1/2] OvmfPkg: Introduce Tdx BFV/CFV PCDs and PcdOvmfImageSizeInKb From: "Andrew Fish" In-reply-to: <08185e00b379d70f3420e8c099c26ae5d62c18bc.camel@linux.ibm.com> Date: Wed, 01 Sep 2021 12:19:04 -0700 Cc: "Yao, Jiewen" , "Xu, Min M" , Ard Biesheuvel , "kraxel@redhat.com" , Ard Biesheuvel , Jordan Justen , Brijesh Singh , Erdem Aktas , Tom Lendacky Message-id: <269131DD-C918-40F0-81D2-2151C177F407@apple.com> References: <77440edd1e175207dffcaaa052ce26ae71e6c66c.1630289827.git.min.m.xu@intel.com> <20210830070339.u47qq3g7hb4rq3xc@sirius.home.kraxel.org> <20210831051305.dhqvsh4jzqekmjly@sirius.home.kraxel.org> <20210831102120.kh2b6boorxets75j@sirius.home.kraxel.org> <20210901061033.auj6v3nnofmcawxc@sirius.home.kraxel.org> <08185e00b379d70f3420e8c099c26ae5d62c18bc.camel@linux.ibm.com> To: edk2-devel-groups-io , James Bottomley X-Mailer: Apple Mail (2.3654.20.0.2.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.790 definitions=2021-09-01_05:2021-09-01,2021-09-01 signatures=0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable > On Sep 1, 2021, at 9:53 AM, James Bottomley wrote: >=20 > On Wed, 2021-09-01 at 08:59 +0000, Yao, Jiewen wrote: >> Hi Min >> I agree with Gerd and Ard in this case. >>=20 >> It is NOT so obvious that the FTW is produced then consumed in the >> code. What if the attacker prepares some special configuration to >> trigger the FTW process at the first boot, the code will do *read* >> before *write*? That is a potential attack surface. >=20 > It's not just that: even if you can ensure nothing in the host changed > the variables, how do you know *your* code inside the guest is updating > them? In ordinary OVMF we try to ensure that by having the variables > SMM protected so the only update path available to the kernel is via > the setVariable interface, but we can't do that in the confidential > computing case because SMM isn't supported. That means a random kernel > attacker in the guest can potentially write to the var store too. >=20 > At least for the first SEV prototype I had to make the var store part > of the first firmware volume firstly so it got measured but secondly so > it couldn't be used as a source of configuration attacks. >=20 > I have a nasty feeling that configuration attacks are going to be the > bane of all confidential computing solutions because they give the > untrusted VMM a wide attack surface. >=20 James, If we take a big step back the requirement for an EFI Runtime Service, like= the variable API, is just exclusive access to hardware at OS runtime. The = variable store needs to be on a hardware device that has a persistent relia= ble store. The FTW is really about maintaining the consistency of the store= if the power gets yanked at the wrong moment. So the fact that the UEFI Va= riable Store is in NOR FLASH is a historical artifact more than architectur= e. Also on physical devices hardware cost money, and you need the NOR FLASH= for the firmware so why change it. Thus conceptually the variable store co= uld be backed by a virtual hardware device that was designed with security = in mind. Maybe more of message passing interface and the reliability of upd= ates is maintained by the hardware device not the UEFI code. It would also = be possible for the hardware device to enforce security policy. You could e= ven have EFI send a one shot message per 1st boot to the hardware to define= a security policy. If you wanted the hardware device could even implement = the UEFI Secure Boot infrastructure so the UEFI Variable Driver could be un= trusted. I guess this hypothetical variable store virtual hardware device c= ould also have hardware access to other security hardware resources (like a= TPM) and implement security policies based on that.=20 FYI on Macs with a T2 (security chip) the UEFI variable store lives on the = T2.=20 Thanks, Andrew Fish > James >=20 >=20 >=20 >=20 >=20 >=20 >=20