From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by mx.groups.io with SMTP id smtpd.web09.13823.1634409508955108427 for ; Sat, 16 Oct 2021 11:38:29 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=OHtUagoo; spf=pass (domain: linux.ibm.com, ip: 148.163.158.5, mailfrom: dovmurik@linux.ibm.com) Received: from pps.filterd (m0127361.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19GGVX2p037955; Sat, 16 Oct 2021 14:38:27 -0400 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=6TpMc2sPoJPg+zB2VkCNtB+U9IoFHhPzgsmRz2F3l14=; b=OHtUagooRRwoN117dgB9Wv6DjTQwCf99eB5BglsNTTpSm8PIcbWDSQGSKBZPm5kkbl1v gtakR7okKD7+M6C2mJ7yfmRq2VnP2jop5O9mrXFeWQhBbdx92psjPWBRWVyITEUy0ieV WI7EDpBWDOoEO9xGNebuAuqOWqYO0WWyre+YIJc0YIN5BqHg9jtIMz7OynDjLokSQB2d WV6ZdCHtVIB38rRHNTb3quoMZf8z9eARalzYS+EURu1idr/tRuEWR3pRg9O62iUIPUVP GcjEC5CpjIz2bV08FpQ8UwZarsUWQyxHlqqe8tgYAqWVUidx+KpME1lZTBsKgGXz4AqT Mg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3br2b6sfdv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 16 Oct 2021 14:38:26 -0400 Received: from m0127361.ppops.net (m0127361.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 19GIUD89017702; Sat, 16 Oct 2021 14:38:26 -0400 Received: from ppma02dal.us.ibm.com (a.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.10]) by mx0a-001b2d01.pphosted.com with ESMTP id 3br2b6sfdh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 16 Oct 2021 14:38:26 -0400 Received: from pps.filterd (ppma02dal.us.ibm.com [127.0.0.1]) by ppma02dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 19GIYCOv020438; Sat, 16 Oct 2021 18:38:25 GMT Received: from b03cxnp08027.gho.boulder.ibm.com (b03cxnp08027.gho.boulder.ibm.com [9.17.130.19]) by ppma02dal.us.ibm.com with ESMTP id 3bqpc9gmus-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 16 Oct 2021 18:38:25 +0000 Received: from b03ledav002.gho.boulder.ibm.com (b03ledav002.gho.boulder.ibm.com [9.17.130.233]) by b03cxnp08027.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 19GIcN4G18481760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 16 Oct 2021 18:38:23 GMT Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B1AF5136055; Sat, 16 Oct 2021 18:38:23 +0000 (GMT) Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7CC04136051; Sat, 16 Oct 2021 18:38:20 +0000 (GMT) Received: from [9.65.213.166] (unknown [9.65.213.166]) by b03ledav002.gho.boulder.ibm.com (Postfix) with ESMTP; Sat, 16 Oct 2021 18:38:20 +0000 (GMT) Message-ID: <02cc952f-6170-fb28-a1b1-a3b62b43e5c4@linux.ibm.com> Date: Sat, 16 Oct 2021 21:38:19 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH 2/2] OvmfPkg/AmdSev: update the fdf to use new workarea PCD To: Brijesh Singh , devel@edk2.groups.io Cc: James Bottomley , Min Xu , Jiewen Yao , Tom Lendacky , Jordan Justen , Ard Biesheuvel , Erdem Aktas , Michael Roth , Gerd Hoffmann , Dov Murik , Tobin Feldman-Fitzthum References: <20211014181711.784074-1-brijesh.singh@amd.com> <20211014181711.784074-3-brijesh.singh@amd.com> From: "Dov Murik" In-Reply-To: <20211014181711.784074-3-brijesh.singh@amd.com> X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: _hsmJDKFIvq_tW_x92KukUPfQgeglCL8 X-Proofpoint-GUID: OyvWbe32joiw462JuB1zt00Zf2qfMRd- X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-16_06,2021-10-14_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 adultscore=0 mlxlogscore=999 clxscore=1011 suspectscore=0 bulkscore=0 spamscore=0 phishscore=0 impostorscore=0 mlxscore=0 priorityscore=1501 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110160126 Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [+Tobin] On 14/10/2021 21:17, Brijesh Singh wrote: > The commit 80e67af9afca added support for the generic work area concept > used mainly by the encrypted VMs but missed update the AmdSev package. > > Fixes: 80e67af9afca ("OvmfPkg: introduce a common work area") Thanks Brijesh. The fix does allow me to launch SEV-ES guests, which is good news. However, the guest's measurement has changed, so I wonder what this change causes. The details: I tested 3 commits (always building the AmdSevX64 target): 1. commit 7b4a99be8a39 - edk2-stable202108 I successfully launch SEV and SEV-ES guests and my measurement check script verifies the digest correctly (including the "measured linux boot" hashes table added by QEMU). 2. commit f10a112f08f3 - master (Oct 14) I successfully launch SEV guests, but SEV-ES guests crash with "error: kvm run failed Invalid argument". The measurement check verifies digest correctly. 3. master + this AmdSevX64.fdf patch I successfully launch SEV guests and measurement calculation is OK. As far SEV-ES guests, the measurement check doesn't match what I expect. If I ignore the mismatched measurement and continue the launch, the guest runs OK with SEV-ES. So this patch fixes the problem (SEV-ES guest crashes on launch) but shows another problem (bad guest measurement). Note that for this test, my measurement calculation script automatically takes the OVMF image I'm using to boot the VM. From my reading of the QEMU code, the only pieces that should affect the measurement is the OVMF image, the hashes table, and the VMSAs for each vcpu. The OVMF image is updated on every check, and the rest shouldn't have changed between those 3 revisions that I tested. It might be an issue with my measurement checking script which was assuming something that has changed with the introduction of the new work area, but I can't think of something like that. Note again that plain SEV measurement is still working OK. Do you encounter similar issues with VM measurement? -Dov > Cc: James Bottomley > Cc: Min Xu > Cc: Jiewen Yao > Cc: Tom Lendacky > Cc: Jordan Justen > Cc: Ard Biesheuvel > Cc: Erdem Aktas > Cc: Gerd Hoffmann > Reported-by: Dov Murik > Signed-off-by: Brijesh Singh > --- > OvmfPkg/AmdSev/AmdSevX64.fdf | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/OvmfPkg/AmdSev/AmdSevX64.fdf b/OvmfPkg/AmdSev/AmdSevX64.fdf > index 542722ac6b37..56626098862c 100644 > --- a/OvmfPkg/AmdSev/AmdSevX64.fdf > +++ b/OvmfPkg/AmdSev/AmdSevX64.fdf > @@ -57,7 +57,7 @@ [FD.MEMFD] > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize > > 0x00B000|0x001000 > -gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase|gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize > +gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaSize > > 0x00C000|0x000C00 > gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretBase|gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretSize > @@ -79,6 +79,13 @@ [FD.MEMFD] > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize > FV = DXEFV > > +########################################################################################## > +# Set the SEV-ES specific work area PCDs > +# > +SET gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase = $(MEMFD_BASE_ADDRESS) + gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaBase + gUefiOvmfPkgTokenSpaceGuid.PcdOvmfConfidentialComputingWorkAreaHeader > +SET gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize = gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaSize - gUefiOvmfPkgTokenSpaceGuid.PcdOvmfConfidentialComputingWorkAreaHeader > +########################################################################################## > + > ################################################################################ > > [FV.SECFV] >