Talk:Dm-crypt/Encrypting an entire system

From ArchWiki
Jump to navigation Jump to search


A while ago User:Indigo added a reference to the LVM on LUKS on LVM scenario with [1], which was later modified with [2], and finally deleted with [3].

IMO it would be interesting to restore it as a stub section here, like Dm-crypt/Encrypting_an_Entire_System#LUKS_on_software_RAID, waiting for somebody to fill it up, what do you think?

I've also found a forum thread: [4].

-- Kynikos (talk) 14:09, 18 February 2014 (UTC)

It sure is an interesting use case, but I am hesitant. The main reason is that it has to be certain that udev device discovery (be it with encrypt or sd-encrypt) is rock solid longterm for such a setup, see e.g. [5] for related problems. The edits you refer to originate from before that and also before systemd. Therefore I think it would be sensible to have developer input on viability/route for such a sandwich.
I am biased though, I generally prefer encryption as the first mapper. One reason is that it is very easy to seriously wreck a LUKS blockdevice with a single resize statement, if lvm hovers over it.
A final thought on LVM: crypttab offers vanilla flexibility for multiple disks. It would be interesting to know, if someone runs an Arch setup with multiple non-root fully encrypted disks, mounted via crypttab/fstab and joined to a single VG. That might be a worthwhile alternative extension for the shorter Dm-crypt/Encrypting_a_Non-Root_File_System ?
edit: before I forget - a variation of above alternative extension on the non-root page instead may be not to use LVM but have multiple non-root fully encrypted disks and use a btrfs raid1 inside it. Users experiences with that might also be interesting for others.
Plenty of food. Looking forward to read/learn other opinions/experiences. --Indigo (talk) 22:13, 18 February 2014 (UTC)
Thanks for all these interesting observations. Let's keep it on hold then, at least now we have a reminder for this case. -- Kynikos (talk) 05:33, 19 February 2014 (UTC)
Anytime. Good you brought it to the table. --Indigo (talk) 10:51, 19 February 2014 (UTC)

LUKS on LVM /tmp example

I don't think the example config for /tmp is correct. It uses tmpfs, which completely bypasses the physical disks (other than swap), making the whole endeavor pointless. The proper solution seems to be to use the 'tmp' option in /etc/crypttab--I just set this up, and it seems to be working. It automatically creates a new ext2 filesystem with a random key on each boot. I'd update the article, but the crypttab syntax it uses doesn't even match mine, and I don't know how to translate to the new syntax. TravisE (talk) 10:27, 11 March 2014 (UTC)

You probably use in crypttab "tmp=ext2" as option? I'd say you are right anyway (and the example still works but wastes the reserved lv diskspace). Feel free to edit right away if you clarified or post the settings you use here and we adapt them. --Indigo (talk) 20:06, 11 March 2014 (UTC)
I updated syntax: [6]
I still left the lv for it. Question to answer before removing it would be where /tmp swaps to, if required. Do you know that?
--Indigo (talk) 22:45, 25 March 2014 (UTC)

Clarifying "LUKS on LVM"

  • In "LUKS on LVM", the following commands are used to "Randomise /dev/sda2":
cryptsetup -d /dev/random -c aes-xts-plain64 -s 512 create lvm /dev/sda2
dd if=/dev/urandom of=/dev/mapper/lvm
cryptsetup remove lvm

What's the point of this? Why not just dd if=/dev/urandom of=/dev/sda2?

  • In /etc/crypttab, the following line is used for swap:
swap	/dev/lvm/swap	SWAP		-c aes-xts-plain64 -s 512

What does specifying "SWAP" as keyfile do? Couldn't find documentation on this.

  • And why should the keyfile for home be 256 bytes if the key size is 512 bits? --Bypeoplelikeyou (talk) 21:37, 24 March 2014 (UTC)

The section LVM_on_LUKS you refer to still needs care to bring it up-to-date and into line with the structure followed for the scenarios.
To your questions:
  • The use of /dev/urandom is unnecessary. The quoted approach was probably chosen back then to speed up the randomising of the device, but then using /dev/urandom is not beneficial. /dev/zero should be used. We want to crosslink such instructions: [7]
  • Good catch. Again this stems from history. When that section was written, crypttab still had an option to specify a passphrase (and "SWAP" was used as the example one). The use of passphrases was later deprecated (in 2012) and this line was not updated. IF you use it like that now, cryptsetup parsing will prompt for a (new) passphrase (for swap) on boot, i.e. it would boot with crypted swap after you provide a/any pass. In any case I updated it: [8]
  • In your last question, you mix up the options "--key-size" (for the cipher) and "--keyfile-size" (for the keyfile). We have that covered in Dm-crypt/Device_Encryption#Encryption_options_with_dm-crypt
--Indigo (talk) 22:36, 25 March 2014 (UTC)
Thanks, better now. In my last question, I referred to this command: dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256 How could anything more than 64 bytes increase security? --Bypeoplelikeyou (talk) 00:48, 6 April 2014 (UTC)
Yes, but you compare an apple and a pear. Both those bits/bytes have different purposes and cryptographic attributes in LUKS mode. Have a look for master-key derivation, we tried an explanation here: Disk_Encryption#Cryptographic_metadata
--Indigo (talk) 13:00, 6 April 2014 (UTC)


On the page it says “This method will not allow you to span the logical volumes over multiple disk, even in the future. For a solution that allows to do so, see #LUKS on LVM”. This is wrong IMHO, you can create another LUKS container and use that as a second LVM physical volume. --Dingens (talk) 13:25, 23 April 2014 (UTC)

Your quote speaks of "spanning the logical volumes over multiple disks", i.e. extending the vg/lv created later by virtue of LVM to the next device. What you suggest is ok, but it can be done to any scenario on the page and not for the lv-root created in the scenario. For example, you have a small disk that runs full, add another disk and want to extend the encrypted lv-root to the new disk. With "#LUKS on LVM" you can theoretically do that, with the other scenarios not (single cryptdevice= option).
--Indigo (talk) 18:52, 23 April 2014 (UTC)

LVM on LUKS kernel parameters

The LVM on LUKS sections correctly indicates that the bootloader needs to supply the following kernel parameter:


where MyStorage is the name of the volume group. It then says "See Dm-crypt/System_Configuration#Boot_loader for details.". The linked page says to supply the following different kernel parameter:


where "dmname is the device-mapper name given to the device after decryption, which will be available as /dev/mapper/dmname"

This doesn't work if you're using LVM on LUKS, since the names in /dev/mapper will be of the form volume_group-volume. I discovered this the hard way. Perhaps the Dm-crypt/System_Configuration#Boot_loader page could be modified to reflect that the device-mapper name isn't always right?

Cmatteri (talk) 06:22, 1 May 2014 (UTC)

Let's better say the device mapper is always right, but mkinitcpio parses a different format. So yes, I am with you. It is contradictionary. I did two edits to clarify it on the configuration subpage: [9]. We have a couple more of these in LUKS on LVM; I'm closing this point. If you think something is wrong or could be improved in wording, feel free to edit right away, open this item again or a new one.
--Indigo (talk) 18:07, 1 May 2014 (UTC)

LUKS on LVM troubleshooting

I'd really like to remove Dm-crypt/Encrypting_an_entire_system#Troubleshooting:_the_system_does_not_boot, or at least move it somewhere else, in fact no other scenario has troubleshooting sections, so it really seems out of place there (it's a residue from the historical LUKS article). Plus, it's not saying anything that is not obvious once one has understood how to map LVM volumes and open dm-crypt containers manually (which is thoroughly described in LVM and dm-crypt/Device encryption). -- Kynikos (talk) 04:06, 18 May 2014 (UTC)