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.web12.8757.1607528829449906051 for ; Wed, 09 Dec 2020 07:47:09 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=lVb5TFdC; spf=pass (domain: linux.ibm.com, ip: 148.163.158.5, mailfrom: jejb@linux.ibm.com) Received: from pps.filterd (m0098414.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0B9FXav3130891; Wed, 9 Dec 2020 10:47:05 -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=9Ql+Pd67xg4Lrfo++DqpMqIgWf9mid7ZDMbFp6mebOA=; b=lVb5TFdC46jjXvNTB1OjU1y2YWXmwF3fy6omroaChy+arZdi1tOGmPWN4Nc1IHuwE+Zv 7lVXBRe+j/jcH2WC6DEcGBvrg62/DsjAh/yWPXAecTv0hjUzVg06Tgrep24F+fKOJlmH e0M0jeZHQFhkJQlVfKUy5D3eWQrcO3VleT4aVKe07EvSrxTbGd5mJb/rC3PGj/VTI3y2 s60jdzpTUig7e3kTDmJB5IfAdwv5pdaG71Mvli4UX048U5V5MVRUsGfp8UGePrUs8QP0 Djqt3z4GpcZuq7yS94FS2uQ8uuhEaV/8/4vEq5MtW8+H/7QSn4qDXBFbVWG/n2Xus4CH yg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 35avmu9ygs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Dec 2020 10:47:05 -0500 Received: from m0098414.ppops.net (m0098414.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 0B9FXhXX131473; Wed, 9 Dec 2020 10:47:04 -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 35avmu9yge-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Dec 2020 10:47:04 -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 0B9FRwZH009869; Wed, 9 Dec 2020 15:47:04 GMT Received: from b03cxnp08025.gho.boulder.ibm.com (b03cxnp08025.gho.boulder.ibm.com [9.17.130.17]) by ppma01dal.us.ibm.com with ESMTP id 3581u9gpdn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Dec 2020 15:47:04 +0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp08025.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 0B9Fl0ON19857808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 9 Dec 2020 15:47:00 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 69BE578066; Wed, 9 Dec 2020 15:47:00 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CC47678064; Wed, 9 Dec 2020 15:46:57 +0000 (GMT) Received: from jarvis.int.hansenpartnership.com (unknown [9.85.183.17]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Wed, 9 Dec 2020 15:46:57 +0000 (GMT) Message-ID: Subject: Re: [edk2-devel] [PATCH v3 6/6] OvmfPkg/AmdSev: Expose the Sev Secret area using a configuration table From: "James Bottomley" Reply-To: jejb@linux.ibm.com To: devel@edk2.groups.io, jiewen.yao@intel.com 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 , "Justen, Jordan L" , Ard Biesheuvel Date: Wed, 09 Dec 2020 07:46:56 -0800 In-Reply-To: References: <20201130202819.3910-1-jejb@linux.ibm.com> <20201130202819.3910-7-jejb@linux.ibm.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.343,18.0.737 definitions=2020-12-09_13:2020-12-09,2020-12-09 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 mlxlogscore=999 spamscore=0 lowpriorityscore=0 impostorscore=0 priorityscore=1501 mlxscore=0 malwarescore=0 suspectscore=0 adultscore=0 clxscore=1011 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012090108 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Wed, 2020-12-09 at 12:02 +0000, Yao, Jiewen wrote: > Hi James > I am not sure if this solution is only for AMD SEV or it is a generic > solution to "pass a secret to grub and let grub decrypt the disk". Well, being open source, it's driven by the implementation, which is AMD. However, if you look at how it works, it's composed of a secret discovery piece and then a packaging piece which is this part. It's certainly true that any discover mechanism could feed this packaging piece, so I agree that the SecretDXE could pass up the secret from any discovery mechanism not just SEV. > If it is only for AMD SEV, please stop reading and ignore my comment > below. > > If it is designed to be a generic solution to pass a secret to grub > and let grub decrypt the disk. I have some thought below: > Intel TDX ( > https://software.intel.com/content/www/us/en/develop/articles/intel-trust-domain-extensions.html > ) have similar feature - a TDX virtual firmware may do attestation > and get a key from remote key server. > We might use same architecture to pass the secrete to grub. > Initially, we define an ACPI 'SVKL' table to pass the secrete in > intel-tdx-guest-hypervisor-communication-interface ( > https://software.intel.com/content/dam/develop/external/us/en/documents/intel-tdx-guest-hypervisor-communication-interface.pdf > ), section 4.4 storage volume key data. > But it is also OK if you want to use UEFI configuration table. >>From the coding point of view it's definitely easier to do a UEFI configuration table. If I had to insert something inside ACPI I'd be hijacking a lot more of the guts of OVMF to achieve it. > If we need a common API for both AMD SEV and Intel TDX, then I > recommend some enhancement for SevLaunchSecret.h. > 1) The file name (SevLaunchSecret.h) should be generic, such as > TrustedVmSecret, StorageVolumeKey, etc. It should not include 'SEV'. > Otherwise, we have to define a new GUID for 'TDX'. > 2) The GUID name (gSevLaunchSecretGuid, SEV_LAUNCH_SECRET_GUID) > should be generic. Same reason above. > 3) The data structure name (SEV_LAUNCH_SECRET_LOCATION) should be > generic. Same reason above. > 4) The data structure field (SEV_LAUNCH_SECRET_LOCATION.Base) should > use UINTN or EFI_PHYSICAL_ADDRESS to support above 4GB memory > location. I agree with trying to make it more generic. what about replacing SEV_LAUNCH with CONFIDENTIAL_COMPUTING SevLaunch with ConfidentialComputing And obviously making the area a UINT64. > 5) The internal data structure of the secret is not defined. Is it > raw binary? Or ASCII string password? Or DER format certificate? Or > PEM format key? At least, we shall describe it in the header file. Since OVMF doesn't interpret the area, I didn't describe it in this patch, but if you look at how the grub piece works: https://lists.gnu.org/archive/html/grub-devel/2020-11/msg00081.html It's another GUIDed list, so all I've defined is a GUID that means "this is a disk password". You can define a guid for any other content type. > 6) The might be a chance that a key server need input multiple keys > to a trusted VM. How we handle this? Do we expect multiple UEFI > configuration tables and each table support one key? or one table to > support multiple keys? The keys would each have their own guid which would be pieced up by the receiver. > Would you please take a look at intel-tdx-guest-hypervisor- > communication-interface, section 4.4 storage volume key data. > We defined multiple key layout, key type and key format. Please let > us know if you have any thought. I really think the standard GUIDed form: GUID|len|data Works best because a GUID is big enough to define for any number of uses and it also means we don't have to define key types or anything, because all a new consumer has to do is define their data structure and give it a guid. The single uefi config table is passed through to all the elements until it gets to one that recognizes the GUID. James