From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Z3qfX-0004fQ-IS for mharc-grub-devel@gnu.org; Sat, 13 Jun 2015 15:00:39 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58034) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z3qfU-0004eo-45 for grub-devel@gnu.org; Sat, 13 Jun 2015 15:00:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z3qfQ-0001p4-Rn for grub-devel@gnu.org; Sat, 13 Jun 2015 15:00:36 -0400 Received: from johnlane.plus.com ([212.159.104.145]:65136 helo=sodium.amajohn.co.uk) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z3qfQ-0001oF-HA for grub-devel@gnu.org; Sat, 13 Jun 2015 15:00:32 -0400 Received: by sodium.amajohn.co.uk (Postfix, from userid 1000) id ABAC488D; Sat, 13 Jun 2015 20:00:21 +0100 (BST) Received: from [10.0.200.1] (hydrogen.amajohn.co.uk [10.0.200.1]) by sodium.amajohn.co.uk (Postfix) with ESMTPSA id 95FD8855; Sat, 13 Jun 2015 20:00:20 +0100 (BST) Message-ID: <557C7DB7.3060408@jelmail.com> Date: Sat, 13 Jun 2015 20:00:07 +0100 From: John Lane User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Andrei Borzenkov Subject: Re: Patches to cryptomount (plain support, keyfiles and LUKS detached headers) References: <548EC66C.2050006@jelmail.com> <54C165DD.4010109@gmail.com> <557B2FD4.1030604@jelmail.com> <20150613082749.383fc60f@opensuse.site> In-Reply-To: <20150613082749.383fc60f@opensuse.site> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9CW79Qw4kfGPmG0m3fcNcipxqToIun4nr" X-Outbound-Checked: Yes X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 212.159.104.145 Cc: grub-devel@gnu.org X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 19:00:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9CW79Qw4kfGPmG0m3fcNcipxqToIun4nr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 13/06/15 06:27, Andrei Borzenkov wrote: > =D0=92 Fri, 12 Jun 2015 20:15:32 +0100 > John Lane =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >>> Sorry, we cannot accept patches which aren't sent to this ml by autho= r. >> I've attached the patches here. They apply clean to c945ca75. > Sending them as patch series in mail body would make it easier to > review and comment on them. Ok, sure I'll do that. please bear with me... I'll re-jig the patches so that the plain-mode stuff is separated. May be a delay as I'll need to find the time to do it. > >>> I'm not sure that all features are good. For starters plain mode is j= ust >>> difficult to setup and use. Please provide usecases not already cover= ed >>> by current features. >> My target was to establish LUKS volumes with detached headers and key >> files and this is not already covered by current features. >> >> My specific use-case is booting secured systems where the boot >> environment (Grub, LUKS headers and keys) is contained on removable >> media such as a USB key. The non-removable hard-drive has no boot code= >> on it; it just appears as an unformatted disk unless the removable key= >> is used. >> >> To support this, it was necessary to add support to Grub for detached >> LUKS headers and keys. >> >> I am aware of a number of other people enquiring about this specific >> functionality so I am not alone in thinking it's a valid use-case. >> >> Regarding plain mode, I don't understand why plain mode is "difficult= >> to setup and use". I did the work on plain mode at the same time becau= se >> one of the disks that I needed to work with was a plain mode disk. I >> asked about the existing but non-functioning "peter/devmapper" branch >> and spent some time trying to get that to work. In the end, and as I >> understand how LUKS uses dm-crypt, it seemed better to re-use the >> existing code base in the cryptodisk routines because this is more >> current, used and tested. By doing that I was able to get it to work >> very quickly. >> > The problem is not coding it. It is impossible to identify plain mode > crypto-containers at run time. So it depends on user knowing (or > guessing) which of disks to use. It is pure manual stuff which cannot > be integrated in GRUB grub-install or grub-mkconfig. > > You have 5 disks each encrypted with different key that are plain/use > detached header. How can you setup GRUB to automatically find out the > right key/header for each disk? > > I personally would appreciate keyfile support as separate patch, not > buried in plain mode support. Especially if it would be accompanied by > grub-mkconfig changes to automate generation of grub.cfg to use it.=20 I'll separate the plain from LUKS stuff as said above... might take a little while to find some time though... >> I've been using my changes in daily use since my original postings las= t >> December. I've just updated to the latest head and the patches still >> merge cleanly. >> >> I'd appreciate it if these changes could be considered. If any more >> information would be useful please let me know. >> > >> @@ -488,6 +496,7 @@ grub_cryptodisk_open (const char *name, grub_disk_= t disk) >> =20 >> if (grub_memcmp (name, "cryptouuid/", sizeof ("cryptouuid/") - 1) =3D= =3D 0) >> { >> + grub_crypto_uuid_dehyphenate((char *)name + sizeof ("cryptouuid= /")); > This alters original name passed to grub_disk_open. As already > mentioned it is better to use comparison function that ignores hyphens.= The reason I did it that way was because it was easy, coming from the point of view that I was only getting to know the code-base. I simply converted the uuid at the first opportunity into the format that the existing code base expects. That way the rest of the code can carry on as if a uuid without hyphens was presented. I thought that was pretty harmless given that the dehyphenate function does nothing to a uuid that has no hyphens in it. Anyway, I will resubmit the patch by email as described above - we can discuss it further under that... > --9CW79Qw4kfGPmG0m3fcNcipxqToIun4nr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVfH3CAAoJEGnTYCRabxPGT8EP/R441tTmoVzpsdbnRj1FXLmw MzfImmUdd1JQQjOrwyuo8rqezDbiMRc6UtSqpJLcyh6x/B6sJKKysOk2uVkzomy4 2O8biJhfvny0+HyxTh3pLitaEZqyNBth+kAYDGwUN9bFo8rdGd4DxlyIV3QZvnbw fM4VYdDtX62Ymvh6NFSOO3//RKi8dwfw7/RB0uZt0wT4VeXFff95xFV74mYPfrPK MTNW/IWD0E9Xcl+dAXcspS4TJQD6p/R3gVLnKniZPc99gBHOqzIj44WHluv+B1P+ xEPyuJ/PMV2XDoi5HyLMIhavXulMQn/jIWFkpvHmGhnng4ENNOi0h8gfi5BeDDbB A8PAKf0GhPfD7FN5zAQE1Z1HgnKEyw/VXM4lKrBiXVzLKjbmgpcRmT9AnVNnWmmZ 8VvaRRdUYtISkWDVcXD4dNB+BcoEmCNAKNFWoIbeReCpxAyCPEPzUNZ2oMNNjwAU dWqObrpgVFqPixyUxkUEV47tcJFQ27zmCIGgk2Qp+mD7/AmeUWI798AenlNu6er0 YA4hCxHlUBW1Qsnq2JIsElCgJ3vm2GL0A+5U5cekVUI9Druvg1FurrKVoG9k+zil GaTw3/XckogJO1/QKDwkK+vxUw5MqFVY+uC8FlmvprAxrgwKWZRNO4fEcZsEMsVs 1Fz/B4wCvdyCJPJn5Aqt =5WGJ -----END PGP SIGNATURE----- --9CW79Qw4kfGPmG0m3fcNcipxqToIun4nr--