Re: [PATCH 1/7] Cryptomount support LUKS detached header

[John Lane]

On 14/03/18 13:05, Daniel Kiper wrote:
> On Wed, Mar 14, 2018 at 09:44:58AM +0000, John Lane wrote:
>> From: John Lane <address@hidden>
> 
> I have just skimmed through the series. First of all, most if not
> all patches beg for full blown commit messages. Just vague statements
> in the subject are insufficient for me. And please add patch 0 which
> introduces the series. git send-email --compose is your friend.
> 
> Daniel
> 

Sorry Daniel, this isn't something I do that often - submitting patches
to ML. Do you want me to resubmit them again, or is the below ok for you ?



These patches provide extensions to the "cryptomount" command. There are
my original five patches, plus an additional two patches from other
contributors who sent pull requests.

 [PATCH 1/7] Cryptomount support LUKS detached header
 Support LUKS detached headers so that the header can be separated from
the data payload, e.g. by storing on external removable media such as a
USB key.

 [PATCH 2/7] Cryptomount support key files
 Support key files so that passphrase entry can be suppressed. The
passphrase can be stored in a "key file" that can be stored, for
example, on external removable media such as a USB key.

 [PATCH 3/7] cryptomount luks allow multiple passphrase attempts
 Allow a second attempt to enter a passphrase. If unlocking fails on the
first attempt then the user is presented with the passphrase entry
prompt again. If a key file is given that does not unlock the device
then the user is given the opportunity to enter a passphrase.

This feature was added following feedback from Andrei Borzenkov back in
2015 when I first submitted these patches.

 [PATCH 4/7] Cryptomount support plain dm-crypt
 Support plain dm-crypt mode. Allow plain volumes to be opened. This is
largely a re-factoring of exisitng code to allow the crypto routines be
used independently of LUKS.

 An important thing to recognise with this patch is that it largely
moves code from luks to cryptodisk so that it can be used outside of
luks (i.e. as plain dm-crypt). The crypto implementation was not changed
- most of the code in this patch already existed.

A little explanation of what the patch does:

I extracted the in-line code from "luks.c" that creates the crypto disk
into a new cryptomount function called "grub_cryptodisk_create" that is
then used by the luks module and is also avilable to the cryptomount
module.

I extracted the "set_passphrase" function from the "devmapper.c"
committed (e7f405ab) in the "peter/devmapper" branch so that I could use
it in cryptomount to hash a manually entered passphrase.

I then wrote some additional options and a small block of code to
implement plain mode using the above.


 [PATCH 5/7] Cryptomount support for hyphens in UUID
 Support for hyphens in UUID. The "-u" option of cryptomount accepts a
UUID. This option allows that to be delimited with hyphens so that the
same format can be given to Grub as is passed to the Linux kernel boot
options.

Contributor patches

 [PATCH 6/7] Retain constness of parameters.
  Don't drop constness on the parameters since they are being only read
anyway. Without this patch, compilation may fail if the compiler
complains that the constness of passed in parameters is being dropped.

 [PATCH 7/7] Add support for using a whole device as a keyfile
 This fixes the situation where a device is passed as a parameter to
--keyfile instead of the path to a file.

It is probably worth reviewing the email threads beginning with [1] and
[2], and especially my reply [3] in which I answer FAQs about this work.
discusses the self-generation (grub-mkconfig) aspects of this,
especially with respect to plain mode (there isn't any - but I had some
ideas in that mail about how it could possibly be achieved).

[1] http://lists.gnu.org/archive/html/grub-devel/2015-06/msg00109.html
[2] http://lists.gnu.org/archive/html/help-grub/2017-02/msg00017.html
[3] http://lists.gnu.org/archive/html/help-grub/2017-02/msg00029.html

end