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.11796.1606836436093070634 for ; Tue, 01 Dec 2020 07:27:16 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=SIgMvCfk; spf=pass (domain: linux.ibm.com, ip: 148.163.158.5, mailfrom: jejb@linux.ibm.com) Received: from pps.filterd (m0127361.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0B1FAQJs162759; Tue, 1 Dec 2020 10:27:11 -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=nJ4KW9KOx+BfU95EP17pWAMXDCxmYyKNwtkCxKVy+t4=; b=SIgMvCfkb11Do45PUdpm6rBfwPITIuFOKNJG2k1kk5PjH/a2gw/S/PjPinRwJXpGu9mL 2sAWa7xCyhHvZ79LdNIVzbGD9kkbN5akA81o+7ZOgWVSqCWiIblM0dcSkBSAtru9nqjq OphQIXOXHbHEqhXWVc8HPHMHCx3Ua9xiu+vCuq6MTtv2rBLuftswzNTc8J3qpwd2eQQU QVrkG7bOn4RuHU2+UrcB31z/FqCpmQn3fClum+khCSbDqA31vn6Ks6DPoFFBIlVI1Usv xAymI0aUV/IWzoP6mr+Qe0BItXMSjBBdYTH5rRZDBaF6fTrrLnpiKCYlx11UtJ8I4dDi mg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 355k18hf4n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 01 Dec 2020 10:27:10 -0500 Received: from m0127361.ppops.net (m0127361.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 0B1FATe0162876; Tue, 1 Dec 2020 10:27:03 -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 355k18hf18-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 01 Dec 2020 10:27:02 -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 0B1FGfiS031233; Tue, 1 Dec 2020 15:26:51 GMT Received: from b03cxnp07028.gho.boulder.ibm.com (b03cxnp07028.gho.boulder.ibm.com [9.17.130.15]) by ppma04dal.us.ibm.com with ESMTP id 353e697e3p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 01 Dec 2020 15:26:51 +0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp07028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 0B1FQlS824314156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 1 Dec 2020 15:26:47 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A99A078064; Tue, 1 Dec 2020 15:26:47 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4751C7805E; Tue, 1 Dec 2020 15:26:44 +0000 (GMT) Received: from jarvis.int.hansenpartnership.com (unknown [9.80.201.242]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Tue, 1 Dec 2020 15:26:43 +0000 (GMT) Message-ID: <2e64cf912acfe5aa7cc9c9b1303ccd910faaf6f8.camel@linux.ibm.com> Subject: Re: [PATCH v3 0/6] SEV Encrypted Boot for Ovmf From: "James Bottomley" Reply-To: jejb@linux.ibm.com To: Ard Biesheuvel , 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" , Laszlo Ersek , Jordan Justen Date: Tue, 01 Dec 2020 07:26:42 -0800 In-Reply-To: <2f0c10ac-d4b1-0873-0ef2-aeeea9b0d001@arm.com> References: <20201130202819.3910-1-jejb@linux.ibm.com> <2f0c10ac-d4b1-0873-0ef2-aeeea9b0d001@arm.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-12-01_07:2020-11-30,2020-12-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 phishscore=0 adultscore=0 priorityscore=1501 lowpriorityscore=0 impostorscore=0 suspectscore=0 bulkscore=0 mlxlogscore=999 clxscore=1015 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012010093 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Tue, 2020-12-01 at 09:05 +0100, Ard Biesheuvel wrote: > On 11/30/20 9:28 PM, James Bottomley wrote: > > v3: > > > > - More grub and boot stripping (I think I got everything out, but > > there may be something that strayed in the boot panic > > resolution). > > - grub.sh tidy up with tabs->spaces. > > - Move the reset vector GUIDisation patch to the front so it can be > > applied independently > > - Update the .dsc and .fdf files for variable policy > > > > v2: > > > > - Strip more out of AmdSev image (networking, secure boot, smm) > > - give sev reset block a generic table guid and use it for boot > > secret area > > - separate secret patches and make grub script more robust > > - Add copyrights and fix formatting issues > > > > v1: > > > > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077 > > > > This patch series is modelled on the structure of the Bhyve patches > > for Ovmf, since it does somewhat similar things. This patch series > > creates a separate build for an AmdSev OVMF.fd that does nothing > > except combine with grub and boot straight through the internal > > grub to try to mount an encrypted volume. > > > > This all looks reasonable to me, although I defer to Laszlo when it > comes to assessing the impact on maintainability of other platforms > under OvmfPkg. > > Acked-by: Ard Biesheuvel > > Is there any point to keeping the TPM bits in the AmdSev platform? > Or are these completely orthogonal? If there is no meaningful way > [yet] to plumb these together, it might be better to just rip that > out entirely so people don't make assumptions. There is definitely a use case in the cloud for an attested VM boot and run time whether that VM is encrypted or not. Although the SEV attestation covers OVMF/grub it would still be useful to get the regular boot time attestation from them as well, so I think OVMF will require a TPM device even in the SEV use case. Obviously there is still a question of how you run a vtpm in this use case, since it would have to be part of the trusted envelope as well, so it can't simply run in the host like vtpms usually do. However, SEV-SNP is moving towards the concept of a trusted management VM, so I do envisage that the vtpm would eventually be part of this or another set up like it so it would be separate from the encrypted VM that's running but part of the trusted envelope. James