Hi all,
Am 04.02.2016 um 19:42 schrieb Michael Kjörling:
On 4 Feb 2016 18:23 +0100, from arno@xxxxxxxxxxx (Arno Wagner):
if you place a copy of the header at the end,
It doesn't need to be at the end of the container either; that's just
a convenient spot, particularly because the size of the device backing
the container is already known and it's far away from the beginning of
the container. The most important aspect would likely be that the two
locations are unlikely to be affected by any single error, which is
trivial to show to be the case on HDDs with far-removed LBA addresses,
and is easy to argue is highly likely on SSDs in the same case.
Well there's only two ways, storing it based on the device's size, or at
a fixed offset (which would imply a minimum size of offset+headersize).
The latter seems plain wrong. So yes, in contrast to the current
situation the logic to determine device size, placing the header and so
on needs to be added.
you already
need some way to know where the end is and to reserve space
at it. A resize could then be as simple as an additional
"luksUpdateHeaderCopy" afterwards (whith all other
header-changing operations doing that implicitely already).
I don't know anything about what hooks are available or practical, but
an alternative might be to hook into the "resize" control flow and
move the header through there. That would be a much cleaner approach
from a user point of view.
As a user, I would want a usable encrypted container; I don't really
care where on the disk the metadata to implement this is stored, and I
certainly wouldn't want the documentation to say "oh, and after you
run this, you MUST run this other command" just to keep the container
in a consistent state. That would feel very amateurish. It would be a
bit like if I store a file on a RAID 1, I then have to resilver the
array to make sure that the file is on all constituent devices.
Keeping consistency is of course not the user's job. But when we look at
v2 design changes, these things need to be addressed and evaluated.
While an ACID-Transaction to move the header is no magic, things need to
be crafted carefully. Milan already said there's some sort of replay log
planned or WIP.
For completeness and security (preventing an old copy
of the header from lingering), a "luksNukeHeaderCopy"
would also be required.
This should be handled transparently by luksErase and/or resize, for
the same reason cited above; all commands that use or affect the LUKS
header should strive to keep the container in a consistent state,
including ensuring that both copies of the metadata are synchronized.
If absolutely necessary, a command-line switch could be added to
disable that behavior, with clear warnings about the potential
implications.
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
