LUKS encrypted root with GuixSD 0.12.0

LUKS encrypted root with GuixSD 0.12.0

[Eddie Baxter]

[-- Attachment #1: Type: text/plain, Size: 676 bytes --]

Hi,

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

Which while it does work does mean I'm entering my passphrase twice
(As well as having to drop to the Grub command line!)

Is this still an unsupported setup for now? If not, am I doing
something blatently wrong?

Thanks!

[-- Attachment #2: Type: text/html, Size: 1036 bytes --]

LUKS-encrypted root and unencrypted /boot with GuixSD 0.12.0

[Ludovic Courtès]

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’.

bug#25305: LUKS-encrypted root and unencrypted /boot with GuixSD 0.12.0

[Jonathan Brielmaier]

We have now pretty good LUKS support, but I don't know if we support
this use case. I always have `/boot` encrypted as well...

bug#25305: LUKS-encrypted root and unencrypted /boot with GuixSD 0.12.0

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]

On Mon, 16 Nov 2020 18:56:56 +0100
Jonathan Brielmaier <jonathan.brielmaier@web.de> wrote:

> We have now pretty good LUKS support, but I don't know if we support
> this use case. I always have `/boot` encrypted as well...

Unencrypted /boot and encrypted / is necessary to be able to use Heads
(right now).

(It measures /boot in order to find out whether it has been tampered with or
not)

If you want to be able to boot on a Heads system, either Heads needs to be
modified to mount encrypted / , or there needs to be an unencrypted /boot.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

bug#25305: LUKS-encrypted root and unencrypted /boot with GuixSD 0.12.0

[Ludovic Courtès]

Hi,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> (It measures /boot in order to find out whether it has been tampered with or
> not)

(Off-topic.) I’d be curious to see how much of this approach makes sense
in the context of immutable deployments like Guix does.

Ludo’.