GNU bug report logs - #72889
Support for root filesystem on btrfs raid1 on two LUKS devices

Previous Next

Package: guix;

Reported by: "amano.kenji" <amano.kenji <at> proton.me>

Date: Fri, 30 Aug 2024 08:49:04 UTC

Severity: normal

To reply to this bug, email your comments to 72889 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#72889; Package guix. (Fri, 30 Aug 2024 08:49:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to "amano.kenji" <amano.kenji <at> proton.me>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Fri, 30 Aug 2024 08:49:04 GMT) Full text and rfc822 format available.

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

From: "amano.kenji" <amano.kenji <at> proton.me>
To: "bug-guix <at> gnu.org" <bug-guix <at> gnu.org>
Subject: Support for root filesystem on btrfs raid1 on two LUKS devices
Date: Fri, 30 Aug 2024 07:07:55 +0000
Imagine that root filesystem is btrfs raid1 on two LUKS devices.

To mount it on initial ram disk, guix has to first unlock two LUKS devices with one password.




Information forwarded to bug-guix <at> gnu.org:
bug#72889; Package guix. (Thu, 05 Sep 2024 01:58:02 GMT) Full text and rfc822 format available.

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

From: "amano.kenji" <amano.kenji <at> proton.me>
To: "72889 <at> debbugs.gnu.org" <72889 <at> debbugs.gnu.org>
Subject: A new insight
Date: Thu, 05 Sep 2024 01:56:25 +0000
I guess this is going to require passphrase reuse for mapped devices.




Information forwarded to bug-guix <at> gnu.org:
bug#72889; Package guix. (Tue, 10 Sep 2024 13:15:02 GMT) Full text and rfc822 format available.

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

From: "amano.kenji" <amano.kenji <at> proton.me>
To: "72889 <at> debbugs.gnu.org" <72889 <at> debbugs.gnu.org>
Subject: I thought of a possible way to do this.
Date: Tue, 10 Sep 2024 13:14:38 +0000
- /dev/sda

/dev/sda1: A tiny LUKS partition that's filled with the content of a keyfile without any filesystem format.
/dev/sda2: /boot for grub. It also serves as FAT32 EFI partition.

- /dev/sdb

/dev/sdb1: /gnu/store on btrfs raid1
/dev/sdb2: / on btrfs raid1 on LUKS

- /dev/sdc

/dev/sdc1: /gnu/store on btrfs raid1
/dev/sdc2: / on btrfs raid1 on LUKS

Open /dev/sda1 as a luke device, /dev/mapper/key, with one password. It contains a keyfile without any filesystem format. Use /dev/mapper/key as a keyfile for all other LUKS devices in mapped devices.

This exposes /gnu/store, but /gnu/store is not supposed to have any sensitive data. This obviously makes it practically impossible to detect physical tempering of data, but if you store it at a secure location, you don't have to worry too much about evil maid attack.

RAID1 for physically secure servers is enough to ensure some availability when a disk fails.

For laptops that you carry, you are not going to use btrfs raid1, and you can just have unencrypted /boot on fat32 and / on btrfs on luks. extra-initrd contains a keyfile for / so that I don't have to type the password twice.

A desktop computer doesn't require server-level availability, but people who have money can still put root on encrypted btrfs raid1.

Perhaps, can this be documented in the cook book?




This bug report was last modified 339 days ago.

Previous Next


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