[dm-crypt] The future of disk encryption with LUKS2
sven at whgl.uni-frankfurt.de
Thu Feb 4 21:51:14 CET 2016
Am 04.02.2016 um 19:42 schrieb Michael Kjörling:
> On 4 Feb 2016 18:23 +0100, from arno at wagner.name (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
More information about the dm-crypt