From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1keFwA-0005K8-Kw for mharc-grub-devel@gnu.org; Sun, 15 Nov 2020 06:11:14 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:53548) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1keFw6-0005Js-Bx for grub-devel@gnu.org; Sun, 15 Nov 2020 06:11:10 -0500 Received: from new3-smtp.messagingengine.com ([66.111.4.229]:40023) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1keFw4-0007z4-CX for grub-devel@gnu.org; Sun, 15 Nov 2020 06:11:10 -0500 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id DFBF758009E; Sun, 15 Nov 2020 06:11:07 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 15 Nov 2020 06:11:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pks.im; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm2; bh=iU0KflrQLtKLdOGikiYsKB9NUJZ uYHxLEpoFXxkU8ag=; b=QODUBqPW+X+AORWxi4OvGfD9YHGq9feRM0QheSpO5an neiZ238asGD3Rft3t4THQgGx8UWlrdYRh/FF9rzok5ihIgmlwOBIwZg95MIX/21o 39WOPWUVyd0aWECd6Sk77e7w8m+vIbHvEdNFPy8U5YNOtfaSEXBVfZoaukYGeyDq cNe335wEe634zGkOuTa4s+ZKWhG2e3TT8AcrIDRLrE0033knp7caLGao6Ymxo4Qj AkSn+SVOaQzTiECChNYhdzRVpIf0nLZ93sx3VLzuUd/G0mN+dIkHnIBH3kO/TDXa MMADB9KNNctWni62PYct7v45yTMvIJL6kPygQp0jRxA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=iU0Kfl rQLtKLdOGikiYsKB9NUJZuYHxLEpoFXxkU8ag=; b=mhkUiSan7PPt4ZdaOjMpyM D7b8lguraAGtq5GlqSuzCXPAriKrC9+dRNeVrA/EAgnzoyz552Y0WuRvBLL4+ULE 1GmP0Un3z8htbT1tIQPYH5uZaYyuYZ7mlkwZyi5XQeNeDsQYn23hn3YN2tQaDRjJ rE/K761u2J/oPE6QRuWaW6f6HKdpKcdRvdurquYjuylWYAIIzkI0woM3rY0Qx/Q1 xgtZMhUVWdYGXiRsfyeUORhgt14bshhRQrtsY0GXJgMs71fe4niiKakJfT8ezRDf E5OSVw8f4BQinNfv30RM79AG2U/cAZ0GGDYlTW2O001Z2zhyWDK2zvmLhxWvbutA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddvledgvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpefrrghtrhhi tghkucfuthgvihhnhhgrrhguthcuoehpshesphhkshdrihhmqeenucggtffrrghtthgvrh hnpeetudffueetveekgffgtdekvefggedvtdegfefgffffgfeuffefveelheefgedvffen ucffohhmrghinhepghhrohhuphhsrdhiohdpghhnuhdrohhrghenucfkphepjeekrdehge drvddurddvtdeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepphhssehpkhhsrdhimh X-ME-Proxy: Received: from vm-mail.pks.im (dynamic-078-054-021-206.78.54.pool.telefonica.de [78.54.21.206]) by mail.messagingengine.com (Postfix) with ESMTPA id E8ABB3064AB2; Sun, 15 Nov 2020 06:11:04 -0500 (EST) Received: from localhost (ncase [10.192.0.11]) by vm-mail.pks.im (OpenSMTPD) with ESMTPSA id a6eada35 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sun, 15 Nov 2020 11:11:03 +0000 (UTC) Date: Sun, 15 Nov 2020 12:11:02 +0100 From: Patrick Steinhardt To: The development of GNU GRUB Cc: James Bottomley , 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" Subject: Re: [PATCH v2 0/3] Add ability to use SEV provisioned secrets for disk decryption Message-ID: References: <20201113222510.16958-1-jejb@linux.ibm.com> <20201113195038.5d9dafa3@crass-HP-ZBook-15-G2> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="y3pfgS4HgLcWRmGl" Content-Disposition: inline In-Reply-To: <20201113195038.5d9dafa3@crass-HP-ZBook-15-G2> Received-SPF: pass client-ip=66.111.4.229; envelope-from=ps@pks.im; helo=new3-smtp.messagingengine.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/15 06:07:07 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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: Sun, 15 Nov 2020 11:11:10 -0000 --y3pfgS4HgLcWRmGl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 13, 2020 at 07:50:38PM -0600, Glenn Washburn wrote: > On Fri, 13 Nov 2020 14:25:07 -0800 > James Bottomley wrote: >=20 > > v2: update geli.c to use conditional prompt and add callback for > > variable message printing and secret destruction > >=20 > > 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: > >=20 > > https://edk2.groups.io/g/devel/topic/78198617#67339 > >=20 > > 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. > >=20 > > The three patches firstly modify the cryptodisk consumers to allow > > arbitrary password getters instead of the current console based one. >=20 > I like this idea in general. >=20 > > 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. >=20 > 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. Ah, should've read all messages first. I'm now repeating kind of the same thing as a reply to patch 1/3. > 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: >=20 > cryptomount -a -k (proc)/sevsecret Interesting approach. I think I tend to agree, but I'm not too sure about potential security implications. Anyway, I still like the password callback function per-se as it nicely deduplicates existing code already. So regardless of where we end up here, I think that would be nice to have anyway. Patrick > 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). >=20 > 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=3Dsev unconditionally. In most cases no output would be > generated, but some debug log messages should be generated on error. >=20 > 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. >=20 > 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. >=20 > > With all this in place, the sequence to boot > > an encrypted volume without user intervention is: > >=20 > > sevsecret > > cryptomount -s > > source (crypto0)/boot/grub.cfg > >=20 > > Assuming there's a standard Linux root partition. > >=20 > > James >=20 > Glenn >=20 > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel --y3pfgS4HgLcWRmGl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEF9hrgiFbCdvenl/rVbJhu7ckPpQFAl+xDMUACgkQVbJhu7ck PpT3sw/+Naokjw0zF0JpAkeTOktrmTekYGMnuau/03Q5TXXSaY0lH5NJWEJR1sgP jsKSQb93LbBEssdPQkgz6SM1mEQuwu1McSAvc8NMko+AHgpcfCrYavm7zu3rz6DQ GgLCercbPtOsqCPm7kGFnHY5Q1JY3LOP8MpN2xmSDXCd4WPCoRFvgcu79yu+stu3 yXKBC1tMv9w6PeuBpbf60woFzeJT/hg4lxSFPz//31tQEFc2CjbQfQaAvvGmhnEg 9ukx0QPGj2GOHLuhR1xWtY/XGMKR8+8eOKRwNBo1PgtyR6EY7UePUvbfwciABbog 8rDRPoIMfh5VWxjbPOk1E2K5gNOmtssBIDNNtvIQ4f4e4EU4bCYtR83mHTScYNCR RbFbq6L0hU20XBYIWy/a5kkXh+5Wj427h81O1jBNFq+tQwWModKRs1nnXLCtWTVb wasS5JesBGNrpd/g6X1W79Rd/g+0yAM+jFxA2jEDBq7+ly4oez+Es32D7j/UNN5s 2mRb2VRaHEXIw7Piy7uuMrxvOKg85LO3/WrHsch5X4DUVJURz2znLwJPPNIY5fHu Gcc8V2uxSqi2gqvOxAbCW00NmVaOf1IyT/khRJ+hTvslktD6BvLyOIOZQgt5B5Nj OEEerVZyhbOEUZcIv28vnkAIfuDPpVSHjZ/9Eu3Rxa0CXXxyANI= =5+P5 -----END PGP SIGNATURE----- --y3pfgS4HgLcWRmGl--