1

I'd like to use BTRFS RAID1 with dm_crypt on a microserver. The hard part that I don't understand many things about how filesystems and LUKS work. Let's say we have 2 partitions on a drive and we do a whole drive encryption. Does that mean that both partitions will be encrypted and without knowing the key I won't be able to tell what filesystems they have? If so, then I don't understand how it is possible to have an unencrypted boot partition (necessary to load dm_crypt) on such drives or how btrfs raid1 will work if I encrypt both drives and they don't know from each other until both of them are decrypted? On the other hand if dm_crypt uses the btrfs partitions to store the data encrypted for example in a huge file, then wouldn't the btrfs scrub work on this huge file only and wouldn't a single uncorrectable error kill the whole content of the disks?

1

Does that mean that both partitions will be encrypted and without knowing the key I won't be able to tell what filesystems they have?

Yes, both partitions will be encrypted as LUKS partitions. You will be able to tell they are LUKS encrypted partitions. Without the key (and/or passphrase), you will not be able to tell what is inside the partition.

If so, then I don't understand how it is possible to have an unencrypted boot partition ...

Either (a) the boot partition is a separate [and unencrypted] partition, or (b) the boot loader [GRUB?] asks for the passphrase and knows how to decrypt and mount the boot parition. (I typically use an unencrypted boot partition with Ubuntu. I once saw an encrypted boot partition on an installation of Manjaro Linux.)

The main problem with this setup that since raid1 will be on the upper level, both hdds/ssds will be encrypted differently, which means performance penalty and a lot of unnecessary encryption.

I've heard the overhead of disk encryption is negligible. I have never had a problem with it. But then I have never measured the performance impact, and I do not need high speed disk IO on my system.

In any case, you will only pay the cost for multiple encryption when writing data. When reading, only one copy of the data will need to be read.

I use LUKS + ZFS + RAID1, but only for /home. I use ext4 for /, and ext2 for /boot.

(Note that if you have N>2 disks, BTRFS's "RAID1" mode is not really RAID1, as BTRFS will only create 2 copies of your data, not N copies as required by RAID1. In other words, BTRFS "RAID1" with N>2 disks gives you more storage space, not more redundancy.)

| improve this answer | |
1

I read some texts in the topic. According to them the partitioning and formatting are separate processes, so I don't have to give the file system type by partitioning a block device (ssd/hdd/virtual?). The dm-crypt can convert an unencrypted block device to an encrypted one by encrypting each block (or sector?) individually and the btrfs can live on that encrypted block device.

Note: dmcrypt + btrfs needs 4+ kernel to work properly; 3.2- kernels have compatibility and security issues, 4.0- kernels have performance issues.

The main problem with this setup that since raid1 will be on the upper level, both hdds/ssds will be encrypted differently, which means performance penalty and a lot of unnecessary encryption. According to other texts/answers I read there is no way to do this now. People are working on btrfs encryption, but there is nothing stable yet. Currently the stacked approach with ecryptfs - the btrfs FAQ mentions - is a lot slower than dm-crypt, so that wouldn't be a good solution either. Another option is using zfs, which has encryption support, but afaik. it consumes a lot of memory compared to btrfs.

update (Jan, 2019):

I checked zfs too, it has a nice native encryption and you can encrypt the swap partition too, so I think that is the way to go. It has some drawbacks too, it uses more memory and it isn't as straightforward to add a new disk as with btrfs.

| improve this answer | |
  • This is stable and easy to set up, see my answer below (~2019, btrfs in kernels >= 5.0.4); eg any ubuntu 18.04 system today. – mike Nov 16 '19 at 19:04
0

perhaps I'm miss-understanding your question, but this should be completely fine.

The prerequisite for your system is that the LUKS devices are opened/decrypted prior to accessing them. Two basic ways this could be set up:

  • on a filesystem required for boot: you had to enter your passphrase at boot (grub, or kernel depending on whether you fully FDE'd your disk)
    • this would have a 0 for mount order in /etc/fstab
  • or not required for boot, eg a data drive.
    • I'll use this as an example; it's the slightly more complicated case it would seem.

assume for exmaple you have a non-encrypted btrfs on /dev/sda1 and LUKS encrypted btrfs's on /dev/sdb1 and /dev/sdc1

So you need all relevant devices opened/decrypted. This is a completely independent step / entity from BTRFS. LUKS uses the kernel device-mapper, so what this means is:

  • without LUKS, you'd reference your btrfs filesystem via the standard device path do your partition such as /dev/sda1 (note, we're talking partition not whole sda drive, since the filesystem is contained there).
  • WITH LUKS, luks conceptually wraps the filesystem. When you (manually, or eg automated at boot) luksOpen it (again, kernel devicemapper is used) you end up with a /dev/mapper/your_label. You do still have the normal /dev/sda1 node, but this isn't going to be used; the dev/mapper/ node is (after luks-open) conceptually the same as the /dev/sda1 - it's where your btrfs filesystem is.

Once you have the btrfs filesystems available, eg /dev/sda1, /dev/mapper/your_label etc, you can perform whatever btrfs tasks you need, such as device add to make a raid1 array.

Now - how to "make the btrfs filesystem available automatically?

  1. you can manually unlock it of course
  2. your LUKS can be the one that contains your root fs, meaning you would have had to follow other guides to have grub or the kernel in your initramfs unlock it
  3. you have a secure filesystem already unlocked (eg, your root FS) and we can use a keyfile + /etc/crypttab to unlock it automatically.

using the last as an example, as it seems like the case you're asking about

steps:

  1. create a keyfile and add associate it with the drive via cryptsetup luksAddKey /dev/sdb1 (prompts you for your LUKS passphrase) - many tutorials for this online, such as https://access.redhat.com/solutions/230993
  2. create an entry in /etc/crypttab that tells your system to mount that device (note, use a UUID= not /dev/sdb1 ... but that's another topic!). The keyfile, now available since your root fs was previously luksOpened, is used automatically to open it.

Now your btrfs filesystems are available / decrypted, and will work just as though LUKS isn't present (albeit at /dev/mapper/... nodes, not /dev/sd... nodes) `

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.