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.1517.1620316969152760235 for ; Thu, 06 May 2021 09:02:50 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=XLNknUv7; spf=pass (domain: linux.ibm.com, ip: 148.163.158.5, mailfrom: jejb@linux.ibm.com) Received: from pps.filterd (m0098414.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 146FWerw038838; Thu, 6 May 2021 12:02:46 -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=eSyMymZYDtSucWMLRh/GL+JZG/lUtMQMQsSa/6jdi38=; b=XLNknUv7IHn+i5qhY1H1JuoJskFeYWv7dNZRbZ7AQMV5p+lAqwUXgxP10mEuhYJCPFjL MQYwZgHlmE9XBPITipjtDXap2AS8G3Nql5DMDH8Lhm0u2fIXur/CckKBkBc9Xe5b+fKe 9HkIyDSskopmSMP0AxxwbIZ20ekVf3rSYORjIjgDOjPjTkUvYvNjyDCR6XLADaNl/VQy ui62TskPZW3CSbiRhaHL/IWEq4KWt+2ZcQP+V3iVxOdM47a98fHwfERjLhLIpEZkfVKP oNmQnvJrNtaO5xto0xl4XHu9NtzveUgdShWr4HEGuCldkl//TRg+xJ3T2rph+h4S/Hi1 Kw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 38chabd57h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 May 2021 12:02:46 -0400 Received: from m0098414.ppops.net (m0098414.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 146FtI3H151759; Thu, 6 May 2021 12:02:46 -0400 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 38chabd56u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 May 2021 12:02:46 -0400 Received: from pps.filterd (ppma04wdc.us.ibm.com [127.0.0.1]) by ppma04wdc.us.ibm.com (8.16.0.43/8.16.0.43) with SMTP id 146FflBG002676; Thu, 6 May 2021 16:02:45 GMT Received: from b03cxnp07029.gho.boulder.ibm.com (b03cxnp07029.gho.boulder.ibm.com [9.17.130.16]) by ppma04wdc.us.ibm.com with ESMTP id 38bedu4uth-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 May 2021 16:02:45 +0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp07029.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 146G2iS823855474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 6 May 2021 16:02:44 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 434937805E; Thu, 6 May 2021 16:02:44 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CE9397805F; Thu, 6 May 2021 16:02:39 +0000 (GMT) Received: from jarvis (unknown [9.80.192.238]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Thu, 6 May 2021 16:02:39 +0000 (GMT) Message-ID: <65a716cc4943d0998e5bf45df37da97fdb03325e.camel@linux.ibm.com> Subject: Re: [edk2-devel] [PATCH RFC v2 11/28] OvmfPkg: Reserve Secrets page in MEMFD From: "James Bottomley" Reply-To: jejb@linux.ibm.com To: Laszlo Ersek , devel@edk2.groups.io, brijesh.singh@amd.com, Dov Murik Cc: Min Xu , Jiewen Yao , Tom Lendacky , Jordan Justen , Ard Biesheuvel , Erdem Aktas , "tobin@ibm.com" Date: Thu, 06 May 2021 09:02:37 -0700 In-Reply-To: References: <20210430115148.22267-1-brijesh.singh@amd.com> <20210430115148.22267-12-brijesh.singh@amd.com> <8b46fe32-beda-0195-8c67-c7ef19194f85@linux.vnet.ibm.com> User-Agent: Evolution 3.34.4 MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: K3m06gkD-53leyCDhdhFluO53u3MV8Dq X-Proofpoint-GUID: Irs_VVcmWNn2_Rc4oFHd845LG3OsK4cI X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-05-06_10:2021-05-06,2021-05-06 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 impostorscore=0 spamscore=0 suspectscore=0 phishscore=0 malwarescore=0 lowpriorityscore=0 bulkscore=0 priorityscore=1501 clxscore=1011 mlxscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2105060109 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Wed, 2021-05-05 at 21:33 +0200, Laszlo Ersek wrote: > On 05/05/21 15:11, Brijesh Singh wrote: > > On 5/5/21 1:42 AM, Dov Murik wrote: [...] > > > Would it make sense to always use EfiACPIMemoryNVS for the > > > injected secret area, even for regular SEV (non-SNP)? > > > > Ideally yes. Maybe James had some reasons for choosing the > > EfiBootServicesData. If I had to guess, it was mainly because there > > no guest kernel support which consumes the SEV secrets page. > > git-blame fingers commit bff2811c6d99 ("OvmfPkg/AmdSev: assign and > reserve the Sev Secret area", 2020-12-14). > > Commit bff2811c6d99 makes it clear that the area in question lives in > MEMFD. > > We're populating the area in the PEI phase. We don't want anything in > DXE to overwrite it. > > Once the bootloader (and/or perhaps the kernel's EFI stub) fetched > the secret from that particular location, there is no need to prevent > later parts of the OS (the actual kernel) from repurposing that area. > That's why EfiBootServicesData was used. That's right: originally the design was not to have the boot secrets survive boot because they should already be copied into their correct, and presumably protected, locations by the time exit boot services comes. The grub code actually shreds the secret in the page once it consumes it, so the area for a simple disk secret should be empty anyway. James