[dm-crypt] The future of disk encryption with LUKS2

Sven Eschenberg sven at whgl.uni-frankfurt.de
Mon Feb 8 05:32:14 CET 2016

Am 08.02.2016 um 04:43 schrieb f-dm-c at media.mit.edu:
>      > Date: Mon, 8 Feb 2016 03:46:27 +0100
>      > From: Sven Eschenberg <sven at whgl.uni-frankfurt.de>
>      > If a sector fails, it is not that uncommon that a whole chunk of
>      > consecutive sectors fail (for rotating disks that is).
> Oh, come on.  A one-meg gap is 256 4K sectors and 1024 1K sectors.
> I've never seen anything take out more than a handful of sectors
> adjacent to each other unless the disk has completely failed.
> Anything that's chewing up multiple megs or tens of megs at the start
> of your FS is likely to destroy any other random parts of it as well.
> Okay, how about a -10- meg gap?  That enough?

Well, I've seen several thoundand adjacent sectors going down. And not 
just once.

As I pointed out creating a filesystem can easily destroy both headers, 
even though many FSes have a rather thin metadata structure. Another 
neat example mdadm - default is header at 4k (primary header will be 
damaged) followed by a bad block list and and intent bitmap. The size of 
those can vary afaik.

To be honest, I am not completely sure what a good offset would be.

> If you need resiliency from massive corruption like that, use a header
> backup -on other media-, and -also- an actual backup of the FS.

Of course, that's what I usually do anyway. But we'll have to at least 
consider an average user aswell, having a normal desktop, using a magic 
mumbo jumbo installer with LVM on top of dm-crypt setup. It's not about 
covering your or my use case, but rather those of as many users as 
possible, without sacrificing i.e. security though.

> Complicating LUKS to the point where resizing becomes fraught and
> difficult to handle and other tools need all kinds of special
> instructions to solve a problem where the disk is already in severe
> distress or something's written tens of megs of garbage all over it
> seems pointless.

Of course overcomplicating things is not an option. But you should 
always remember: A damaged header is a total loss, a damaged fs can 
quite often be recovered easily enough. And other tools need 'special 
instructions' for every fs, dm-layer and task. There's no generic 
resize() IOCTL for all your block layers.

> The (potentially solvable) problem we've seen most on this list is not
> massive disk failure, but OS's that decide to overwrite a sector or
> two near the front.  So maybe we'll be extravagent and use 10 megs of
> clear space between the two copies---that's still absolutely in the
> noise on any reasonable disk, while being dead simple to implement,
> does not require any knowledge of the ultimate container size, does
> not require motion if the size changes, and will withstand almost any
> conceivable failure except someone doing "dd if=/dev/zero of=part" and
> then not noticing until a minute later---at which point, it's time to
> go to the backups anyway.  And it doesn't involve hairing up the
> options to enable/disable/move around/dance a jig with where the
> backup header is stored.  Keep it simple.

I don't mind keeping it simple. Really simple and secure was already 
mentioned: You do have a backup anyway, just recreate the container and 
pull back the backup and you are done ;-). Resizing (growing) is just a 
convenient thing to do.



More information about the dm-crypt mailing list