--- Begin Message ---
|
Subject: |
LUKS-encrypted root and unencrypted /boot with GuixSD 0.12.0 |
|
Date: |
Sat, 31 Dec 2016 00:52:04 +0100 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Hello!
Eddie Baxter <pieceredd@gmail.com> skribis:
> I have attempted to install GuixSD on an encrypted root using LUKS, after
> reading the release notes for 0.12.0 that implies this should now work - My
> config.scm is linked:
>
> https://gist.github.com/AcouBass/3a1a6ab28c17830a175dc7da95eb18cd
>
> I don't get any errors on installation, nor upon doing a system
> reconfigure.
>
> At the moment I am still having to drop to a command prompt in Grub and use
> the commands:
>
> insmod luks
> cryptomount hd0,msdos2
The config has an unencrypted /boot and an encrypted root. What’s
tested and known-good is a configuration with an encrypted root that
contains /boot, like the one here:
https://www.gnu.org/software/guix/manual/html_node/Using-the-Configuration-System.html#index-encrypted-disk-1
It may be that this configuration is not correctly supported yet.
I’m Cc’ing bug-guix@gnu.org so we keep track of this issue.
> Which while it does work does mean I'm entering my passphrase twice
> (As well as having to drop to the Grub command line!)
The passphrase-twice issue seems hard to avoid: first GRUB needs to
access the partition, and then the kernel needs to access it.
If anyone is aware of ways to solve this, I’m all ears!
Thanks for your report!
Ludo’.
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#37851: bug#25305: bug#37851: Grub installation only checks for encrypted /boot folder |
|
Date: |
Mon, 21 Dec 2020 21:23:36 +0100 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
Hi Ludo,
First of all, thanks for your review. :-)
Ludovic Courtès <ludo@gnu.org> writes:
> Hi Miguel,
>
> Miguel Ángel Arruga Vivas <rosen644835@gmail.com> skribis:
>> + (define (crypto-devices)
>> + (define (crypto-device->cryptomount dev)
>> + (if (uuid? dev)
>> + #~(format port "cryptomount -u ~a~%"
>> + ;; cryptomount only accepts UUID without the hypen.
>> + #$(string-delete #\- (uuid->string dev)))
>> + ;; Other type of devices aren't implemented.
>> + #~()))
>> + (let ((devices (map crypto-device->cryptomount store-crypto-devices))
>> + ;; XXX: Add luks2 when grub 2.06 is packaged.
>> + (modules #~(format port "insmod luks~%")))
>> + (if (null? devices)
>> + devices
>> + (cons modules devices))))
>
> What I don’t get is why we’re able to use an encrypted root right now
> without emitting “cryptomount” GRUB commands?
The grub boot process goes more or less like this:
1. Firmware loads the initial image.
1.1. If that image is not the final one, it contains a "pointer" to the
final one, which is loaded by it; this chain can be viewed as part
of the firmware loading for this purpose.
2. The image code reads an initial configuration file, which is usually
generated by grub-install/grub-mkstandalone. Here Grub is placing
the needed the cryptomount lines for the devices needed to mount
target in order to read grub.cfg and other modules.
3. grub.cfg is read (a.k.a. normal mode) and the usual boot process
follows.
The first configuration file is generated automatically by grub-install,
which physically scans the target location (still /boot in our case) and
inserts the needed insmod and cryptomount calls. When the target and
the store don't share the device, the calls leading to the store must be
inserted manually into grub.cfg.
It could be easier to remove completely /boot and use a directory from
the store, but that leads to more writes of the image, as each
reconfiguration involving a change on the devices used for the store
must end up returning a different store file name too. Nonetheless,
that would leave /boot untouched if anybody wants to install their
version of grub there for other purposes...
>> + (_
>> + ;; No crypto-devices found
>> + '())))
>> + (_
>> + ;; No store found, old format.
>> + '())))
>
> s/No store found/No crypto devices found/ ?
The first comment is reached when crypto-devices isn't found in a
(boot-parameters ... (store ...) ...) form. The second one is reached
when (boot-parameters ...) form doesn't even contain a tag store in it.
It follows the same pattern as store-device, as the old format didn't
have a store element.
On the other hand, I added a period to the first sentence as it was
missing. 0:)
>> +(define (operating-system-bootloader-crypto-devices os)
>> + "Return the subset of mapped devices that the bootloader must open.
>> +Only devices specified by uuid are supported."
>> + (map mapped-device-source
>> + (filter (match-lambda
>> + ((and (= mapped-device-type type)
>> + (= mapped-device-source source))
>> + (and (eq? luks-device-mapping type)
>> + (or (uuid? source)
>> + (begin
>> + (warning (G_ "\
>> +mapped-device '~a' won't be mounted by the bootloader.~%")
>> + source)
>> + #f)))))
>> + ;; XXX: Ordering is important, we trust the returned one.
>> + (operating-system-boot-mapped-devices os))))
>
> You can use ‘filter-map’ here.
Thanks for the pointer! I've modified a bit tests/boot-parameters.scm
to be extra-sure that I was doing that change OK, as I moved the or to a
internal function for readability too.
> The rest LGTM! Make sure the “installed-os” and “encrypted-root-os”
> system tests are still fine, and if they are, I guess you can go ahead.
Pushed to master as f00e68ace0 with these changes, after running the
tests and booting up my system.
Happy hacking!
Miguel
--- End Message ---