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.6112.1637760921373064673 for ; Wed, 24 Nov 2021 05:35:21 -0800 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@ibm.com header.s=pp1 header.b=tINPJBiV; spf=pass (domain: linux.ibm.com, ip: 148.163.158.5, mailfrom: jejb@linux.ibm.com) Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 1AOCMF26003310; Wed, 24 Nov 2021 13:35:19 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 : mime-version : content-transfer-encoding; s=pp1; bh=EuhrBYyyWwEhfOcEARCE4yxoeAiLKYrKkjweBoGzULE=; b=tINPJBiVinHoUp1f5qi8tame4aByevZIQrKD7NdlfU8r4owgBHPNTdyq+5Ahr4bPQVfx 2jo6mqlK1Y3qfRgWtnEMaoZKBCWjrLre6DAzCSpjw2tcu4J9CKKF6Vg+U2YChpZr+aT7 Xn3wvho+7grBVwmehVAC+JjYxp0uDHcRLbsqiP6Pl03w4veuSaeHVzGJnAb/E/j9TJY8 uwIkXz1MDwD+wn4cwZdyVNqOisrTaP5Jyo1aoHUplhR1/QlO9p9FsXq7hdyBs30hmjgn xtwbNAXn346M3jE6Z3AYFDsQl43iyFyhJaQfG3YuS/h+G1oDf7BPHLTBQi23HuFx3R0k jQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 3chnbchhbr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Nov 2021 13:35:18 +0000 Received: from m0098416.ppops.net (m0098416.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 1AODTYqb027689; Wed, 24 Nov 2021 13:35:18 GMT Received: from ppma04wdc.us.ibm.com (1a.90.2fa9.ip4.static.sl-reverse.com [169.47.144.26]) by mx0b-001b2d01.pphosted.com with ESMTP id 3chnbchhbg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Nov 2021 13:35:18 +0000 Received: from pps.filterd (ppma04wdc.us.ibm.com [127.0.0.1]) by ppma04wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 1AODZ7Ba031021; Wed, 24 Nov 2021 13:35:17 GMT Received: from b03cxnp08025.gho.boulder.ibm.com (b03cxnp08025.gho.boulder.ibm.com [9.17.130.17]) by ppma04wdc.us.ibm.com with ESMTP id 3cernbhrb1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Nov 2021 13:35:17 +0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp08025.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 1AODZGqY59113898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 24 Nov 2021 13:35:16 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8B4577806A; Wed, 24 Nov 2021 13:35:16 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A8B457807B; Wed, 24 Nov 2021 13:35:14 +0000 (GMT) Received: from jarvis.int.hansenpartnership.com (unknown [9.163.26.160]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Wed, 24 Nov 2021 13:35:14 +0000 (GMT) Message-ID: <5d39c546fe66fc945e9687f187ed9892b6a6a00c.camel@linux.ibm.com> Subject: Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to support Tdx From: "James Bottomley" Reply-To: jejb@linux.ibm.com To: devel@edk2.groups.io, jiewen.yao@intel.com, Gerd Hoffmann Cc: "Xu, Min M" , Ard Biesheuvel , "Justen, Jordan L" , Brijesh Singh , Erdem Aktas , Tom Lendacky Date: Wed, 24 Nov 2021 08:35:13 -0500 In-Reply-To: References: <20211119151130.g2wcnuhivt3lxvzi@sirius.home.kraxel.org> <20211123123821.q4fanslttg72n2r3@sirius.home.kraxel.org> <1D6AF5B4-87BD-4773-A5C7-4779016A0673@intel.com> <1DF0C062-BF78-44E2-BE96-2C8727C36845@intel.com> <5ec6897681e46fe181193651164f0f17d5d1205d.camel@linux.ibm.com> <20211124081204.ortxlgwgp2c5dlhw@sirius.home.kraxel.org> User-Agent: Evolution 3.34.4 MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: dmCxxs3yM295-e7wQ5xd1rc490ZyA0oE X-Proofpoint-GUID: LpAfxsF9pJzPUtFDlaLUfpcysK9WLcSj 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-24_04,2021-11-24_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 bulkscore=0 adultscore=0 phishscore=0 suspectscore=0 impostorscore=0 lowpriorityscore=0 mlxlogscore=999 spamscore=0 malwarescore=0 clxscore=1015 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2111240076 X-MIME-Autoconverted: from 8bit to quoted-printable by mx0b-001b2d01.pphosted.com id 1AOCMF26003310 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2021-11-24 at 11:08 +0000, Yao, Jiewen wrote: > > -----Original Message----- > > From: Gerd Hoffmann [...] > > There isn't much external input to process in PEI phase. Virtual > > machines are a bit different than physical machines. They need to > > process some input from the host here which describes the virtual > > hardware so they can initialize it properly. For example parse the > > etc/e820 fw_cfg file to figure how much memory is installed (or > > parse the td hob in case tdx is used). > >=20 > > That platform-specific code for virtual machine initialization must > > do careful sanity checking when you don't want trust the VMM of > > course. Whenever that code lives in SEC or PEI doesn't change the > > picture much though. I don't disagree on this because we don't have a rom root of trust in OVMF ... however it matters for most of the rest of edk2 > [Jiewen] I am not sure what information you are trying to convey. > I never said that TDVF don=E2=80=99t need check the input after remove = PEI. > The check is always needed, no matter in PEI or SEC. I totally agree. >=20 > However, what I want to say is PEI has much more unnecessary code > than SEC. > You never know the quality of the those unnecessary code. Maybe it > has a security bug, but it is just not triggered. > For example, can you guarantee PEI code has not bug? Or DXE IPL has > not bug? Code removal to thin down the image is orthogonal to the location of that code ... I don't think anyone objected to securing the path through PEI by reducing unnecessary code; the doubt is that the elimination of PEI somehow improves security. >=20 > What I did is a process of risk management - if PEI is removed, I > don=E2=80=99t need care the risk brought by PEI. Well, as I said above, you can remove the unnecessary code in PEI (and SEC and DXE). However, once you've done that, you don't eliminate risk by removing PEI because all you do is move the necessary code that was in PEI to somewhere else. If you move it to SEC, I agree with Gerd that it doesn't alter the security position much because SEC is a low exposure domain like PEI. If you move it to DXE it actually decreases your security measurably because DXE is a high exposure security domain. > Unless you can prove that the risk of PEI is zero, then the risk is > there. But you don't make it zero by eliminating PEI, you simply move the risk elsewhere because the necessary code still has to execute. > > > 2. "bugs in PEI code can't be used to exploit the system when it > > > has transitioned to the DXE domain." > > > [Jiewen] I disagree. A bug in PEI code may already modify the > > > HOB, while the HOB is an architecture data input for DXE. > > > If DXE relies on some malicious data from PEI, DXE might be > > > exploited later. > >=20 > > Attacking PEI is harder though because the external input it > > processes is limited when compared to DXE. > >=20 > > Once you are transitioned to DXE you can't call into PEI Modules > > any more. > >=20 > > So, how would an attacker trick PEI code into modifying HOBs (or > > carrying out other actions under attackers control)? >=20 > [Jiewen] I would disagree " Attacking PEI is harder though because > the external input it processes is limited when compared to DXE "=20 > First, the number of extern input !=3D the difficulty of the attack. > Second, the number of extern input !=3D the severity of the > consequence. Attacking PEI is harder than attacking DXE because of the limited exposure to external influences. It doesn't mean it can't be done but it does mean exploiting the same code can be harder or impossible in PEI compared to DXE. The key point is there are some classes of bug that can't be exploited in PEI because of the limited exposure. These bugs can be exploited in DXE because of the wider exposure. This is why moving code from DXE to PEI increases the risk. > On how to trick PEI, if you search the public UEFI BIOS attack > history in the web, you can find example. > The attack simply used an integer overflow, to cause buffer overflow. > And the buffer overflow can be used to inject shellcode, then gain > the execution privilege. > Finally, it can control the whole system. >=20 > Modifying HOB is not a difficult task, as long as there is proper > vulnerability, being used to gain a memory write. >=20 > In security world, we always say: Even if you cannot do it, you > cannot assume other people cannot do it. > Unless you can prove it cannot be done. Otherwise, anything might be > possible. >=20 > That is why people are in favor of crypto notation and formal > verification to prove something is correct. There are many ways of improving security. Formal verification has its place, but grows exponentially harder with the complexity of the system. Separation into multiple security domains is also a common technique (which also facilitates formal verification because it reduces the state space). What I worry about is that elimination of one of the UEFI security domains causes code to move to places that makes it more exploitable. James