From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by mx.groups.io with SMTP id smtpd.web10.717.1630515211290698880 for ; Wed, 01 Sep 2021 09:53:31 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=TNUmhZNX; spf=pass (domain: linux.ibm.com, ip: 148.163.156.1, mailfrom: jejb@linux.ibm.com) Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 181GiaBq160636; Wed, 1 Sep 2021 12:53:29 -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=pQMDnL7LqH/5fs+GbgqH26OCJm9oeuWqpSP7EfgEqeg=; b=TNUmhZNX4G3InM2kLj1TmrNGUuDVpChv1rklNezVw3128wO37oLPmG6QiyAeKPTR2767 t0CrByA1H4965cAbfDsjuO8ZQ9zOk+h0cnH2xK9vQFebuEfHtrB+2YXMm97ZnEaPeqND Sqyja+Ge1ENvPLrzEuvEvzseNOqeRumzKwvDIK7vEdGu3x9M4CQG250veaCQAPVUIOlQ oMI91z3+n+sGkDjCfmUovN5aiwAK+KC3lbaaiMOeg90xcJWUvxaS+2iFRoQxTdl0dUZW 4VpvAmyTCo/AzJtvH2ttF4PkSCfj7yhPGga1x0dQHFrIBBveKdnVecRUGlrNoXyWanh4 NA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3atda5r6ps-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 01 Sep 2021 12:53:29 -0400 Received: from m0098404.ppops.net (m0098404.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 181Ginv1161691; Wed, 1 Sep 2021 12:53:28 -0400 Received: from ppma01wdc.us.ibm.com (fd.55.37a9.ip4.static.sl-reverse.com [169.55.85.253]) by mx0a-001b2d01.pphosted.com with ESMTP id 3atda5r6pc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 01 Sep 2021 12:53:28 -0400 Received: from pps.filterd (ppma01wdc.us.ibm.com [127.0.0.1]) by ppma01wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 181GWj4D023723; Wed, 1 Sep 2021 16:53:27 GMT Received: from b03cxnp07027.gho.boulder.ibm.com (b03cxnp07027.gho.boulder.ibm.com [9.17.130.14]) by ppma01wdc.us.ibm.com with ESMTP id 3aqcsddgv3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 01 Sep 2021 16:53:27 +0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp07027.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 181GrQGv26149268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 1 Sep 2021 16:53:26 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 443997805F; Wed, 1 Sep 2021 16:53:26 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 54CBF78060; Wed, 1 Sep 2021 16:53:25 +0000 (GMT) Received: from jarvis.int.hansenpartnership.com (unknown [9.211.89.117]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Wed, 1 Sep 2021 16:53:25 +0000 (GMT) Message-ID: <08185e00b379d70f3420e8c099c26ae5d62c18bc.camel@linux.ibm.com> Subject: Re: [edk2-devel] [PATCH V5 1/2] OvmfPkg: Introduce Tdx BFV/CFV PCDs and PcdOvmfImageSizeInKb From: "James Bottomley" Reply-To: jejb@linux.ibm.com To: "Yao, Jiewen" , "Xu, Min M" , Ard Biesheuvel , "devel@edk2.groups.io" , "kraxel@redhat.com" Cc: Ard Biesheuvel , "Justen, Jordan L" , Brijesh Singh , Erdem Aktas , Tom Lendacky Date: Wed, 01 Sep 2021 09:53:24 -0700 In-Reply-To: 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> User-Agent: Evolution 3.34.4 MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-Proofpoint-GUID: cr0ThcBOqspeDWjt8hRN6QyLHn-dYTTr X-Proofpoint-ORIG-GUID: H5zKJOe5Tjt1RYWn9u5lazE5NKX7pHzC 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 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 bulkscore=0 mlxscore=0 suspectscore=0 phishscore=0 malwarescore=0 adultscore=0 mlxlogscore=999 priorityscore=1501 clxscore=1011 spamscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2109010096 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Wed, 2021-09-01 at 08:59 +0000, Yao, Jiewen wrote: > Hi Min > I agree with Gerd and Ard in this case. > > 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. 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. 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. 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. James