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.10010.1623254406016817596 for ; Wed, 09 Jun 2021 09:00:06 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=mJtb38wL; spf=pass (domain: linux.ibm.com, ip: 148.163.158.5, mailfrom: jejb@linux.ibm.com) Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 159FY2W4133640; Wed, 9 Jun 2021 12:00:01 -0400 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=dllmvlBcL2B114BuwtmcaF0BAYVn8h/5OqT0wgZhuuM=; b=mJtb38wLKM84VD1XHew/dYiyEmtB0FLxpyPOsbHyRDUtAkNA3qnH4JnK3woHYDmJU0Ku KyPpPftorUXVXNwDeX5xftOk75XNL05UYNppZK+C1oH9nSj8wZ5HIDvyZNYeN5gEvNOc uRLRHEvrkSQ0TvXtdIkonLWvYV2zZz2pyUnEUbYacJcMKxf36wOHM24pBW1RhwjKn4Ms JXMQsV9FOKREMtwQBZse1sH9GGp3M5qKM8X9hV4rP4nTntIjSrwc131o6QK/usI37W83 96zFD7PZUxgqfshgdT+/d8HMGs36MJTNaKEQVaYCkTz22qIzndMtrjg7OFCqzTgneaIa cQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 392xpamrb8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Jun 2021 12:00:01 -0400 Received: from m0098413.ppops.net (m0098413.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 159FYE3b134447; Wed, 9 Jun 2021 12:00:01 -0400 Received: from ppma01wdc.us.ibm.com (fd.55.37a9.ip4.static.sl-reverse.com [169.55.85.253]) by mx0b-001b2d01.pphosted.com with ESMTP id 392xpamraq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Jun 2021 12:00:01 -0400 Received: from pps.filterd (ppma01wdc.us.ibm.com [127.0.0.1]) by ppma01wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 159Fv2dS028528; Wed, 9 Jun 2021 16:00:00 GMT Received: from b03cxnp08028.gho.boulder.ibm.com (b03cxnp08028.gho.boulder.ibm.com [9.17.130.20]) by ppma01wdc.us.ibm.com with ESMTP id 3900w98vwh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Jun 2021 16:00:00 +0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp08028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 159Fxx2U21102882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 9 Jun 2021 15:59:59 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5B20878063; Wed, 9 Jun 2021 15:59:59 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E0A037806E; Wed, 9 Jun 2021 15:59:55 +0000 (GMT) Received: from jarvis.int.hansenpartnership.com (unknown [9.85.129.99]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Wed, 9 Jun 2021 15:59:55 +0000 (GMT) Message-ID: <8eabf1c1fba9bfcb7f6eb2247a1ba336e04952ca.camel@linux.ibm.com> Subject: Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF From: "James Bottomley" Reply-To: jejb@linux.ibm.com To: Paolo Bonzini , "Xu, Min M" , "devel@edk2.groups.io" , "Yao, Jiewen" , "rfc@edk2.groups.io" Cc: Laszlo Ersek , Brijesh Singh , Tom Lendacky , "erdemaktas@google.com" , "cho@microsoft.com" , "bret.barkelew@microsoft.com" , Jon Lange , Karen Noel , Nathaniel McCallum , "Dr. David Alan Gilbert" , "Ademar de Souza Reis Jr." Date: Wed, 09 Jun 2021 08:59:54 -0700 In-Reply-To: References: User-Agent: Evolution 3.34.4 MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: Vm9Xp8GLm3cHQ-AJRsGaVBVi_Fuo05sg X-Proofpoint-GUID: D7FHM8EFzkZlZI5mAFEYqfGfsWej0-C0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-06-09_04:2021-06-04,2021-06-09 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 spamscore=0 clxscore=1015 mlxscore=0 lowpriorityscore=0 malwarescore=0 priorityscore=1501 adultscore=0 mlxlogscore=999 bulkscore=0 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106090075 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Wed, 2021-06-09 at 17:47 +0200, Paolo Bonzini wrote: > On 09/06/21 16:28, James Bottomley wrote: > > That would cut across the ApEntrypoint and the guidedStructureEnd. > > However, nothing says anything in the reset vector guided structure > > has to be data ... so it could equally well be code. That means we > > can do guid based entries that contain the 32 bit real and 64 bit > > entry points. This would also come with the added advantage that > > we can scan the OVMF binary to see what entry points it supports. > > Isn't the initial state included in the save area just like for SEV- > ES? Initial state of what? We currently have two entries: one points to the address and size of the secrets page and the other gives the address of the ES work area page that's used for AP reset. > So it's not even QEMU, but rather some external tool that builds > the encrypted image, that needs to understand that GUIDed structure. Yes, it's really to make the configuration of the OVMF blob somewhat introspectable. The current consumer is QEMU, but I see no reason why other tools might not use this mechanism as well. > The GUIDed structure can either include the entry point code; or it > could have room for a couple 8-byte pointers since any fixed-size > area in the GUIDed structure would be just a jump anyway. Well, exactly ... depending on what the requirement is we can do pretty much anything with the data contents with the only caveat that it's currently constructed by an asm file, so we don't quite have the full macro power of C available. However, symbol resolution is definitely possible and quite easy. James