Re: The future of disk encryption with LUKS2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux