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.web10.30856.1605731024037712194 for ; Wed, 18 Nov 2020 12:23:44 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=RrGO3Lsk; spf=pass (domain: linux.ibm.com, ip: 148.163.158.5, mailfrom: jejb@linux.ibm.com) Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0AIK1vj9165385; Wed, 18 Nov 2020 15:23:42 -0500 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=A+84HFIHOMFPwz+EzZ8dWnJGjRrLuHm1DXIKANADVws=; b=RrGO3LskcWLE1m0esIiQWvsivOz5gzzNb1TW5kxfshyRz5Mt8tFMQZvoIKtiH0TWQ2RL qBQEGY3p6XSZ6eFpgwcbNJYlT7l8mChj/8rI8BpSlWF2r8Piovd6AOvPxK8DIrTv68Vx udMj6Vc87R0TaAXrKhM3oKIMR+j6jmWml8d2S5tkmQl+/uVKskRmXPbZIhFGajeFDzpC 3gNjK7OF3UNgb4hjCcKdr/TUTiJkj8cOqEFiLZPXKIw6pRfpTGqxj0oiKS+vA4fF0P5v MlZfL03Tbm5N4wHsSxrOZMrMPXXVcUc6tJPFl6Z0z1QqAzUn5x6iw3WIrDscRGYvD6/M fg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 34w8pcuhfa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Nov 2020 15:23:42 -0500 Received: from m0098421.ppops.net (m0098421.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 0AIK3Uxe174625; Wed, 18 Nov 2020 15:23:41 -0500 Received: from ppma04dal.us.ibm.com (7a.29.35a9.ip4.static.sl-reverse.com [169.53.41.122]) by mx0a-001b2d01.pphosted.com with ESMTP id 34w8pcuhf5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Nov 2020 15:23:41 -0500 Received: from pps.filterd (ppma04dal.us.ibm.com [127.0.0.1]) by ppma04dal.us.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 0AIKMPLf016482; Wed, 18 Nov 2020 20:23:41 GMT Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by ppma04dal.us.ibm.com with ESMTP id 34t6v9h9bf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Nov 2020 20:23:41 +0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 0AIKNSaD63766972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 18 Nov 2020 20:23:28 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 80BED78068; Wed, 18 Nov 2020 20:23:37 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 677CD7805C; Wed, 18 Nov 2020 20:23:35 +0000 (GMT) Received: from jarvis.int.hansenpartnership.com (unknown [9.85.179.241]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Wed, 18 Nov 2020 20:23:35 +0000 (GMT) Message-ID: <111856145fea09b5ed88a1dfa7b7d7ff6eece639.camel@linux.ibm.com> Subject: Re: [edk2-devel] [PATCH 3/4] OvmfPkg: create a SEV secret area in the AmdSev memfd From: James Bottomley Reply-To: jejb@linux.ibm.com To: Laszlo Ersek , devel@edk2.groups.io Cc: dovmurik@linux.vnet.ibm.com, Dov.Murik1@il.ibm.com, ashish.kalra@amd.com, brijesh.singh@amd.com, tobin@ibm.com, david.kaplan@amd.com, jon.grimm@amd.com, thomas.lendacky@amd.com, frankeh@us.ibm.com, "Dr . David Alan Gilbert" Date: Wed, 18 Nov 2020 12:23:34 -0800 In-Reply-To: <6db69ccd-340f-2df2-718b-5f7db09da0b8@redhat.com> References: <20201112001316.11341-1-jejb@linux.ibm.com> <20201112001316.11341-4-jejb@linux.ibm.com> <6db69ccd-340f-2df2-718b-5f7db09da0b8@redhat.com> User-Agent: Evolution 3.34.4 MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312,18.0.737 definitions=2020-11-18_06:2020-11-17,2020-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 mlxscore=0 impostorscore=0 spamscore=0 lowpriorityscore=0 mlxlogscore=999 priorityscore=1501 clxscore=1015 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011180135 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Mon, 2020-11-16 at 23:46 +0100, Laszlo Ersek wrote: > On 11/12/20 01:13, James Bottomley wrote: [... I made all the changes above this] > > diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm > > b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm > > index 980e0138e7..7d3214e55d 100644 > > --- a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm > > +++ b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm > > @@ -35,6 +35,8 @@ ALIGN 16 > > ; the build time RIP value. The GUID must always be 48 bytes > > from the > > ; end of the firmware. > > ; > > +; 0xffffffc2 (-0x3e) - Base Location of the SEV Launch Secret > > +; 0xffffffc6 (-0x3a) - Size of SEV Launch Secret > > ; 0xffffffca (-0x36) - IP value > > ; 0xffffffcc (-0x34) - CS segment base [31:16] > > ; 0xffffffce (-0x32) - Size of the SEV-ES reset block > > @@ -51,6 +53,8 @@ ALIGN 16 > > TIMES (32 - (sevEsResetBlockEnd - sevEsResetBlockStart)) DB 0 > > > > sevEsResetBlockStart: > > + DD SEV_LAUNCH_SECRET_BASE > > + DD SEV_LAUNCH_SECRET_SIZE > > DD SEV_ES_AP_RESET_IP > > DW sevEsResetBlockEnd - sevEsResetBlockStart > > DB 0xDE, 0x71, 0xF7, 0x00, 0x7E, 0x1A, 0xCB, 0x4F > > (5) I'd prefer if we could introduce a new GUID-ed structure for > these new fields. The logic in QEMU should be extended to start > scanning at 4GB-48 for GUIDS. If the GUID is not recognized, then > terminate scanning. Otherwise, act upon the GUID-ed structure found > there as necessary, and then determine the next GUID *candidate* > location by subtracting the last recognized GUID-ed structure's > "size" field. So for this one, we can do it either way. However, the current design of the sevEsRestBlock is (according to AMD) to allow the addition of SEV specific information. Each piece of information is a specific offset from the GUID and the length of the structure can only grow, so the ordering is fixed once the info is added and you can tell if the section contains what you're looking for is present if the length covers it. We can certainly move this to a fully GUID based system, which would allow us to have an unordered list rather than the strict definition the never decreasing length scheme allows, but if we do that, the length word above becomes redundant. I don't have a huge preference for either mechanism ... they seem to work equally well, but everyone should agree before I replace the length based scheme. James