From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.158.5]) by mx.groups.io with SMTP id smtpd.web10.11891.1637677612109256610 for ; Tue, 23 Nov 2021 06:26:52 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=hgL097Ht; spf=pass (domain: linux.ibm.com, ip: 148.163.158.5, mailfrom: jejb@linux.ibm.com) Received: from pps.filterd (m0098414.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 1ANDWt2K000820; Tue, 23 Nov 2021 14:26:49 GMT 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 : content-transfer-encoding : mime-version; s=pp1; bh=Qp0+gSVq4bYxngKs9qUows6B9bvoUgb2Mw9y3/VMFXg=; b=hgL097HtCUGvcNdAL6Q7lu2gB+cpErkOYIZWX/9Rc2xZCqqW/EidFvIOnT4tgyCzzzfS p3KVpNJOEqrdnxNruP+H3WR8MqxdPOZ8yeqrnaNLB9p/2naA1pzP4K+rKiA4zpmzGU8w l2AVgpBA69aFEXvaa4v1dEFVFAMWkB7hT42Xm4YtJJdNaqR2duK0/Q88K95mHbYeJuiK Q6LMFBH/3GfekLkRzsdP6O8WcoPMNpoYeFX65GfHS/tyt5+oI7+bYdjU2ToQEtCo0PTy rbjdh9hzBEwA9BvNId8WmMkt7OCsOqnLzGrECJkO/mHzMuf7HdGNNVvt9pBHqhDPScRs zg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 3cgxfp56hm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Nov 2021 14:26:48 +0000 Received: from m0098414.ppops.net (m0098414.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 1ANDWv84001034; Tue, 23 Nov 2021 14:26:48 GMT Received: from ppma03dal.us.ibm.com (b.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.11]) by mx0b-001b2d01.pphosted.com with ESMTP id 3cgxfp56h1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Nov 2021 14:26:48 +0000 Received: from pps.filterd (ppma03dal.us.ibm.com [127.0.0.1]) by ppma03dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 1ANEIoDB018931; Tue, 23 Nov 2021 14:26:47 GMT Received: from b03cxnp07028.gho.boulder.ibm.com (b03cxnp07028.gho.boulder.ibm.com [9.17.130.15]) by ppma03dal.us.ibm.com with ESMTP id 3ch1nb8uxs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Nov 2021 14:26:47 +0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp07028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 1ANEQkmG28312172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 23 Nov 2021 14:26:46 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EF0EB78069; Tue, 23 Nov 2021 14:26:45 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 30B3A7805F; Tue, 23 Nov 2021 14:26:44 +0000 (GMT) Received: from jarvis.int.hansenpartnership.com (unknown [9.163.26.160]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Tue, 23 Nov 2021 14:26:43 +0000 (GMT) Message-ID: Subject: Re: [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to support Tdx From: "James Bottomley" Reply-To: jejb@linux.ibm.com To: "Yao, Jiewen" , Gerd Hoffmann Cc: "Xu, Min M" , "devel@edk2.groups.io" , Ard Biesheuvel , "Justen, Jordan L" , Brijesh Singh , Erdem Aktas , Tom Lendacky Date: Tue, 23 Nov 2021 09:26:42 -0500 In-Reply-To: References: <867e8a2aaf28c308b20a659057217453c6e38e00.1635769996.git.min.m.xu@intel.com> <20211103063045.kmttoxyluifwo2bq@sirius.home.kraxel.org> <20211117151942.iqow75zq2lrn5xlc@sirius.home.kraxel.org> <20211119151130.g2wcnuhivt3lxvzi@sirius.home.kraxel.org> <20211123123821.q4fanslttg72n2r3@sirius.home.kraxel.org> User-Agent: Evolution 3.34.4 X-TM-AS-GCONF: 00 X-Proofpoint-GUID: td5jaF_AFFXPXbR3x61ZxAjbThSnripx X-Proofpoint-ORIG-GUID: J2pXrssqq5XkwTxcxKTbertZYSOOjkrM X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-11-23_05,2021-11-23_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 mlxscore=0 spamscore=0 clxscore=1015 suspectscore=0 lowpriorityscore=0 malwarescore=0 bulkscore=0 priorityscore=1501 impostorscore=0 phishscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2111230077 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Tue, 2021-11-23 at 13:07 +0000, Yao, Jiewen wrote: > Comment below only: > > > I am persuaded to let config-a adopt the OVMF way, because the > > threat model of config-A is same as the normal OVMF. > > But config-B is NOT. > > Different threat model drives different solution. > > I completely don't understand why they must be same. > > I don't understand why you want separate them. Improving OvmfPkg > security is good for both OVMF and TDVF. For TDVF it is clearly much > more important due to the different threat model, but it is good for > OVMF too. Likewise edk2 in general. > > [Jiewen] My answer is very clear as I mentioned multiple times. > The threat model is different. > IMHO, talking about "Improving OvmfPkg security" without a clear > threat model is *meaningless*. > All mitigation must be based upon threat mode and security objective. > Otherwise, what you are doing might be either unnecessary or > insufficient. Can we take a step back and look at the bigger picture. The way EFI is supposed to operate, according to the architecture model: https://uefi.org/sites/default/files/resources/PI_Spec_1_7_final_Jan_2019.pdf (Figure 1 and Table 4) is that SEC is supposed to be as small and compact as possible, so it could be ROM installed without worrying about upgrade issues. It's job is only to get the CPU initialized to the point it can run PEI, measure PEI and transfer control. Security depends on the smallness of SEC because if it's rom installed (as a root of trust ought to be) it can't be upgraded to fix a bug. PEI is supposed to initialize the hardware: set up the CPU, memory Application Processors and board configuration so we're in a known state with described features for DXE. It then measures DXE (only if SEC didn't measure it) and hands off to DXE. PEI code is designed not to interact with anything except setup to minimize external exploitation of internal bugs. DXE is supposed to contain only runtime code, including device drivers. The security point here is that the job of PEI is over as soon as it hands off to DXE, so at that point all the PEI code could be discarded (it usually isn't, but it could be). This strict isolation between DXE and PEI means that once we're in DXE, any bugs in PEI can't be exploited to attack the DXE environment. This allows us to minimize DXE which is where most of the main risk of configuration based exploitation is. In this security model, you increase security by moving as much code as you can from DXE to PEI because the true attack surface is DXE. To a lot of us, cutting out PEI, which requires redistributing code into DXE sounds like an increase not a reduction in the attack surface of the code. You can argue that OVMF doesn't obey the model above and has a lot of initialization code in DXE anyway, but then the correct route would be to fix our PEI/DXE separation to recover the security properties. > > If you force me to add PEI to config-B. Finally, that causes TDVF > > config-B is compromised due to an issue in PEI. > > Who will take the responsibility? Will you or RedHat take that? > > Bugs happen. There could also be bugs in the additional SEC code you > need for platform setup in a non-PEI configuration ... > > [Jiewen] I agree. That is why we need smaller code. > We can just focus on review that small portion of code what we have > written for TDVF, instead of the whole PEI. > We have process to review and maintain the extra TDVF code. This depends ... if you agree with the security model outlined above, bugs in PEI are less of a problem because they can't be exploited. Or do you not agree with this security model? Security isn't about total bug elimination, it's about exploit elimination. You fix a security vulnerability either by fixing the bug that can be exploited or removing the ability to exploit it. This is the reason for technologies like NX ... they don't stop people exploiting bugs to write code to the stack, but they do mean that once you have the code on the stack you can no-longer execute it and the attackers have to move on to other means of gaining control. The great thing about exploit elimination vs bug elimination is the former can usually be done on a whole class of bugs and the latter requires a whack-a-mole per bug type approach. James