From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1kdeiT-0000Q2-Bn for mharc-grub-devel@gnu.org; Fri, 13 Nov 2020 14:26:37 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:59706) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kdeiR-0000OX-Lz for grub-devel@gnu.org; Fri, 13 Nov 2020 14:26:35 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:64314) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kdeiN-0006ir-Ba for grub-devel@gnu.org; Fri, 13 Nov 2020 14:26:35 -0500 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0ADJPTd9144257; Fri, 13 Nov 2020 14:26:28 -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=X4JEgFxob4dCKovD3G66jiHnKMNrnA6TqLRh795yqJU=; b=kfe5BY/su1dXU4TAcISUyQVwM4rLZqi+50HLTFdfk+7lAOrI0FxlhgOO90xJeyWrVLrO qktWI6xtwtScp6YaTScubz2XyH+DneYxmjzspgTtZRHFtaUY2fJkOT0NLygr68tr72MY 23E8Aci8lJUoT/S+UtjTLCtIyAGakYRaHoqc56ragQ2vkB790Aa9oxLJz18LKB+xewIG ig0EiCjhHVXuAQc+/XZK/F58+8hRSbBkaVEg+QOMDElIgVQvwUhGX8VuuRP8c3UDubJ0 eMbeS3eo58ZdtVyfeGQgeaqPPe3xOIbF1nTjxmSTK83ciiFilBWZYZDAxy7dAjM24SPU sw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 34t09sg0wm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Nov 2020 14:26:27 -0500 Received: from m0098394.ppops.net (m0098394.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 0ADJQR1m151081; Fri, 13 Nov 2020 14:26:27 -0500 Received: from ppma04wdc.us.ibm.com (1a.90.2fa9.ip4.static.sl-reverse.com [169.47.144.26]) by mx0a-001b2d01.pphosted.com with ESMTP id 34t09sg0w4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Nov 2020 14:26:27 -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 0ADJMCJw017025; Fri, 13 Nov 2020 19:26:26 GMT Received: from b03cxnp08028.gho.boulder.ibm.com (b03cxnp08028.gho.boulder.ibm.com [9.17.130.20]) by ppma04wdc.us.ibm.com with ESMTP id 34q5nfe860-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Nov 2020 19:26:26 +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 0ADJQMsX10355400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 13 Nov 2020 19:26:22 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CA60E78063; Fri, 13 Nov 2020 19:26:22 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BA88C7805C; Fri, 13 Nov 2020 19:26:20 +0000 (GMT) Received: from jarvis.int.hansenpartnership.com (unknown [9.85.145.64]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Fri, 13 Nov 2020 19:26:20 +0000 (GMT) Message-ID: <49be721f75e01ad45543c8a31fec0fae734b4bdf.camel@linux.ibm.com> Subject: Re: [PATCH 0/3] Add ability to use SEV provisioned secrets for disk decryption From: James Bottomley Reply-To: jejb@linux.ibm.com To: "Dr. David Alan Gilbert" Cc: grub-devel@gnu.org, 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 Date: Fri, 13 Nov 2020 11:26:19 -0800 In-Reply-To: <20201113182155.GT3251@work-vm> References: <20201113012206.24246-1-jejb@linux.ibm.com> <20201113175015.GS3251@work-vm> <16aa7a05356dc710ca18b5e954617cc9d4acd286.camel@linux.ibm.com> <20201113182155.GT3251@work-vm> 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_17:2020-11-13, 2020-11-13 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 malwarescore=0 bulkscore=0 mlxscore=0 lowpriorityscore=0 adultscore=0 impostorscore=0 priorityscore=1501 suspectscore=0 phishscore=0 spamscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011130123 Received-SPF: pass client-ip=148.163.156.1; envelope-from=jejb@linux.ibm.com; helo=mx0a-001b2d01.pphosted.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/13 14:26:29 X-ACL-Warn: Detected OS = Linux 3.x [generic] [fuzzy] 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: Fri, 13 Nov 2020 19:26:35 -0000 On Fri, 2020-11-13 at 18:21 +0000, Dr. David Alan Gilbert wrote: > * James Bottomley (jejb@linux.ibm.com) wrote: > > On Fri, 2020-11-13 at 17:50 +0000, Dr. David Alan Gilbert wrote: > > > * James Bottomley (jejb@linux.ibm.com) wrote: > > > > 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. 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. With all this in > > > > place, > > > > the sequence to boot an encrypted volume without user > > > > intervention > > > > is: > > > > > > > > sevsecret > > > > cryptomount -s > > > > source (crypto0)/boot/grub.cfg > > > > > > I was thinking what happens if the evil admin adds an extra disc; > > > I > > > guess the argument here is that: > > > a) Since you specify (crypto0) it can only be a decrypted disc > > > b) And since only the guest owner can supply the keys, it can > > > only > > > be there disc image that can be decrypted. > > > > > > Right? > > > > Right, cryptomount will mount as (cryptoN) only those devices which > > can > > actually be decrypted by the key. Since the initial grub.cfg is > > built > > into the grub that executes from the firmware volume only someone > > who > > knows the decryption key can substitute the booted volume. If you > > substitute an unencrypted volume, the grub.cfg script I constructed > > simply errors out (because it can't find any encrypted volumes) and > > reboots. The script is more complicated than the simple > > illustration > > above, but it's in this patch: > > > > https://edk2.groups.io/g/devel/message/67341?p=,,,20,0,0,0::Created,,PATCH+2%2F4,20,2,0,78198619 > > Hmm: > > +echo "Entering grub config" > +sevsecret > +if [ $? -ne 0 ]; then > + echo "Failed to locate anything in the SEV secret area, > prompting for = > password" > + cryptomount -a > +else > + cryptomount -s > + if [ $? -ne 0 ]; then > + echo "Failed to mount root securely, retrying with password > prompt" > + cryptomount -a > + fi > +fi > > if Eviladmin can make it fall down the cryptomount -a paths with one > of their own discs attached they can decrypt that and boot, and then > if they can later inject the original secret, then mount the original > disc. I think Brijesh said that the secret could be changed later; so > perhaps if the admin just stopped the secret being injected > initially, or caused the VM to start without waiting for the > injection, that would happen? In the current scheme the secret is destroyed after cryptomount -s fails, so you still wouldn't get access. But the grub.cfg is designed to be mutable ... if a distro wants a more secure sequence that doesn't try a fallback, it can construct one. James