>> 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 _______________________________________________ Help-grub mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-grub
