Generated grub.cfg does not support encrypted roots

  • Done
  • quality assurance status badge
Details
3 participants
  • Andreas Enge
  • Ludovic Courtès
  • Christopher Baines
Owner
unassigned
Submitted by
Ludovic Courtès
Severity
important

Debbugs page

L
L
Ludovic Courtès wrote on 6 Nov 2015 07:52
(address . bug-guix@gnu.org)
87twozi0ql.fsf@gnu.org
As reported by 宋文武 at

Follow the manual to setup encryted root, using the desktop.scm
template, but
at the final step, it failed with:

Path '/mnt/boot/grub' is not readable by GRUB on boot.
Installation is impossible. Aborting.

(can be reproduced by `grub-install /dev/sdb --boot-directory
/mnt/boot')

After search, it seems that an un-encrypted boot partition is needed:


So, I run fdisk to add a boot partiotion, finally install finished!

But it can't boot, I have to mount the encrypted root in Grub's cmdline:

insmod cryptodisk
insmod luks
cryptomount hd0,msdos2

Ludo’.
L
L
Ludovic Courtès wrote on 29 Feb 2016 06:24
control message for bug #21843
(address . control@debbugs.gnu.org)
8760x7h9wj.fsf@gnu.org
severity 21843 important
A
A
Andreas Enge wrote on 8 Mar 2016 11:21
Re: bug#21843: Generated grub.cfg does not support encrypted roots
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 21843@debbugs.gnu.org)
20160308192104.GA22722@solar
I tried the installation with unencrypted /boot, encrypted / using the
following snippet in the configuration file:
(bootloader (grub-configuration (device "/dev/sda")))
(mapped-devices (list (mapped-device
(source "/dev/sda2")
(target "root")
(type luks-device-mapping))))
(file-systems (cons* (file-system
(device "/dev/mapper/root")
(title 'device)
(mount-point "/")
(type "ext4")
(needed-for-boot? #t))
(file-system
(device "boot")
(title 'label)
(mount-point "/boot")
(type "ext4")
(needed-for-boot? #t))
%base-file-systems))

Grub did not start, as it did not find the kernel etc. in /gnu/store.

So I typed "c" at the grub menu (in text mode without the splash screen,
which also resides in /gnu/store), and issued the following two commands:
insmod luks
cryptomount hd0,msdos2

This prompted me for the password a first time. The "insmod cryptodisk" was
not necessary. There was a new device called "(crypto0)" now; "ls (crypto0)/"
showed, among others, the /gnu directory.

Now I still needed to define the kernel; running "boot" was not enough.

I executed
configfile (hd0,msdos1)/grub/grub.cfg
and now obtained the normal grub menu (with the splash screen) and could now
boot as usual. I was prompted a second time for the password.
According to the grub.cfg, grub searches for the kernel by file name and
uses the device where it is found automatically as root. So the second time
it must also have searched (crypto0).


This can be automated; I just added the two lines
insmod luks
cryptomount hd0,msdos2
to the top of grub.cfg, and the next time everything worked out of the box
(with two password prompts: the first one in text mode before grub was visibly
started, then the grub splash screen appeared, then during the normal boot).

The only difficulty here is the mapping between the mapped-device /dev/sda2
and the grub device hd0,msdos2. We would need to determine this automatically
when creating the grub.cfg during the call to "guix system init".


Maybe UUIDs can help. The command
crytsetup luksUUID /dev/sda2
returns a hex string with dashes, in my case 1aa...-...
This could be run during "guix system init" with the source field of
mapped-device.
The grub manual at:
mentions a device syntax such as
(cryptouuid/123456789abcdef0123456789abcdef0)
I tried replacing
cryptomount hd0,msdos2
by
cryptomount cryptouuid/1aa...
(without the dashes), but this did not work.
The strange thing is that grub somehow knows this uuid; when I type
cryptomount hd0,msdos2
I am presented with the prompt
Enter passphrase for hd0,msdos2 (1aa...):

So I am stuck here.


A first tentative solution would be to look for mapped-devices of type
luks-device-mapping that correspond to file-systems with needed-for-boot?
set to #t, and then add the corresponding "cryptomount" lines to grub.cfg,
with the obvious mapping sda->hd0, sdb->hd1,..., and 1->msdos1, 2->msdos2
and so on.

This would not be perfect, but at least better than what we have now.

And the line "insmod luks" could be added unconditionally (or only in the
presence of a mapped-device of type luks-device-mapping).

Andreas
A
A
Andreas Enge wrote on 8 Mar 2016 11:33
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 21843@debbugs.gnu.org)
20160308193309.GA2251@solar
What is needed are the following two lines at the beginning of grub.cfg:

insmod luks
cryptomount -u 1aa...

where 1aa... is the result of "cryptsetup luksUUID /dev/sda2".

So the logic outlined in my previous message works:
Determine the mapped-devices /dev/sdXY of type luks-device-mapping that
lead to a file-system with needed-for-boot? set to #t.
Using
cryptsetup luksUUID /dev/sdXY
determine a corresponding uuid 12345...0.
If any such mapped-device exists, add
insmod luks
as the first line of grub.cfg. For any such mapped-device, add a line
cryptomount -u 12345...0
right after that.

To simplify the logic, we could also move the needed-for-boot? parameter
to mapped-device, or add such a parameter there.

Andreas
L
L
Ludovic Courtès wrote on 10 Mar 2016 01:17
(name . Andreas Enge)(address . andreas@enge.fr)(address . 21843@debbugs.gnu.org)
8760wuy9mt.fsf@gnu.org
Andreas Enge <andreas@enge.fr> skribis:

Toggle quote (19 lines)
> What is needed are the following two lines at the beginning of grub.cfg:
>
> insmod luks
> cryptomount -u 1aa...
>
> where 1aa... is the result of "cryptsetup luksUUID /dev/sda2".
>
> So the logic outlined in my previous message works:
> Determine the mapped-devices /dev/sdXY of type luks-device-mapping that
> lead to a file-system with needed-for-boot? set to #t.
> Using
> cryptsetup luksUUID /dev/sdXY
> determine a corresponding uuid 12345...0.
> If any such mapped-device exists, add
> insmod luks
> as the first line of grub.cfg. For any such mapped-device, add a line
> cryptomount -u 12345...0
> right after that.

IIUC we don’t *have* to pass the UUID to ‘cryptomount’; we could also
pass the device name, in GRUB format, which would allow us to use the
same strategy as in ‘grub-root-search’ in (gnu system grub)… with the
difficulty that we’d have to be able to map Linux /dev node names to
GRUB device names.

Furthermore, to allow users to specify a LUKS UUID as the ‘source’ of
their ‘mapped-device’ form, as in:

(mapped-device
(source (uuid "cb67fc72-0d54-4c88-9d4b-b225f30b0f44")) ;LUKS UUID
(target "root")
(type luks-device-mapping))

we’d have to extend <mapped-device-kind> with a method to resolve UUIDs
(in this case, to map a UUID to a /dev node.)

Thoughts? Looks like more work than I initially thought.

Besides, I think we should only worry about the mapped device(s) that
back / and /boot, rather than any mapped device, no?

Thanks for looking into it,
Ludo’.
A
A
Andreas Enge wrote on 10 Mar 2016 01:48
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 21843@debbugs.gnu.org)
20160310094837.GA30197@solar
On Thu, Mar 10, 2016 at 10:17:46AM +0100, Ludovic Courtès wrote:
Toggle quote (3 lines)
> IIUC we don’t *have* to pass the UUID to ‘cryptomount’; we could also
> pass the device name, in GRUB format

Yes, but my idea was that the uuid is something we can determine
at instantiation time. If the mapped device is /dev/sdd3, we can run
(system* "cryptsetup" "luksUUID" "/dev/sdd3")
and obtain the uuid.

I suppose we could also use the grub device (hd3,msdos3) in this case,
but I do not know what is the mapping between /dev nodes and these devices,
and if it is actually a function that could be computed from the file name
in /dev only or not.

Toggle quote (7 lines)
> (mapped-device
> (source (uuid "cb67fc72-0d54-4c88-9d4b-b225f30b0f44")) ;LUKS UUID
> (target "root")
> (type luks-device-mapping))
> we’d have to extend <mapped-device-kind> with a method to resolve UUIDs
> (in this case, to map a UUID to a /dev node.)

We can also let the users do the work (and document this in the manual),
by having them supply all the informatin:

(mapped-device
(source "/dev/sdd3")
(uuid "cb67fc72-0d54-4c88-9d4b-b225f30b0f44") ;LUKS UUID
(target "root")
(type luks-device-mapping)
(needed-for-boot? #t))

Toggle quote (3 lines)
> Besides, I think we should only worry about the mapped device(s) that
> back / and /boot, rather than any mapped device, no?

This could either be solved by determining which file systems have
needed-for-boot? #t and determine the corresponding mapped devices,
or by adding such a parameter for the mapped-device as in my suggestion
above.

Or we do it all automatically for / and /boot and drop the parameter
needed-for-boot? everywhere.

Andreas
L
L
Ludovic Courtès wrote on 11 Mar 2016 00:45
(name . Andreas Enge)(address . andreas@enge.fr)(address . 21843@debbugs.gnu.org)
87r3fh4d4c.fsf@gnu.org
Andreas Enge <andreas@enge.fr> skribis:

Toggle quote (9 lines)
> On Thu, Mar 10, 2016 at 10:17:46AM +0100, Ludovic Courtès wrote:
>> IIUC we don’t *have* to pass the UUID to ‘cryptomount’; we could also
>> pass the device name, in GRUB format
>
> Yes, but my idea was that the uuid is something we can determine
> at instantiation time. If the mapped device is /dev/sdd3, we can run
> (system* "cryptsetup" "luksUUID" "/dev/sdd3")
> and obtain the uuid.

Hmm yeah, but we don’t even do that for regular partitions.

Toggle quote (5 lines)
> I suppose we could also use the grub device (hd3,msdos3) in this case,
> but I do not know what is the mapping between /dev nodes and these devices,
> and if it is actually a function that could be computed from the file name
> in /dev only or not.

‘grub-probe’ should know, I think.

Toggle quote (17 lines)
>> (mapped-device
>> (source (uuid "cb67fc72-0d54-4c88-9d4b-b225f30b0f44")) ;LUKS UUID
>> (target "root")
>> (type luks-device-mapping))
>> we’d have to extend <mapped-device-kind> with a method to resolve UUIDs
>> (in this case, to map a UUID to a /dev node.)
>
> We can also let the users do the work (and document this in the manual),
> by having them supply all the informatin:
>
> (mapped-device
> (source "/dev/sdd3")
> (uuid "cb67fc72-0d54-4c88-9d4b-b225f30b0f44") ;LUKS UUID
> (target "root")
> (type luks-device-mapping)
> (needed-for-boot? #t))

I think the goal of providing a UUID is to not have to worry about the
actual device name (which could change).

The ‘needed-for-boot?’ flag should be unnecessary because it can be
inferred from corresponding file systems, as is already the case.

Toggle quote (11 lines)
>> Besides, I think we should only worry about the mapped device(s) that
>> back / and /boot, rather than any mapped device, no?
>
> This could either be solved by determining which file systems have
> needed-for-boot? #t and determine the corresponding mapped devices,
> or by adding such a parameter for the mapped-device as in my suggestion
> above.
>
> Or we do it all automatically for / and /boot and drop the parameter
> needed-for-boot? everywhere.

We keep it only in ‘file-system’, I think.

Anyway, sounds like quite a bit of work here. :-)

Ludo’.
A
A
Andreas Enge wrote on 16 Mar 2016 13:40
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 21843@debbugs.gnu.org)
20160316204000.GA8709@solar
On Thu, Mar 10, 2016 at 10:17:46AM +0100, Ludovic Courtès wrote:
Toggle quote (9 lines)
> Furthermore, to allow users to specify a LUKS UUID as the ‘source’ of
> their ‘mapped-device’ form, as in:
> (mapped-device
> (source (uuid "cb67fc72-0d54-4c88-9d4b-b225f30b0f44")) ;LUKS UUID
> (target "root")
> (type luks-device-mapping))
> we’d have to extend <mapped-device-kind> with a method to resolve UUIDs
> (in this case, to map a UUID to a /dev node.)

I just read a bit of the cryptsetup manual; we do not need to do the
resolution, in the above example we would have the line
cryptomount -u cb67fc72-0d54-4c88-9d4b-b225f30b0f44
(as discussed previously; it works at least without the dashes, we can also
try to keep the dashes).
And then it should be possible to open the device with
cryptsetup luksOpen UUID=cb67fc72-0d54-4c88-9d4b-b225f30b0f44 root
This looks for the given uuid in /dev/disk/by-uuid.

I wanted to give it a try with the installation image, but unfortunately it
does not contain the directory /dev/disk.

Andreas
A
A
Andreas Enge wrote on 17 Mar 2016 06:14
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 21843@debbugs.gnu.org)
20160317131435.GA12731@solar
On Wed, Mar 16, 2016 at 09:40:00PM +0100, Andreas Enge wrote:
Toggle quote (12 lines)
> I just read a bit of the cryptsetup manual; we do not need to do the
> resolution, in the above example we would have the line
> cryptomount -u cb67fc72-0d54-4c88-9d4b-b225f30b0f44
> (as discussed previously; it works at least without the dashes, we can also
> try to keep the dashes).
> And then it should be possible to open the device with
> cryptsetup luksOpen UUID=cb67fc72-0d54-4c88-9d4b-b225f30b0f44 root
> This looks for the given uuid in /dev/disk/by-uuid.
>
> I wanted to give it a try with the installation image, but unfortunately it
> does not contain the directory /dev/disk.

I tried it out with an already installed (and reconfigured, but that should
not make a difference) GuixSD, and the above "cryptsetup" line works as well
(with the dashes).

Andreas
L
L
Ludovic Courtès wrote on 16 Apr 2016 09:09
(address . 21843@debbugs.gnu.org)
878u0dfscg.fsf@gnu.org
ludo@gnu.org (Ludovic Courtès) skribis:

Toggle quote (6 lines)
> Path '/mnt/boot/grub' is not readable by GRUB on boot.
> Installation is impossible. Aborting.
>
> (can be reproduced by `grub-install /dev/sdb --boot-directory
> /mnt/boot')

On this topic, see the story about ‘grub-probe’ at:


Ludo’.
L
L
Ludovic Courtès wrote on 17 Apr 2016 16:29
(name . Andreas Enge)(address . andreas@enge.fr)(address . 21843@debbugs.gnu.org)
87potnlsq5.fsf@gnu.org
ludo@gnu.org (Ludovic Courtès) skribis:

Toggle quote (11 lines)
> Furthermore, to allow users to specify a LUKS UUID as the ‘source’ of
> their ‘mapped-device’ form, as in:
>
> (mapped-device
> (source (uuid "cb67fc72-0d54-4c88-9d4b-b225f30b0f44")) ;LUKS UUID
> (target "root")
> (type luks-device-mapping))
>
> we’d have to extend <mapped-device-kind> with a method to resolve UUIDs
> (in this case, to map a UUID to a /dev node.)

Commit ffba7d498d36618ad21af3961a1a685ae91bae57 makes it possible,
building on ‘find-partition-by-luks-uuid’ added in
a1ccefaa122df7c0045eda1fe6b65d83b65ed238.

(Tested on my system where /home is LUKS-encrypted.)

Ludo’.
L
L
Ludovic Courtès wrote on 27 Apr 2016 13:58
(name . Andreas Enge)(address . andreas@enge.fr)(address . 21843@debbugs.gnu.org)
87y47ywyy4.fsf@gnu.org
Andreas Enge <andreas@enge.fr> skribis:

Toggle quote (5 lines)
> What is needed are the following two lines at the beginning of grub.cfg:
>
> insmod luks
> cryptomount -u 1aa...

The attached patch does exactly that when the ‘mapped-device’ source is
a UUID, as is the case with the modified bare-bones.tmpl example:
Attachment: file
A good way to test it (not as root!) is:

Toggle snippet (7 lines)
$ ./pre-inst-env guix system reconfigure gnu/system/examples/bare-bones.tmpl
/gnu/store/fm8lbh7r3j05bkd6kbnc9xwph6rmy0rz-system
/gnu/store/9l0dfdxj7ybck63r9zrgnxbyryn6f0kh-grub.cfg
/gnu/store/myrc5cinlhpj2yilhzv5y0szz2ax2i6z-grub-2.00
guix system: error: symlink: Mankas permeso: "/var/guix/profiles/system-192-link"

The generated grub.cfg whose name appears above has this entry:

Toggle snippet (9 lines)
menuentry "GNU with Linux-Libre 4.5.2 (beta)" {
insmod luks
cryptomount -u cb67fc72-0d54-4c88-9d4b-b225f30b0f44
search --file --set /gnu/store/dd2qbz6a5pszwnzay3s8mm9yim531nz0-linux-libre-4.5.2/bzImage
linux /gnu/store/dd2qbz6a5pszwnzay3s8mm9yim531nz0-linux-libre-4.5.2/bzImage --root=/dev/mapper/foo --system=/gnu/store/fm8lbh7r3j05bkd6kbnc9xwph6rmy0rz-system --load=/gnu/store/fm8lbh7r3j05bkd6kbnc9xwph6rmy0rz-system/boot
initrd /gnu/store/fm8lbh7r3j05bkd6kbnc9xwph6rmy0rz-system/initrd
}

Now, I haven’t tested this in reality and would appreciate help here.

We may have to add the patch to ‘guix-devel’ in (gnu packages
package-management) to test it.

Ludo’.
L
L
Ludovic Courtès wrote on 1 May 2016 14:29
control message for bug #21843
(address . control@debbugs.gnu.org)
871t5la2lw.fsf@gnu.org
tags 21843 patch
L
L
Ludovic Courtès wrote on 1 May 2016 15:07
Re: bug#21843: Generated grub.cfg does not support encrypted roots
(address . 21843@debbugs.gnu.org)
87vb2x8mac.fsf@gnu.org
ludo@gnu.org (Ludovic Courtès) skribis:

Toggle quote (2 lines)
> Now, I haven’t tested this in reality and would appreciate help here.

I’m in the process of implementing automated tests for the installation
process.

Ludo’.
C
C
Christopher Baines wrote on 25 Oct 2016 23:56
7778a48f-1d46-9fb6-dfa3-92e398f0bbeb@cbaines.net
On 01/05/16 23:07, Ludovic Courtès wrote:
Toggle quote (7 lines)
> ludo@gnu.org (Ludovic Courtès) skribis:
>
>> Now, I haven’t tested this in reality and would appreciate help here.
>
> I’m in the process of implementing automated tests for the installation
> process.

I've been looking at this bug, as I've got a new laptop which I would
like to install GuixSD on, and I would like to use an encrypted root
partition.

Regarding the system tests, it looks to me like they do exist now, but
so far I've been unable to run them (I get an error related to hash
mismatch of module-import-compiled, I want to try getting it to
fallback, but first I need to work out where Guix is being invoked...).
L
L
Ludovic Courtès wrote on 23 Nov 2016 12:21
(name . Christopher Baines)(address . mail@cbaines.net)(address . 21843@debbugs.gnu.org)
877f7u6j7y.fsf@gnu.org
Hello!

(And apologies Christopher for not replying earlier!)

I’m happy to report that this issue is finally fixed in
f7f292d359e0eb77617f4ecf6b3164f868ec1784!

The complete list of relevant commits is this:

Toggle snippet (12 lines)
f7f292d * install: Enable "cryptodisk" handling in GRUB.
b7d408e * mapped-devices: Use 'cryptsetup-static' in 'luks-device-mapping'.
fe93383 * marionette: Add 'marionette-screen-text' using OCR.
f25c9eb * marionette: Delay synchronization with the host's REPL.

[...]

106b389 * gnu: Add 'cryptsetup-static'.
01f94cc * gnu: Add 'lvm2-static'.
10da75d * gnu: grub: Add dependency on LVM2.

Without LVM2 support, ‘grub-install’ and ‘grub-probe’ would fail to
determine what to do with the LUKS-encrypted partition.

When using ‘cryptsetup’ instead of ‘cryptsetup-static’, we were pulling
the whole closure of ‘cryptsetup’ (105 MiB) in the initrd, which was
clearly unreasonable. ;-)

The guts was to come up with a test strategy that would work. The
difficulty here is that we have to enter a passphrase early one in GRUB,
and then once again once the kernel has booted, when ‘cryptsetup’ is
invoked from the initrd. At this point, we have no good communication
channel with the hosts, hence the screenshots with OCR! (Idea stolen
from NixOS’ own tests.)

You can run the test with:

make check-system TESTS=encrypted-root-os

Further testing welcome!

Ludo’.
L
L
Ludovic Courtès wrote on 23 Nov 2016 12:21
control message for bug #21843
(address . control@debbugs.gnu.org)
8760ne6j79.fsf@gnu.org
tags 21843 fixed
close 21843
?
Your comment

This issue is archived.

To comment on this conversation send an email to 21843@patchwise.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 21843
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch