[dm-crypt] The future of disk encryption with LUKS2
sven at whgl.uni-frankfurt.de
Mon Feb 8 03:46:27 CET 2016
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.
Am 08.02.2016 um 03:06 schrieb f-dm-c at media.mit.edu:
> > Date: Mon, 8 Feb 2016 00:17:50 +0100
> > From: Arno Wagner <arno at 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 at saout.de
More information about the dm-crypt