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.web11.12664.1605221434140399176 for ; Thu, 12 Nov 2020 14:50:34 -0800 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@ibm.com header.s=pp1 header.b=tHaqjZzE; 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.42/8.16.0.42) with SMTP id 0ACMWLPt022712; Thu, 12 Nov 2020 17:50:32 -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=VxV153sqF3gJb/Niq5sHZRPFze4k6n+y2h6wb3F2fQM=; b=tHaqjZzE7Lz/I4qwQdydaVTYIZKqDbi+clXOtSmz3sTQO0FFNmSfGfjS7w0maC0DVBHk mWvacx3DMZWZGGsBN+tHB96Heu6ZCT49rtXP/5HO8KT2hH/wGaofrep0khrvtm152XQ5 Qsh7WDZ3JAu7/D7HcSoKtpOC5Q2QKdAHQDeOszpAsZ6wiKFGFXgNcGvbGstBgz/LoCcy n0ERRB7Qrf0vnpYMccb058CcM/hju832SojB9Fddzx4x5viNK2cPZ7BR1j5e4kG9mlxB IInvycTYd6hZuGlpUjvH4fTprPxhOqiefwh3+ldGDcqF99x5h+do2oI53PnZWiZKy/05 yA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 34sdx60cy8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 12 Nov 2020 17:50:32 -0500 Received: from m0098413.ppops.net (m0098413.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 0ACMWF2F022637; Thu, 12 Nov 2020 17:50:32 -0500 Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0b-001b2d01.pphosted.com with ESMTP id 34sdx60cxx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 12 Nov 2020 17:50:32 -0500 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 0ACMgDbU016688; Thu, 12 Nov 2020 22:50:31 GMT Received: from b03cxnp08028.gho.boulder.ibm.com (b03cxnp08028.gho.boulder.ibm.com [9.17.130.20]) by ppma01dal.us.ibm.com with ESMTP id 34nk7b1mu6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 12 Nov 2020 22:50:31 +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 0ACMoSvV14942758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 12 Nov 2020 22:50:28 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1054C7805F; Thu, 12 Nov 2020 22:50:28 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0E2D77805C; Thu, 12 Nov 2020 22:50:25 +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 22:50:25 +0000 (GMT) Message-ID: Subject: Re: [PATCH 0/4] SEV Encrypted Boot for Ovmf From: James Bottomley Reply-To: jejb@linux.ibm.com To: Brijesh Singh , "Dr. David Alan Gilbert" Cc: devel@edk2.groups.io, dovmurik@linux.vnet.ibm.com, Dov.Murik1@il.ibm.com, ashish.kalra@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 14:50:24 -0800 In-Reply-To: <5890c3a4-a480-0ca7-55fd-550a91d8ecb1@amd.com> References: <20201112001316.11341-1-jejb@linux.ibm.com> <5cb9e43e-b22f-0ffc-3b02-1b173454de9f@amd.com> <20201112193804.GJ2905@work-vm> <5890c3a4-a480-0ca7-55fd-550a91d8ecb1@amd.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-11-12_13:2020-11-12,2020-11-12 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 adultscore=0 bulkscore=0 clxscore=1015 priorityscore=1501 impostorscore=0 spamscore=0 phishscore=0 mlxlogscore=999 suspectscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011120126 X-MIME-Autoconverted: from 8bit to quoted-printable by mx0b-001b2d01.pphosted.com id 0ACMWLPt022712 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2020-11-12 at 15:56 -0600, Brijesh Singh wrote: > On 11/12/20 1:38 PM, Dr. David Alan Gilbert wrote: > > * Brijesh Singh (brijesh.singh@amd.com) wrote: > > > Hi James, > > >=20 > > > Thanks for series, I glanced at it, the changes looks okay to me. > > > I have one questions. > > >=20 > > > How does the grub locate the disk decryption key ? Am I correct > > > in assuming that the gurb is iterating through a configuration > > > table entries and comparing the Secret GUID to locate the secret > > > key. As per the SEV spec, its possible that a guest owner can > > > call the secret injection more than once. I don't see the patch > > > consider that case, should we support this or limit to one > > > inject?=C3=82 Maybe Qemu can enforce this property. > > That's interesting, I hadn't realised that was possible - however, > > I can't see a way to use it - for it to be useful, you would have > > to have a way for the guest to communicate to the owner that it had > > finished with the first injection and would like the next; but if > > you already have a way to communicate from the guest to the owner > > to request stuff, then you could pass a new secret by that comms > > route? >=20 > The main reason for its existence was to allow guest owner to inject > multiple blocks of the data if they need to do so, e.g IIRC, Enarx > folks use this to inject the keep which is much bigger than 128K. In some ways this sounds like the wrong approach. I mean we could use injection to inject the entire VM image as well, but we don't, we inject the key and decrypt the image ... it does rather sound like that's what should be happening for other bulk data, like the keep. If you do it this way you can use the main CPU and bulk memory encryption to pull the data into the secure memory rather than using the PSP, which is a lot slower. Also one of the problems with having OVMF define the secret location is that we have to find space in the MEMFD. For a single page like the current implementation uses, that's easy, but for tens to hundreds of pages it would be impossible. Even if we guid describe everything, standard aes keys are 16-32 bytes, so even in the worst case we can fit 85 guid described decryption keys in a page, which should be more than enough for anyone, provided we inject the key to the bulk data, not the bulk data itself. > I am not sure if we really need it for the VM boot flow but we > probably need to define the secret page layout such that it contains > multiple entries in it. In our case the Secret can't be more than a > page, so, we can define a secret page layout such that it can contain > more than one disk key. I was thinking about something like this >=20 > typedef enum { >=20 > DISK_KEY_AES_128, >=20 > SSH_PRIVATE_KEY, >=20 > ... >=20 > } data_type; >=20 > struct secret_data { >=20 > u8 entries; >=20 > struct { >=20 > data_type type; >=20 > u16 len; >=20 > u8 name[16]; >=20 > u8 data[]; >=20 > } entry[]; >=20 > } >=20 > This should allow us to package multiple secrets in one inject. I proposed something slightly different in a prior email. If we use the guid approach, we don't have to define the data structure a-priori ... just the producer and consumer have to agree on what it is. > > > Do you see any need for the Linux kernel needing to access the > > > secret? Since the secret blob is available through configuration > > > table, I believe we can have a platform driver that can read the > > > configuration table and retrieve the secret blob. > > I guess it depends if you get the Grub to pass the fs secret down > > to the kernel or let it pick it up itself from the same place. >=20 > I guess the main reason why I was asking this is, what if guest owner > provides more than one disk keys in the secret injection blob. Grub > can use the boot disk key to access the Linux images and other disk > keys may later be used by Linux. Right, see other email for limitations. James