[plug] Self encrypting drives

Brad Campbell brad at fnarfbargle.com
Fri Jan 20 15:54:26 AWST 2017

G'day all,

I run (ran) LUKS/dm-crypt on all my data drives, swap and basically 
anything other than boot/root on all my machines.

The 6 year old root SSD on my desktop started to crap out yesterday, so 
I replaced both root and home drives with a pair of new Samsung 850's. 
These shiny new drives support SED, so I thought I'd have a crack at 
replacing dm-crypt on the home drive with SED, and I thought it might be 
of interest so I made some notes.

My machines are relatively archaic, so I couldn't get sedutil to compile 
from source because of way out of date header files. I didn't actually 
try very hard, I just used their pre-compiled cli binary.

Because I'm only encrypting a data drive I don't need the pre-boot 
environment or any of that complexity. Nor do I need this to come up in 
the initramfs.

I set the drive up with --initialsetup, then enabled encryption with 
--enableLockingRange 0. I thought I'd be clever and not bother enabling 
the fake MBR as I didn't need the PBE. *Big* mistake. Booting a kernel 
with a locked drive that does not have the MBR enabled spends about 30 
seconds spewing ATA errors into the logs as it tries over and over again 
to read the MBR. This is not a trickle, rather a continuous blast.

So, *always* enable the fake mbr (--setMBREnable on) when you encrypt 
the drive.

To unlock the disk, I've created a little initscript that runs very 
early in the boot process that basically contains the following (excuse 
the gross bash) :

do_start () {
	for i in `$SEDU --scan | awk '{print $1}' | grep '/dev/'` ; do
		if [ -n "`$SEDU --query $i | grep 'Locked = Y'`" ] ; then
			echo $i Locked
			if [ -z "$KEY" ] ; then
			$SEDU --setlockingrange 0 rw $KEY $i
			$SEDU --setMBRDone on $KEY $i
			/sbin/blockdev --rereadpt $i
			echo $i Already Unlocked

This uses sedutil to get a list of all drives that support SED, it then 
iterates them to see if any are locked and if so it proceeds to unlock 
them. No point trying to unlock an already unlocked drive, and as I 
rarely power cycle my machines on most boots they'll already be unlocked.

It's important to re-read the partition table after unlocking and 
swapping the MBRs.

The only thing this loses over using dm-crypt is the machine is now 
susceptible to power-on attacks. So you can soft-boot it into another OS 
and get access to the disk. For my particular threat model that's not an 
issue. I'm more worried by someone breaking in and walking away with the 
box, and if they do that I'm covered.

Encrypting the drive is really just enabling the locking and setting a 
key, so there is no data loss or other interaction required with the disk.


More information about the plug mailing list