[Resolved] BTRFS and Multi-Disk Encryption

ANOKNUSA · 2013-12-05 16:44:24

Howdy-ha, folks. So I've just gotten my hands on a new SSD to complement the one I already have, and was looking to tie them together into a single volume in my laptop. The two options open to me are:

- LVM with EXT4, with one logical volume for '/' and another for '/home.' More mature and stable, better documented, but possibly not taking full advantage of two SSDs.

- BTRFS single mode (I want to maximize space, and I make a full-system backup 3-4 times a week, so RAID isn't an option or necessity), with a dedicated root subvolume and another subvolume for '/home.' I've used BTRFS relatively problem-free for a while, it's optimized for SSD operation and (possibly) more space-efficient than LVM, its implementation seems simpler and more elegant, and I have a couple free weeks coming up where stability won't be an issue. This would be my first choice.

In either case, everything but the UEFI partition will be a single LUKS-encrypted volume unlocked via passphrase, so here's what I'm trying to work out: With LVM, I understand one can span a single storage volume across multiple disks and a single LUKS partition will handle encryption on both disks. Is this the case with BTRFS single mode as well---can I simply create a multi-disk BTRFS data pool, and encrypt that data pool in its entirety, unlocking it with a single passphrase? There's an open question on the BTRFS wiki regarding this; from what I can tell, one can't simply add a new BTRFS filesystem to the existing volume and have encryption retroactively cover both disks. I could simply add one disk to the existing volume, encrypting it using a keyfile that sits on the current primary encrypted disk, but that doesn't seem ideal. Thanks in advance, everyone.

Last edited by ANOKNUSA (2013-12-10 23:32:07)

falconindy · 2013-12-05 17:04:29

ANOKNUSA wrote:

can I simply create a multi-disk BTRFS data pool, and encrypt that data pool in its entirety, unlocking it with a single passphrase?

Not really. This isn't how encryption (LUKS/dm-crypt) works. You're essentially asking if you can layer LUKS on top of an existing filesystem, and this isn't possible. You must encrypt the individual member devices, and then assemble the btrfs device from the decrypted block devs.

It is possible for a privileged application to cache the crypto keys in the kernel keyring for reuse, meaning that you'd only need to enter your password once. IIRC, systemd plans to implement this in their crypt tool but it doesn't exist yet.

ANOKNUSA · 2013-12-05 18:20:08

I understand the BTRFS volume would sit on top of LUKS; I guess I worded that poorly, sorry. So:

*Option 1*

1) Use "cryptsetup" to encrypt and unlock each device---the first with a passphrase, the second with a keyfile;
2) use "mkfs.btrfs -m single -L Arch /dev/mapper/x /dev/mapper/y" to create the multi-disk volume;
3) mount the volume to a folder in /mnt, create the root subvolume, remount using "mount -o <options>subvol=x", and create the /home subvolume;
4) rsync a system backup into the new BTRFS volume, and place the keyfile for the second device in the appropriate place in the filesystem.

*Option 2* (if I understand correctly, which I very well may not)

1) Simply encrypt the second device using a keyfile;
2) place that keyfile in the current (encrypted) filesystem; and
3) add the second BTRFS filesystem device to the already existing volume, using "btrfs scan && btrfs balance"

The result of Option 2 would (should? could? may?) be the same as option 1, given that I'm not planning on duplicating metadata across the two filesystems; however, I didn't specify single mode when I created the original volume, and I believe mkfs.btrfs defaults to metadata duplication anyway, so Option 2 may be no option at all.

I've got no problem manually unlocking two separate devices by entering a passphrase twice, either. If I have to unlock each disk independently, though, my concern would be what happens if I miss a key element in the setup and only one of the two disks is unlocked at boot-up. Would the single UUID assigned to the volume preclude that trouble, or should I expect to mount in degraded mode to sort things out, since encryption would leave the filesystem unreadable/unavailable to the volume?

ANOKNUSA · 2013-12-10 23:30:09

ANOKNUSA wrote:

I've got no problem manually unlocking two separate devices by entering a passphrase twice, either. If I have to unlock each disk independently, though, my concern would be what happens if I miss a key element in the setup and only one of the two disks is unlocked at boot-up. Would the single UUID assigned to the volume preclude that trouble, or should I expect to mount in degraded mode to sort things out, since encryption would leave the filesystem unreadable/unavailable to the volume?

This more-or-less turned out to be the case. There simply doesn't seem to be any reliable way to use BTRFS with multiple encrypted devices right now. Normally, a user wishing to use multiple encrypted disks would make use of the /etc/crypttab file, specifying the second disk to be unlocked using a keyfile stored on the first encrypted filesystem. However, since a BTRFS volume is assigned a single UUID and treated as a single filesystem, all disks/filesystems need to be present when the initramfs starts the boot process. Because the encrypt hook only unlocks a single disk (specified in the kernel parameters), the second disk is left unavailable, and the BTRFS volume fails to mount. Here's the situation:

1) When the volume fails to mount, the user is dropped to the recover shell. Once there, the user can unlock the second drive, mount the BTRFS volume to /new_root and use "switch_root" to finish the booting process; if the user only reboots, say, once a week, that might not be such a bad compromise. Still, it isn't ideal, and the only solution I can think of is to modify the mkinitcpio encrypt hook to unlock two devices simultaneously using the same key. Since I'm not competent enough to handle that (at least not in any reasonable or timely manner) I'll take a pass on it. Although as a side-effect it does seem to slighlty lower the chances of unwanted access, and thus slightly raise security.

2) One can use an abstraction layer such as LVM or FakeRAID to span a logical volume across all disks, then format the logical partition to BTRFS. Since this is one of the key features of BTRFS at the filesystem level, it seems rather odd to span all disks with an abstraction layer and then use a single BTRFS partition inside that layer, especially when LVM in particular has the ability to span disks, add and remove devices online and create snapshots in much the same way BTRFS can. I haven't tested whether LVM + LUKS + BTRFS would impact performance, either (on SATA III SSDs, I suspect not), but it still precludes some key reasons to use BTRFS in the first place.

For now, I'll stick with LVM + LUKS + EXT4; marking as "Resolved."

Last edited by ANOKNUSA (2013-12-10 23:32:18)

myles · 2014-01-08 15:27:29

Because the encrypt hook only unlocks a single disk (specified in the kernel parameters), the second disk is left unavailable, and the BTRFS volume fails to mount.

Does this help? https://bbs.archlinux.org/viewtopic.php … 84#p828784

Arch Linux

#1 2013-12-05 16:44:24

[Resolved] BTRFS and Multi-Disk Encryption

#2 2013-12-05 17:04:29

Re: [Resolved] BTRFS and Multi-Disk Encryption

#3 2013-12-05 18:20:08

Re: [Resolved] BTRFS and Multi-Disk Encryption

#4 2013-12-10 23:30:09

Re: [Resolved] BTRFS and Multi-Disk Encryption

#5 2014-01-08 15:27:29

Re: [Resolved] BTRFS and Multi-Disk Encryption

Board footer