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.web08.1639.1620317533132959979 for ; Thu, 06 May 2021 09:12:13 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=mvZUcs+K; spf=pass (domain: linux.ibm.com, ip: 148.163.158.5, mailfrom: jejb@linux.ibm.com) Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 146GAe8b054480; Thu, 6 May 2021 12:12:10 -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=08XA/zFaGZ73f/8YvcwA8Kw73N3oD//v7z7ZLtXGzrU=; b=mvZUcs+KZ4x7oGXsnXv9g//YOJU4oNWfgoBsJ+q9Nf979qTzuYxd7LX5a4XSTSTBRTUB PS587s1gTjWt+ogL6+8d7ggQANdg+4pwjvs8ZMCNnrCet7eNDYFmnp9OvZb0Fus/La+a gR7ogSVpNRmgQw4D7r3N6R5YCt0SNwXv06m4kb01HiEFuQR3qH1DJjdexPV8cPIz526e G/6KFXUghJ9SXWTzekgo8cZYJymTWrjVzxYBD1FAapNKjUnftMM2fr+IoQdFu49c+eZU ZlEJnoXI0bCVBj2mIS1ceTeL9i/KdTHy5gomQnDBKKSgQin+jDpn86+C/1fQ88IRWlCA 5g== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 38cjb9jym0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 May 2021 12:12:10 -0400 Received: from m0098416.ppops.net (m0098416.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 146GAmUD058180; Thu, 6 May 2021 12:12:10 -0400 Received: from ppma04dal.us.ibm.com (7a.29.35a9.ip4.static.sl-reverse.com [169.53.41.122]) by mx0b-001b2d01.pphosted.com with ESMTP id 38cjb9jykn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 May 2021 12:12:10 -0400 Received: from pps.filterd (ppma04dal.us.ibm.com [127.0.0.1]) by ppma04dal.us.ibm.com (8.16.0.43/8.16.0.43) with SMTP id 146G7mak027040; Thu, 6 May 2021 16:12:09 GMT Received: from b03cxnp08028.gho.boulder.ibm.com (b03cxnp08028.gho.boulder.ibm.com [9.17.130.20]) by ppma04dal.us.ibm.com with ESMTP id 38bedu05n5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 May 2021 16:12:09 +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 146GC8ks38076720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 6 May 2021 16:12:08 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1AB9878060; Thu, 6 May 2021 16:12:08 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0D66B7805C; Thu, 6 May 2021 16:12:03 +0000 (GMT) Received: from jarvis (unknown [9.80.192.238]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Thu, 6 May 2021 16:12:03 +0000 (GMT) Message-ID: 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: Dov Murik , Laszlo Ersek , devel@edk2.groups.io, brijesh.singh@amd.com Cc: Min Xu , Jiewen Yao , Tom Lendacky , Jordan Justen , Ard Biesheuvel , Erdem Aktas , "tobin@ibm.com" Date: Thu, 06 May 2021 09:12:01 -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: fb3tHP54i8g1hkQleABKQfSfsPT6djVT X-Proofpoint-GUID: 8Y00GdW80i1_dDPsgN6qaQJa8HYum5dp 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 priorityscore=1501 mlxlogscore=999 spamscore=0 clxscore=1015 mlxscore=0 malwarescore=0 adultscore=0 phishscore=0 bulkscore=0 lowpriorityscore=0 suspectscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2105060111 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Thu, 2021-05-06 at 13:57 +0300, Dov Murik wrote: > > On 05/05/2021 22:33, 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. > > > > The first use of the secret area was to hold the guest luks disk > passphrase; this is used in the grub-inside-OVMF (AmdSev package), > and there was no need to keep that page around for the guest kernel. > > The reason I'm raising this whole point is that we're working now on > guest-kernel support for reading secrets from that injected page (for > plain SEV). We considered either (a) modifying the secrets page > memory type to reserved here, or (b) add code to the kernel EFI stub > that would copy this page somewhere else for kernel's later use > (which seems more work and not sure what's the advantage). It mirrors the TPM boot log behaviour: the log is stored in boot time only memory, so the kernel EFI stub has to copy it out. The reason the TPM boot log behaves this way is that if the kernel didn't want to collect it, it still gets freed. I imagine a similar rationale exists for the boot secrets: if the kernel isn't interested in them for some reason, we don't want them to persist. > Option (b) seems harder and more fragile, and I'm not sure if there > are any advantages (though I'm definitely not an expert in that > area). I think forcing the kernel to consume the secret before exit boot services is still a good idea because 1. If the kernel can't consume the secret it gets freed 2. Not all secrets are consumed by the kernel, so it can pick the ones it wants out and discard the rest 3. If the kernel is using a secret protection mechanism, that may not work for the memfd page, so relocation of the secret might be a more secure mechanism. James