Ubuntu – Are there any advantages/disadvantages (if any?) in running luksFormat on raw drive (sdx) vs a partition (sdx1)

encryptionhard drivelukspartitioning

I've been setting up a few LUKS encrypted drives and noticed that I've been creating the encrypted disk directly on the 'raw'(?) drive, ie. /dev/sdb, while many examples via google are showing it created on /dev/sdb1

Example using /dev/sdb:

# cryptsetup luksFormat /dev/sdb
# cryptsetup luksOpen /dev/sdb lvm_backup

..and then following on with creating volume groups and logical volumes like so:

# vgcreate vg_backup /dev/mapper/lvm_backup
# lvcreate -l +100%FREE lvm_backup -n backup
# mkfs.ext4 /dev/mapper/vg_backup-backup

and finally mounting the drives.

This leave me with a lsblk looking something like this:

sdb                              8:16   0   2.7T  0 disk  
  lvm_backup (dm-3)            252:3    0   2.7T  0 crypt 
    vg_backup-backup (dm-5)    252:5    0     2T  0 lvm   /backup

In contrast, other lsblk output looks like:

sdb                              8:16   0   2.7T  0 disk  
  sdb1                           #:#     0    2.7T 0 part
    lvm_backup (dm-3)            252:3    0   2.7T  0 crypt 
      vg_backup-backup (dm-5)    252:5    0     2T  0 lvm   /backup

What are the advantages/disadvantages of working directly on the disk (/dev/sdb) vs creating a partition (/dev/sdb1) first?

I'm assuming this is probably somewhat related to:

Best Answer

Offhand, I'm thinking that if your using the entire device (/dev/sdb) and your LUKS header is at the start of the drive, and if some other tool or OS "helpfully" decides that your disk is unformatted with no MBR or GPT, if it were to overwrite your LUKS header that would be bad. If you were using a partition for LUKS then at least a new MBR or GPT wouldn't be as devastating.

You should always backup the LUKS header anyway, as the cryptsetup man page advises too.

And this is what the cryptsetup FAQ says about using "2.2 LUKS on partitions or on raw disks?" (it's long but I'll just paste it, mentions RAID & LVM can greatly complicate things, you may want to rethink using LVM on top of LUKS):

This is a complicated question, and made more so by the availability of RAID and LVM. I will try to give some scenarios and discuss advantages and disadvantages. Note that I say LUKS for simplicity, but you can do all the things described with plain dm-crypt as well. Also note that your specific scenario may be so special that most or even all things I say below do not apply.

Be aware that if you add LVM into the mix, things can get very complicated. Same with RAID but less so. In particular, data recovery can get exceedingly difficult. Only do so if you have a really good reason and always remember KISS is what separates an engineer from an amateur. Of course, if you really need the added complexity, KISS is satisfied. But be very sure as there is a price to pay for it. In engineering, complexity is always the enemy and needs to be fought without mercy when encountered.

Also consider using RAID instead of LVM, as at least with the old superblock format 0.90, the RAID superblock is in the place (end of disk) where the risk of it permanently damaging the LUKS header is smallest and you can have your array assembled by the RAID controller (i.e. the kernel), as it should be. Use partition type 0xfd for that. I recommend staying away from superblock formats 1.0, 1.1 and 1.2 unless you really need them. Be aware that you lose autodetection with them and have to fall back to some user-space script to do it.


(1) Encrypted partition: Just make a partition to your liking, and put LUKS on top of it and a filesystem into the LUKS container. This gives you isolation of differently-tasked data areas, just as ordinary partitioning does. You can have confidential data, non-confidential data, data for some specific applications, user-homes, root, etc. Advantages are simplicity as there is a 1:1 mapping between partitions and filesystems, clear security functionality and the ability to separate data into different, independent (!) containers.

Note that you cannot do this for encrypted root, that requires an initrd. On the other hand, an initrd is about as vulnerable to a competent attacker as a non-encrypted root, so there really is no security advantage to doing it that way. An attacker that wants to compromise your system will just compromise the initrd or the kernel itself. The better way to deal with this is to make sure the root partition does not store any critical data and move that to additional encrypted partitions. If you really are concerned your root partition may be sabotaged by somebody with physical access (that would however strangely not, say, sabotage your BIOS, keyboard, etc.), protect it in some other way. The PC is just not set-up for a really secure boot-chain (whatever some people may claim).

(2) Fully encrypted raw block device: For this, put LUKS on the raw device (e.g. /dev/sdb) and put a filesystem into the LUKS container, no partitioning whatsoever involved. This is very suitable for things like external USB disks used for backups or offline data-storage.

(3) Encrypted RAID: Create your RAID from partitions and/or full devices. Put LUKS on top of the RAID device, just if it were an ordinary block device. Applications are just the same as above, but you get redundancy. (Side note as many people seem to be unaware of it: You can do RAID1 with an arbitrary number of components in Linux.) See also Item 2.8.

(4) Now, some people advocate doing the encryption below the RAID layer. That has several serious problems. One is that suddenly debugging RAID issues becomes much harder. You cannot do automatic RAID assembly anymore. You need to keep the encryption keys for the components in sync or manage them somehow. The only possible advantage is that things may run a little faster as more CPUs do the encryption, but if speed is a priority over security and simplicity, you are doing this wrong anyways. A good way to mitigate a speed issue is to get a CPU that does hardware AES.

Related Question