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.web08.3477.1648672536127350908 for ; Wed, 30 Mar 2022 13:35:36 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@ibm.com header.s=pp1 header.b=GoFwq9QL; spf=pass (domain: linux.ibm.com, ip: 148.163.156.1, mailfrom: dovmurik@linux.ibm.com) Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 22UKS6vb011525; Wed, 30 Mar 2022 20:35:31 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=0qjOcVzDam1izXUT6vP+SpVtmyyQtluzTsxNRPAU6Sc=; b=GoFwq9QLzYB8t+Dn8X1cHvimEYpLqtUDsCM8G09dSvZQdDTM404FeN6PIPcGrpsOW+B9 n+36ItsKzkaBd0L8BV9762i1Gmvbu6J6SWWmdEeGH4u1BBHMGSMBYU8ZaJuTiBNx7yAx J3dgxAQjzbludRBE0oxPmm76hr778KE5+d5NGC9bZsf55jd6QN6HEu1nfvQ8ZEnYkWfb OsLXLeRvh+1wvluUKffHiyghgHrKxXgY3uI2RyPMmAeaTjYKNPpy6WY9ZK7WNFtW3nrO M/gW4kO50CGnVzIMdwBZRjpEyZ/FuklFb/OlT2OO/o7p6P0naivrOCmkIFWudwmMBbR5 dw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3f4uw2b290-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Mar 2022 20:35:30 +0000 Received: from m0098399.ppops.net (m0098399.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 22UKS89F011765; Wed, 30 Mar 2022 20:35:30 GMT Received: from ppma03dal.us.ibm.com (b.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.11]) by mx0a-001b2d01.pphosted.com with ESMTP id 3f4uw2b27v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Mar 2022 20:35:30 +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 22UKJYuv019615; Wed, 30 Mar 2022 20:35:29 GMT Received: from b01cxnp23034.gho.pok.ibm.com (b01cxnp23034.gho.pok.ibm.com [9.57.198.29]) by ppma03dal.us.ibm.com with ESMTP id 3f1tfa7fuy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Mar 2022 20:35:29 +0000 Received: from b01ledav004.gho.pok.ibm.com (b01ledav004.gho.pok.ibm.com [9.57.199.109]) by b01cxnp23034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 22UKZSRi21889414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 30 Mar 2022 20:35:28 GMT Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3D809112065; Wed, 30 Mar 2022 20:35:28 +0000 (GMT) Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9DB00112063; Wed, 30 Mar 2022 20:35:25 +0000 (GMT) Received: from [9.160.79.229] (unknown [9.160.79.229]) by b01ledav004.gho.pok.ibm.com (Postfix) with ESMTP; Wed, 30 Mar 2022 20:35:25 +0000 (GMT) Message-ID: <949fc10b-1c9f-524b-dadc-55b3332adbc2@linux.ibm.com> Date: Wed, 30 Mar 2022 23:35:24 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH 2/2] OvmfPkg/ResetVector: Exclude SEV launch secrets page from pre-validation To: Brijesh Singh , Gerd Hoffmann Cc: devel@edk2.groups.io, Ard Biesheuvel , Jiewen Yao , Jordan Justen , Erdem Aktas , James Bottomley , Min Xu , Tom Lendacky , Tobin Feldman-Fitzthum , Dov Murik References: <20220328184530.86797-1-dovmurik@linux.ibm.com> <20220328184530.86797-3-dovmurik@linux.ibm.com> <20220330052029.4fuzbca2364nm7fg@sirius.home.kraxel.org> <7585badc-63d5-4195-760c-3cc3665795e4@linux.ibm.com> <7ea76edb-fad8-b06e-e715-0868de1f1261@amd.com> <5a8dfc50-d9e8-447e-6328-302d8a519c79@linux.ibm.com> <4fdbb522-e7e5-a0a8-ee1b-003e3f80c9c6@amd.com> From: "Dov Murik" In-Reply-To: <4fdbb522-e7e5-a0a8-ee1b-003e3f80c9c6@amd.com> X-TM-AS-GCONF: 00 X-Proofpoint-GUID: Fd59qDRQ1PLyVSYME_5pztWdYxkxM8Wa X-Proofpoint-ORIG-GUID: PS_7gomBCqPFs53OkGB_s8pshttAJNyF X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.850,Hydra:6.0.425,FMLib:17.11.64.514 definitions=2022-03-30_06,2022-03-30_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 mlxscore=0 lowpriorityscore=0 suspectscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxlogscore=999 adultscore=0 priorityscore=1501 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2203300099 X-MIME-Autoconverted: from 8bit to quoted-printable by mx0a-001b2d01.pphosted.com id 22UKS6vb011525 Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 30/03/2022 22:35, Brijesh Singh wrote: >=20 >=20 > On 3/30/22 14:31, Dov Murik wrote: >> >> >> On 30/03/2022 22:27, Brijesh Singh wrote: >>> >>> >>> On 3/30/22 01:04, Dov Murik wrote: >>>> >>>> >>>> On 30/03/2022 8:20, Gerd Hoffmann wrote: >>>>> =C2=A0=C2=A0=C2=A0 Hi, >>>>> >>>>>> Check if that page is defined; if it is, skip it in the metadata >>>>>> list. >>>>>> In such case, VMM should fill the page with the hashes content, or >>>>>> explicitly update it as a zero page (if kernel hashes are not used= ). >>>>> >>>>> Is it an option to just skip the page unconditionally? >>>>> >>>>> I think in the OvmfPkgX64 build the page is not used, so it probabl= y >>>>> doesn't matter whenever it is included or not, and it would make >>>>> things >>>>> a bit less confusing ... >>>>> >>>> >>>> >>>> Brijesh, >>>> >>>> What would happen if we change this: >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 %define SNP_SEC_MEM_BASE_DESC_3 (CPUI= D_BASE + CPUID_SIZE) >>>> >>>> to: >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 %define SNP_SEC_MEM_BASE_DESC_3 (Fixe= dPcdGet32 >>>> (PcdOvmfSecPeiTempRamBase)) >>>> >>>> in OvmfPkg/ResetVector/ResetVector.nasmb ? >>>> >>>> It means that the page starting at MEMFD_BASE_ADDRESS+0x00F000 (that >>>> is, the page >>>> that follows the SNP CPUID page) will not be pre-validated by QEMU. >>>> >>> >>> Lets look at the OvmfPkgX64.fdf is >>> >>> ... >>> >>> 0x00E000|0x001000 >>> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidBase|gUefiOvmfPkgTokenSpaceGui= d.PcdOvmfCpuidSize >>> >>> >>> >>> 0x010000|0x010000 >>> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgToken= SpaceGuid.PcdOvmfSecPeiTempRamSize >>> >>> >>> >>> 0x020000|0x0E0000 >>> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpace= Guid.PcdOvmfPeiMemFvSize >>> >>> >>> >>> ... >>> >>> If you change SNP_SEC_MEM_BASE_DESC_3 to start from PcdOvmfPeiMemFvBa= se >>> then who will validate the range for=C2=A0 PcdOvmfSecPeiTempRamBase - >>> PcdOvmfPeiMemFvBase ? The SEC phase (Sec/X64/SecEntry.nasm) uses the >>> PcdOvmfSecPeiTempRamBase. If the memory is not validated prior to use >>> then it will result in #VC (page-not-validated) and crash the guest B= IOS >>> boot. >>> >> >> Gerd actually wants to change SNP_SEC_MEM_BASE_DESC_3 to start from >> PcdOvmfSecPeiTempRamBase, which is 0x010000. >> >> Supposedly no one uses the single page at 0x00F000 . >=20 > Yes, that should be alright as long as the SNP_SEC_MEM_BASE_DESC_3 star= t > from PcdOvmfSecPeiTempRamBase. In PEI phase, we validate all the > unvalidated range. So, as long as SEC phase is not using 800F000 - > 8010000 we should be good. The PEI will validate that page. >=20 How does the PEI phase know that this page in the middle is still unvalid= ated? I see this code: STATIC SNP_PRE_VALIDATED_RANGE mPreValidatedRange[] =3D { = =20 // The below address range was part of the SEV OVMF metadata, and range= =20 // should be pre-validated by the Hypervisor. = =20 { = =20 FixedPcdGet32 (PcdOvmfSecPageTablesBase), = =20 FixedPcdGet32 (PcdOvmfPeiMemFvBase), = =20 }, = =20 // The below range is pre-validated by the Sec/SecMain.c = =20 { = =20 FixedPcdGet32 (PcdOvmfSecValidatedStart), = =20 FixedPcdGet32 (PcdOvmfSecValidatedEnd) = =20 }, = =20 }; = =20 As the comment says, it assumes the entire range from PcdOvmfSecPageTablesBase (=3D 0x800000) to PcdOvmfPeiMemFvBase (=3D 0x820000)=20 is pre-validated by the Hypervisor. How will it know to actually validate that page at 0x80F000 ? -Dov