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. > 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 implications. -- Michael Kjörling • https://michael.kjorling.se • michael@xxxxxxxxxxx “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
