Re: Support for plain dm-crypt and detached LUKS header

[John Lane]

>> So, what is the state of supporting plain dm-crypt?

Hi, I originally posted the patches referred to in this thread and I
thought I would offer my opinion into this discussion, FWIW, because
there has been a fair amount of interest in the patches.

I have just confirmed that the patches apply cleanly to the current HEAD
(8736a048) and have done a quick boot test to verify my build of that
version. The latest patches (updated April 2016) remain available at
http://grub.johnlane.ie for anyone who wants them.

> As was discussed, having separate grub module that implements it would
probably be OK with understanding that user has to configure it manually;

The modules that my patches apply to are `cryptodisk` and `luks`. The
crypto routines implemented in `luks` were moved into `cryptodisk` so
that they could be used without LUKS (given LUKS is based on dm-crypt
this seemed a logical and sensible approach).

The important thing to note here is that I introduced no new crypto code
(I did not use the pre-existing attempt to implement dm-crypt that
remains in the 'peter/devmapper' branch).

I feel that separating the crypto routines into a new dm-crypt module
and thereby duplicating the crypto routines would add confusion and
widen the scope for bugs or vulnerabilities to appear. I think it is
safer to stick with the existing, tested, code that is known to work.
Hence why I did it that way.

The user has to configure dm-crypt manually (even with the patches I
provided). I think, given the nature of dm-crypt, this is a fair
requirement. I made no changes to the grub.cfg auto-generation code
whatsoever.

>> Why create separate module? It appears (I may be wrong) that this
functionality can be provided by existing module.

It can indeed.

> cryptsetup works with self-identifying containers which dm-crypt is not.

It also works with 'plain' containers. Granted, you can't auto-generate
config for them but I would suggest that, for those wishing to use these
advanced features, they are already in the do-it-yourself category.
Writing a custom grub.cfg is not difficult.

> full fledged support including grub-install magic is likely not
possible at all.

I don't think, given the required parameters for a dm-crypt volume, that
there would be any reasonable way to auto-generate config for them. But
I don't see the problem with that. I think it's an acceptable trade-off
for those wishing to use plain-mode dm-crypt. With this functionality
added, people have a choice.

There is the issue that you can't reliably predict what a device hd1,1
will map to. But I did have a thought about that but never went as far
as trying to do it. On Linux, devices are mapped to a hardware-specific
path such as

    ata-ST31500341AS_7VS1GB18
    ata-ST31500341AS_7VS1GB18-part1

where the components are the device's model number and serial number.
You could imagine doing something (by hand) in grub.cfg like this

    cryptomount -p ata-ST31500341AS_7VS1GB18
or
    cryptomount -p ata-ST31500341AS_7VS1GB18,1

I wouldn't know how to implement such a scheme myself though.

I'm sure there must be valid reasons why these patches weren't taken on
board despite my trying to accommodate all feedback received when I
originally submitted them, but it is a fact that people do find them
useful and that suggests to me that it would be welcomed by many if some
more thought could be put into taking them on board.

In the meantime, they remain available at http://grub.johnlane.ie and on
Github at https://github.com/johnlane/grub.

Best regards,
John Lane