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.9928.1605210294952616158 for ; Thu, 12 Nov 2020 11:44:55 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=URu1T4q/; spf=pass (domain: linux.ibm.com, ip: 148.163.158.5, mailfrom: jejb@linux.ibm.com) Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0ACJWKEC175448; Thu, 12 Nov 2020 14:44:52 -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=wucgp6CUAL6+UpuSx4bIVvDxRVLwU3/IrFaFTyLvLQg=; b=URu1T4q/EfYaMRF0xrYQb5KjOJS/kIkRbUSyct2ldoDWCFkV6rRe/wgVNHCe5STvzW6W ieiuVy9Jhv7mfwADRV05jodSiE4VLGNz9hwWXTsEzUIOcpFrBM43xV8ETWskmIHRXaUO dBjnqguV6cq0Cdz5kItIiuyMGwytE6jL/KAYYOYsgYk8s1s0IWikGOtMq1naB6m1vnlE 9AHzb8rlRQWHmEfIYtD/qQrzpsMd7dI5lAmngldnuxWoPKlu6hJOdA2hE5cS4XyVSVFY o9Xd4QNPs0acn7avpo8Z3K5kU6RWws2PLict+yIYPRcSCWFz5dGOO9bUUWhbQBJbDKmO Kg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 34s47yfuct-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 12 Nov 2020 14:44:52 -0500 Received: from m0098419.ppops.net (m0098419.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 0ACJWYFQ176373; Thu, 12 Nov 2020 14:44:52 -0500 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 34s47yfucm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 12 Nov 2020 14:44:52 -0500 Received: from pps.filterd (ppma04wdc.us.ibm.com [127.0.0.1]) by ppma04wdc.us.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 0ACJeJnf001243; Thu, 12 Nov 2020 19:44:51 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 34q5nf62eq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 12 Nov 2020 19:44:51 +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 0ACJimeT17695284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 12 Nov 2020 19:44:48 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 44E0078064; Thu, 12 Nov 2020 19:44:48 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 34F5A78063; Thu, 12 Nov 2020 19:44:46 +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 19:44:45 +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 , devel@edk2.groups.io Cc: 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, "Dr . David Alan Gilbert" Date: Thu, 12 Nov 2020 11:44:44 -0800 In-Reply-To: <5cb9e43e-b22f-0ffc-3b02-1b173454de9f@amd.com> References: <20201112001316.11341-1-jejb@linux.ibm.com> <5cb9e43e-b22f-0ffc-3b02-1b173454de9f@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_10:2020-11-12,2020-11-12 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 mlxscore=0 suspectscore=0 priorityscore=1501 adultscore=0 lowpriorityscore=0 malwarescore=0 spamscore=0 phishscore=0 bulkscore=0 clxscore=1015 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011120113 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Thu, 2020-11-12 at 11:32 -0600, Brijesh Singh wrote: > Hi James, > > Thanks for series, I glanced at it, the changes looks okay to me. I > have > one questions. > > 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? Maybe Qemu can > enforce this property. Well in the original patch, grub recognized the secret in the area by the prefix "PASSWORD:". I think that's a bit fragile, so I was planning to rework the grub patch to do everything by guid, so the secrets table itself would have its own guid which would be followed by the entire table length. Then the entries in the table would have the format |guid|len|data| So every consumer first of all validates the table by the initial guid and gets the total length then iterates over the entries to see if its interested in any of them. The format of |data| would be up to the consumer. > 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've only been really concentrating on the grub use case. However, as you saw in my reply about migration, we likely also need an entry so that the migration helper can pick up its ECDH identity. The scheme would definitely cover passing a secret to the kernel as well. The one caveat there is that the HOB that covers the secret is boot time, so the secret would have to be extracted in the kernel EFI stub before ExitBootServices() is called. I suppose nothing really prevent the HOB from becoming runtime except the security maxim that you want all secret lifetimes to be as short as possible. James