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

[Sven Eschenberg <sven@whgl.uni-frankfurt.de>]

Placing the secondary (backup) header closely to the first one is not a 
good idea. While this does resolve a power failure induced broken 
header, all other problems persist.

If a sector fails, it is not that uncommon that a whole chunk of 
consecutive sectors fail (for rotating disks that is). While a recovery 
from such a severe failure poses further problems on higher levels, the 
risk both headers get damaged is not that small, if they are too close 
to each other.

Same holds true when structured data is written over the header 
accidently. Depending on the FS and other things both headers could 
easily be damaged. Well, if the headers are far apart (start/end) this 
could still happen ... true.

The LUKS-header (including key material, which indeed is vital and needs 
to be replicated as well) is not as small as you might think, as the 
size strongly depends on various parameters.

IMHO a small 1 MB gap is not really an option, as most problems won't be 
really solved by this.

It would be possible to place the header at floor(dev_sectors/2) or 
something, but this would be pretty complicated, as you'd have to add a 
dm-layer to tie together the backing device split by the header or 
modify dm-crypt in ther kernel to skip over the gap properly. This seems 
a little too nasty for me.

Regards

-Sven

Am 08.02.2016 um 03:06 schrieb f-dm-c@media.mit.edu:
>      > Date: Mon, 8 Feb 2016 00:17:50 +0100
>      > From: Arno Wagner <arno@wagner.name>
>
>      > I see your problem. The more simple solution would be to
>      > default to a header copy at the end (people being careless),
>      > but to allow to explicitely disable/endable it on creation
>      > and later. In fact, I am very much for adding these options.
>
> That still seems to be more complicated than it needs to be.
>
>      > You and (likely) I would run with single headers, but looking
>      > at the history of this list, that default backup header would
>      > have helped quite a few people.
>
> Even a second header right after the first---or with an empty gap of a
> meg or something---would solve the overwritten-by-OS problem, and even
> the bad-disk-sector-in-an-unfortunate-place problem, or the power-
> failure-exactly-when-modifying-a-keyslot problem.  It takes up so
> little space that just always doing it (unless it's a truly tiny
> container) would make sense, assuming you're going to change the
> format at all from only one header.  And it's way easier to do than to
> rely on correctly knowing the end of the container when that end might
> move.  That also means you don't need all kinds of fancy switches and
> options to control the behavior, -especially- switches and options
> that both installers and gparted etc must now learn to use whenever
> the container is being resized.  Either leave things with a single
> header, or just write a second one with a one meg empty gap between
> it and the first one, and call it a day already.
>
> [Putting the backup right at the end of the partition only solves some
> problems anyway---anything which moves a potential later partition
> backwards could overwrite it, and I've occasionally seen mistakes like
> that when repartitioning, depending on the tool.  Certain RAID formats
> put data near the end of the partition as well, and they often suffer
> obscure failures modes because of that as well.]
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>