[dm-crypt] The future of disk encryption with LUKS2
sven at whgl.uni-frankfurt.de
Wed Feb 10 14:48:48 CET 2016
While I understand your arguments, many of these issues can be addressed
more or less easily. If we talk about really complex setups, we
hopefully consider these not average user cases and non average users
are always on their own, at least to some extent.
Concerning GPT, it already collides with mdadm metadata, while mdadm
metadata at the start of device does have it's own serious issues aswell.
And to be honest, there is no way around the user knowing the layering
anyway and letting him/her do the necessary steps in the correct ordering.
The current LVM man pages still suggests that resizing with multiple
metacopies is not working, if it does work nowadays, the man page needs
BTW: Personally I think that one thing in the blockdevice stack was
screwed up severely: Always have information on the upper layer in the
lower layer - That would eliminate most issues. On the lowest layer we
do have that information (PARTUUID/PARTTYPE), it is just mostly ignored.
Am 10.02.2016 um 09:37 schrieb Milan Broz:
> 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.
> dm-crypt mailing list
> dm-crypt at saout.de
More information about the dm-crypt