GNU bug report logs - #65002
[PATCH 0/2] Add support for unlocking root device via a key file

Previous Next

Package: guix-patches;

Reported by: Tomas Volf <~@wolfsden.cz>

Date: Tue, 1 Aug 2023 21:08:01 UTC

Severity: normal

Tags: patch

Done: Ludovic Courtès <ludo <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #28 received at 65002 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Tomas Volf <wolf <at> wolfsden.cz>
Cc: 65002 <at> debbugs.gnu.org
Subject: Re: [bug#65002] [PATCH v2 2/2] gnu: bootloader: grub: Add support
 for loading an additional initrd
Date: Wed, 10 Jan 2024 00:28:18 +0100
Tomas Volf <wolf <at> wolfsden.cz> skribis:

> In order to be able to provide decryption keys for the LUKS device, they need
> to be available in the initial ram disk.  However they cannot be stored inside
> the usual initrd, since it is stored in the store and being a
> world-readable (as files in the store are) is not a desired property for a
> initrd containing decryption keys.

This explanation should go in the manual IMO (it’s already partly there).

> This commit adds an option to load additional initrd during the boot,
> one that is not stored inside the store and therefore can contain
> secrets.
>
> Since only grub supports encrypted /boot, only grub is modified to use the
> extra-initrd.  There is no use case for the other bootloaders.
>
> * doc/guix.texi (Bootloader Configuration): Describe the new extra-initrd
> field.
> * gnu/bootloader.scm: Add extra-initrd field to bootloader-configuration
> * gnu/bootloader/grub.scm: Use the new extra-initrd field

It’d be great if you could specify the entities changes in each file
(which variable/procedure is changed, what is added/removed).  A
committer can do it on your behalf later if you’re unsure.

> +@item @code{extra-initrd} (default: @code{#f})
> +Path to an additional initrd to load.  Should not point to a file in the

s/Path/File name/ (by convention)

Please make full sentences.  “Should not” is probably too strong;
perhaps: “It may or may not point to a file in the store, but the main
use case is for out-of-store files containing secrets.”

> +store.  Typical use case is making keys to unlock LUKS device available

Add a line break after “store.” to distinguish the reference from the
discussion of one possible use case.

> +during the boot process.  For any use case not involving secrets, you
> +should use regular initrd (@pxref{operating-system Reference,
> +@code{initrd}}) instead.
> +
> +Suitable image can be created for example like this:
> +
> +@example
> +echo /key-file.bin | cpio -oH newc >/key-file.cpio
> +chmod 0000 /key-file.cpio
> +@end example
> +
> +Be careful when using this option, since pointing to a file that is not
> +readable by the grub while booting will cause the boot to fail and
> +require a manual edit of the initrd line in the grub menu.
> +
> +Currently only supported by grub.

s/grub/GRUB/

Would be great if you could include also a short config example here, or
add a cross-reference to the example for
‘luks-device-mapping-with-options’ if that covers both.

> +  (extra-initrd          bootloader-configuration-extra-initrd
> +                         (default #f))    ;string | #f
> +  )

No lonely paren please.  :-)

Otherwise LGTM.

Could you send updated patches with these minor changes?

Thanks!

Ludo’.




This bug report was last modified 1 year and 124 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.