From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by mx.groups.io with SMTP id smtpd.web11.7499.1605200847834380687 for ; Thu, 12 Nov 2020 09:07:28 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=pYQvwOWP; spf=pass (domain: linux.ibm.com, ip: 148.163.156.1, mailfrom: jejb@linux.ibm.com) Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0ACH3Y59128504; Thu, 12 Nov 2020 12:07:20 -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=Usa+kabABcKHiMUlh2vSPSDjspffYyNYyUhOW1Q5aMw=; b=pYQvwOWPDKL3jYPWmo1/24mcY0GZs9kxeunnXKRhlxR+5SAureSw0KAWmk0gHN5Qsiz8 G2oeitwlMXWhnHuZkEVaAdzbG+1oG/3UfvjBZ+ETyMFx8yRp6EbUrokBzxppO1dHbtFn fjLG7a1L6O4hklOszK7rth00hv11SiTKkXkhoMUc+JKOus6P8C7LiKPRhOeQqJRgypGB CCH2qOWFtOt9C6Y5e+3HC9+jqrcO8eVPiIfbEKMHZIjbrxdkXtv+kO8mVRcalgytDyRQ +n6Qni95qs1IbGAW2B84/1wVI9Gk28i2fS4AAcdn+K0UX3LaX61vghDQEueHmfKMrAEO iQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 34s7m3kuc3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 12 Nov 2020 12:07:20 -0500 Received: from m0098399.ppops.net (m0098399.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 0ACH42sV130874; Thu, 12 Nov 2020 12:07:20 -0500 Received: from ppma03dal.us.ibm.com (b.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.11]) by mx0a-001b2d01.pphosted.com with ESMTP id 34s7m3kubj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 12 Nov 2020 12:07:19 -0500 Received: from pps.filterd (ppma03dal.us.ibm.com [127.0.0.1]) by ppma03dal.us.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 0ACGpU1o007419; Thu, 12 Nov 2020 17:07:19 GMT Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by ppma03dal.us.ibm.com with ESMTP id 34nk7a6k0s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 12 Nov 2020 17:07:19 +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 0ACH76JG14156368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 12 Nov 2020 17:07:06 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D22D57805E; Thu, 12 Nov 2020 17:07:14 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CB27E78067; Thu, 12 Nov 2020 17:07:12 +0000 (GMT) Received: from jarvis.int.hansenpartnership.com (unknown [9.85.145.64]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Thu, 12 Nov 2020 17:07:12 +0000 (GMT) Message-ID: <6285626e5b22fbbf78b15d21dcc17adf9ed0e21e.camel@linux.ibm.com> Subject: Re: [PATCH 0/4] SEV Encrypted Boot for Ovmf From: James Bottomley Reply-To: jejb@linux.ibm.com To: "Dr. David Alan Gilbert" , Ashish Kalra Cc: devel@edk2.groups.io, dovmurik@linux.vnet.ibm.com, Dov.Murik1@il.ibm.com, brijesh.singh@amd.com, tobin@ibm.com, david.kaplan@amd.com, jon.grimm@amd.com, thomas.lendacky@amd.com, frankeh@us.ibm.com Date: Thu, 12 Nov 2020 09:07:11 -0800 In-Reply-To: <20201112163434.GH2905@work-vm> References: <20201112001316.11341-1-jejb@linux.ibm.com> <20201112162117.GA3223@ashkalra_ubuntu_server> <20201112163434.GH2905@work-vm> 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-12_07:2020-11-12,2020-11-12 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 adultscore=0 lowpriorityscore=0 mlxlogscore=961 suspectscore=0 phishscore=0 impostorscore=0 mlxscore=0 bulkscore=0 malwarescore=0 clxscore=1015 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011120100 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Thu, 2020-11-12 at 16:34 +0000, Dr. David Alan Gilbert wrote: > * Ashish Kalra (ashish.kalra@amd.com) wrote: > > On Wed, Nov 11, 2020 at 04:13:12PM -0800, James Bottomley wrote: > > > From: James Bottomley > > > > > > 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. > > > > > > Concept: SEV Secure Encrypted Images > > > ==================================== > > > > > > The SEV patches in Linux and OVMF allow for the booting of SEV > > > VMs in an encrypted state, but don't really show how this could > > > be done with an encrypted image. > > > > A basic question here ... the SEV usage model in which the firmware > > is encrypted and loaded into VM using LAUNCH_UPDATA_DATA and then > > measurement is provided and attestation is done with the VM owner > > and after VM owner verifies measurement, the VM owner encrypts the > > disk encryption key and sends it to the guest and it is injected > > into the guest using the LAUNCH_SECRET API, which is then used to > > decrypt the OS encrypted image, won't this work to start the SEV VM > > with an encrypted image ? > > That's still what James system does, but the problem is maintaining a > chain of trust from the set of measured binaries to the point at > which you can use the injected secret. > > On the current OVMF world we end up measuring the OVMF binary, but > not the stored variable flash; but then what? Who would read the > injected secret? Because SEV/SEV-ES has no way of performing a later > attestation, or updating the measurements, we have no way of > following the path from OVMF (possibly via variables) to a boot > loader, to a filesystem. Right, the specific problem is our current linux boot sequence goes OVMF->grub->linux But OVMF can only execute things on an unencrypted vFAT filesytem, so if grub is on vFAT there's no way to prevent a cloud admin substituting the grub binary after attestation is done and the key released if we only attest OVMF, so the bogus grub binary could simply capture the key and transmit it to a hacker. Pulling grub inside OVMF allows us to attest both OVMF and grub as one entity and also prevents the boot going via the unencrypted vFAT filesystem, eliminating the potential interception point. James