[dm-crypt] The future of disk encryption with LUKS2
arno at wagner.name
Fri Feb 5 11:56:02 CET 2016
I think you are asking for a lot more "magic" than is safe
here. If you are a mrer "user", you have no business resizing
a LUKS container in the first place. You need to know what you
are doing to do so safely.
On Thu, Feb 04, 2016 at 19:42:43 CET, Michael Kjörling wrote:
> 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.
> > 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.
> > 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
> Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
> “People who think they know everything really annoy
> those of us who know we don’t.” (Bjarne Stroustrup)
> dm-crypt mailing list
> dm-crypt at saout.de
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno at wagner.name
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
A good decision is based on knowledge and not on numbers. -- Plato
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
More information about the dm-crypt