From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1kdldE-0003CD-Jg for mharc-grub-devel@gnu.org; Fri, 13 Nov 2020 21:49:40 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:55724) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kdldC-0003C2-S6 for grub-devel@gnu.org; Fri, 13 Nov 2020 21:49:38 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:34822 helo=mx0a-001b2d01.pphosted.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kdld8-0000Yd-PR for grub-devel@gnu.org; Fri, 13 Nov 2020 21:49:38 -0500 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 0AE2WNUY176044; Fri, 13 Nov 2020 21:49:30 -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=2B4pvwRYtOOaqEfbnP3MS87Q0CUvDtwOzTOpAQm+Ojg=; b=TaMX1YWIF13b8IG0WmfcYmGTwX6Cpk/CucF74t+cgFHIIw/HMHdyuPZRJB/c58rQ2lbO Hm4mz9Ln65WGas8iVoRLe25AwOFAT6QsuXka9iIoCT2c/5nibcB2k/9E6JrtdMqyRXfA 0WKQxC5rfZctKVQS4oeI91bxhLQmJRtP0FhXYn2bTIM+hg8X6Sd58GbRUKTt58rirbzl w0CGGP0wQzL6GbZoQ7WNrU420EZFFVX/8WoDaNq2SxF2ZKaMSX0JOzqhTguZQqT8SK+J oKdNdDA/D8p41tHVff5QBomBC5HWst/NipHyDY5K14csfqy7H8ay1fgowHmYuqZ/VC9X kA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 34t0hu8dyj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Nov 2020 21:49:30 -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 0AE2fpmb012020; Fri, 13 Nov 2020 21:49:29 -0500 Received: from ppma03dal.us.ibm.com (b.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.11]) by mx0b-001b2d01.pphosted.com with ESMTP id 34t0hu8dyg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Nov 2020 21:49:29 -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 0AE2fZAn028216; Sat, 14 Nov 2020 02:49:29 GMT Received: from b03cxnp07028.gho.boulder.ibm.com (b03cxnp07028.gho.boulder.ibm.com [9.17.130.15]) by ppma03dal.us.ibm.com with ESMTP id 34nk7an6nx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 14 Nov 2020 02:49:29 +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 0AE2nPL712190230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 14 Nov 2020 02:49:26 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 94098780AB; Sat, 14 Nov 2020 02:49:24 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 710507808E; Sat, 14 Nov 2020 02:48:31 +0000 (GMT) Received: from jarvis.int.hansenpartnership.com (unknown [9.85.145.64]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Sat, 14 Nov 2020 02:48:31 +0000 (GMT) Message-ID: <09df2068181c996d4417b6fe3e4fa14df17f2997.camel@linux.ibm.com> Subject: Re: [PATCH v2 0/3] Add ability to use SEV provisioned secrets for disk decryption From: James Bottomley Reply-To: jejb@linux.ibm.com To: The development of GNU GRUB 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" Date: Fri, 13 Nov 2020 18:48:30 -0800 In-Reply-To: <20201113195038.5d9dafa3@crass-HP-ZBook-15-G2> References: <20201113222510.16958-1-jejb@linux.ibm.com> <20201113195038.5d9dafa3@crass-HP-ZBook-15-G2> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.4 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-13_21:2020-11-13, 2020-11-13 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 bulkscore=0 priorityscore=1501 mlxscore=0 adultscore=0 phishscore=0 clxscore=1015 impostorscore=0 lowpriorityscore=0 malwarescore=0 mlxlogscore=999 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011140011 Received-SPF: pass client-ip=148.163.158.5; envelope-from=jejb@linux.ibm.com; helo=mx0a-001b2d01.pphosted.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/13 21:49:31 X-ACL-Warn: Detected OS = Linux 3.x [generic] X-Spam_score_int: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2020 02:49:39 -0000 On Fri, 2020-11-13 at 19:50 -0600, Glenn Washburn wrote: > On Fri, 13 Nov 2020 14:25:07 -0800 > James Bottomley wrote: > > > v2: update geli.c to use conditional prompt and add callback for > > variable message printing and secret destruction > > > > To achieve encrypted disk images in the AMD SEV encrypted virtual > > machine, we need to add the ability for grub to retrieve the disk > > passphrase from the SEV launch secret. To do this, we've modified > > OVMF to set aside an area for the injected secret and pass up a > > configuration table for it: > > > > https://edk2.groups.io/g/devel/topic/78198617#67339 > > > > The patches in this series modify grub to look for the disk > > passphrase > > in the secret configuration table and use it to decrypt any disks > > in > > the system if they are found. This is so an encrypted image with a > > properly injected password will boot without any user intervention. > > > > The three patches firstly modify the cryptodisk consumers to allow > > arbitrary password getters instead of the current console based > > one. > > I like this idea in general. > > > The next patch adds a '-s' option to cryptodisk to allow it to use > > a > > saved password and the final one adds a sevsecret command to check > > for > > the secrets configuration table and provision the disk passphrase > > from > > it if an entry is found. > > I'm not in favor of this approach. This feels like a special case of > providing a key file to cryptomount. We have working (and I believe > merge worthy) patches for adding key file support. Unfortunately, due > to the current position in the grub development cycle, they have not > been merged. As a side note, it might be interesting to re-work the > key file patch series to use the arbitrary password getter mechanism > you've created. > > What I would prefer, because it feels more generic, is to have the > sevsecret module create a procfs entry (perhaps (proc)/sevsecret), > which outputs the secret data when read (or NULL string if some error > in finding the secret). Then to cryptomount all devices that accept > the sev secret do: > > cryptomount -a -k (proc)/sevsecret > > In this case you could re-use most of the code in > grub_efi_sevsecret_find and creating the procfs entry would be > trivial (see bottom of cryptodisk.c for an example on how to do > this). A file interface feels slightly wrong for this. What we need is a use/release envelope ... effectively a way of enforcing the lifetime on the secret use. This allows a wider variety of threat models than the simply file model because the latter assumes an infinite lifetime (even though that can be hacked around using temporary filesystems). From a generality point of view it feels better to implement a file interface as a special case of a use/release model because it simply has an empty release function. If you follow this model, a file use case would have a special filesecret command and the use would go like: filesecret cryptomount -s > One potential issue could be getting error messages from > grub_efi_sevsecret_find back to the user and a solution could be to > replace the grub_error with grub_dprintf("sev", ...) statements and > set debug=sev unconditionally. In most cases no output would be > generated, but some debug log messages should be generated on error. Right, all this currently goes in the release function. > Also, if this series does end up adding an option to cryptomount, a > documentation patch should be added. I think we should start > documenting procfs paths as well. > > Also, out of curiosity, is it possible that there are multiple > GRUB_EFI_DISKPASSWD_GUID entries defined? You only get the first > one, but I'm wondering if the spec allows for more. Well, I'm currently defining the spec by proposing patches. I envisage the secret area would contain multiple secrets, some of which may be consumed before grub but a few may be consumed after grub by the OS. I also suspect if the cryptomount fails, it might be advisable to destroy the entire secrets area rather than just the grub passphrase, because failure to decrypt the /boot partition would indicate potential tamper attempts. Given the use case is an encrypted boot system on an untrusted cloud, I can't see any reason for having multiple grub passwords ... the image should only have a single /boot filesystem. James