On 02/10/2016 12:35 AM, Arno Wagner wrote: > On Tue, Feb 09, 2016 at 23:08:19 CET, Lars Winterfeld wrote: >> On 08.02.2016 22:51, Milan Broz wrote: >>> [Just note to already crazy discussion here - there will be NO LUKS header >>> at the end of device. Been there with another storage project and >>> just no - it is not worth problems it causes.] >> >> Out of curiosity: what were those problems? I think the real problem was mentioning here several times - the device size sometimes changes and you have no real control over it. People resize partition tables, logical volumes, use dd from smaller disk to bigger (and vice versa but that's another story ;-) Then you have not always chance to properly wipe out old header, and in the LUKS case it is additional security risk. (If you do not wipe additional space it is not so big problem.) Also note that GPT stores backup header near the end of device, I can imagine various semi-destroyed headers by that as well. In case of a "forensic" recovery (you are trying to recover some partially wiped disk) it complicates thinks even more (should we expect that a second header somewhere on the device has correct device size in it or it is just old header and the real one was destroyed?) (If we have sequence if or epoch in such metadata - what to do if there is more recent version - because some people tried to recover with wrong device size (common mistake to try recovery before thinking of the real problem)? What if it is an older metadata from some previous install - can we expect always different UUID?) >From the LUKS POV it means that there is no need to change logic of backup and recovery of header (just replace header, no need to play magic with writing to device end). With external scripts (and even programs compiled without proper flags) you have even bigger chance to screw it up for large devices when calculating header position because of limited integers handling (note getsize/getsize64 in blockdev command for example). The implementation is more complicated but that's not the reason to reject it (despite I prefer simpler code). IIRC for lvm2 the resize with redundant metadata (located near the end of PV) was disabled for some time (code was not complete to handle it) but today it should work (just FYI). ... > Was the problem confusion/complexity because this > layering-sheme was violated? That is another problem - during storage stack resize you require user to do various complicated steps. If a layer just takes current device size without any complicated steps it effectively limits area for error. (Well, it can be exact opposite in some situations but I expect people are more extending devices than shrinking it.) (In current LUKS2 metadata we can store segment size, so we can limit device size in header but this is meant for some internal segment handling like reencryption which requires several segments of sliding window with limited size. Default is still "use current device size".) So my reason to not use header near the end of the device is mainly that security risk of possibly old keyslot material on device. Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
