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

[Mat628]

You may already be aware of this but I guess to make it clearer for others. In 
both cases only one grub.cfg is needed to boot and requires no chainloading.
Two distinctions should be made if trying to boot a computer with LVM on LUKS 
with detached header with/without /boot/grub/(grub.cfg) residing inside the 
encrypted device.

First (with): If /boot/grub/(grub.cfg) is encrypted then as far as I know only 
the boot.img and core.img are stored unencrypted and only they are responsible 
for unlocking the LUKS device. This is accomplished with the limited modules 
inside the core.img along with load.cfg. Load.cfg is created by grub-install so 
the system can gain access when booting to /boot/grub/(grub.cfg) and the needed 
modules. Then once the LUKS device is unlocked then grub.cfg can take over 
because only at that point it is unencrypted. Now at this point all of the 
commands that mattle_opts.cfg copied into grub.cfg are not actually needed 
since they were already called prior to unencrypting /boot/grub/(grub.cfg). 
Then it finishes booting like an unecrypted computer.

Second (without): If /boot/grub/(grub.cfg) is not encrypted then as far as I 
know load.cfg is not needed because the commands from mattle_opts.cfg are 
loaded into grub.cfg and since /boot/grub/(grub.cfg) is in plain text it can be 
freely loaded and then it will call the necessary modules and commands to 
unlock the LUKS device and finish booting.

>if the grub boot loader is capable of retrieving the header file using the 
>search.fs directives, then why would you need to manually feed it to 
>grub-install? Wouldn't grub-install be capable of doing the same, ie. read the 
>contents of in this case mattle_opts.cfg and also find the header file that 
>way?

You're correct that at boot using search.fs/pt modules and setting environment 
variables it can find the header file and the LUKS device with detached header. 
But those modules literally search every device until it matches it with the 
users input of the (part)uuid of the device and sets that device to the 
environment variable. In turn we use that variable to act as the device name 
when using cryptomount. That approach is top down.

So to do it in reverse it would require parsing the mattle_opts.cfg and then 
matching environment variables to (part)uuid's and then matching that to the 
header file name.

The example shown is a simple one with only one cryptomount. It is possible if 
the user wants to they could have the header file and key files stored inside 
another (multiple) LUKS device that needs to be opened prior to unlocking the 
LUKS device with detached header. i.e. if the system required 2 people to be 
present one with the header file in a LUKS device and one with the keyfile in a 
LUKS device. Which leads to multiple search.fs/pt commands along with multiple 
cryptomount commands.

>You state that the only reason for passing the options to grub-install is for 
>it to know which modules to load based on the actual header file contents.

That is not the only reason, the main reason is to "reconnect" the detached 
header to the LUKS device (only in memory, the header is not wrote back to the 
disk) so that grub-install and the rest of grub-utils will be able to properly 
find the root device and get the proper abstractions and from then on treat the 
LUKS device as normal. i.e. as if it were not detached from its header.

>You also state somewhere that a little bit of a difficulty exists if you want 
>to install to two devices after one another; requiring the editing of 
>mattle_opts.cfg in between.

Yes I mentioned a little bit of difficulty but to mitigate having to change 
${prefix}/etc/mattle_opts.cfg for an alternate install to device. I added 
another command to both grub-install and grub-mkconfig to allow the user to use 
an alternate file.

i.e. default: the user installs to usb_disk_1 with the header/keyfiles on that 
disk.

Then wants to install to usb_disk_2 as a backup device which also has a copy of 
the header/keyfiles on it. Then the user makes a file that has the correct 
search.fs/pt commands to be able to find the files on usb_disk_2 and then uses 
that alternate file for that grub-install and grub-mkconfig call only.

default setup: ${prefix}/etc/mattle_opts.cfg

search.fs_uuid uuid-of-usb-disk-1 usb_header_f
search.pt_uuid partuuid-of-detached-luks-device luks_device
cryptomount ($luks_device) --header=/($usb_header_f)/header_luks.bin
-----------
mount /dev/sdb1 /mnt/usb_disk_1
grub-install --crypto-device=/dev/sda1 
--crypto-header=/mnt/usb_disk_1/sda1_header.bin /dev/sdb
-----------

alternate setup: usb_disk_2_opts.cfg

search.fs_uuid uuid-of-usb-disk-2 usb_header_f
search.pt_uuid partuuid-of-detached-luks-device luks_device
cryptomount ($luks_device) --header=/($usb_header_f)/header_luks.bin
-----------
mount /dev/sdc1 /mnt/usb_disk_2
grub-install --crypto-device=/dev/sda1 
--crypto-header=/mnt/usb_disk_2/sda1_header.bin 
--mattle-opts-file=/usb_disk_2_opts.cfg /dev/sdc
-----------
>So this makes me believe at this point that mattle_opts.cfg is authorative in 
>the sense that you will need to match the grub-install parameters with it 
>*anyway*.

No it is not in that if I want to install the boot.img and core.img to 
usb_disk_1 but have my files on usb_disk_2 all that is needed is for 
mattle_opts.cfg to have the correct entries to find the files on usb_disk_2.

It is not necessary that the --crypto-header file that is used for grub-install 
have the same path as the file used at boot. It must be a copy of it but it 
does not need to be the same path. i.e for grub-install header_file.bin is on 
'/' but when booting a copy is on usb_disk_1 as shown above. This is one reason 
why its okay to install to usb_disk_1 but have the files on usb_disk_2. Or if 
the user wants to have the header file on one device and the keyfile on another 
device.

>I assume grub.cfg is also read by grub-install (or /etc/default/grub or 
>whatever) and even though ${prefix}/etc/mattle_opts.cfg is only (?) referenced 
>in grub-mkconfig_lib.in it would just seem to be that you have now two 
>separate types of config that you need to keep in sync?

grub.cfg (boot/grub/grub.cfg) is not read by grub-install or grub-mkconfig, for 
anything I have done.

Yes, ${prefix}/etc/mattle_opts.cfg is only referenced in that form in 
grub-mkconfig_lib.in but it is also referenced in grub-install.c as 
GRUB_SYSCONFDIR, "mattle_opts.cfg" where GRUB_SYSCONFDIR is defined 
as'${prefix}/etc'. But to make it clearer and for consistency I will change it 
to ${prefix}/etc'.

/etc/default/grub and ${prefix}/etc/mattle_opts.cfg dont need to be kept in 
sync. /etc/default/grub is read by both grub-install and grub-mkconfig in order 
to see if GRUB_ENABLE_CRYPTODISK_MATTLE_OPTS=y. If that is set then my 
additional features are allowed to be used including the reading, copying and 
pasting of mattle_opts.cfg into load.cfg and grub.cfg.

> The contents of mattle_opts.cfg are fprintf'ed into load.cfg which is
inside core.img.

>But that is done by grub-install right.

Yes that is done by grub-install.

I understand that for standard LUKS device setup it is easier. But with my 
added features to grub-install/mkconfig and the added search_pt_uuid module 
along with john lanes crypto enhancements it also allows for use with plain 
dm-crypt and the extra features for keyfiles including offsets. Where having 
the mattle_opts.cfg file makes it easier when using it with those options.