[dm-crypt] Detached headers, multiple drives and UUIDs
okozina at redhat.com
Mon Apr 10 17:16:36 CEST 2017
On 04/10/2017 04:33 PM, 7heo wrote:
> On Mon Apr 10 16:09:53 2017 GMT+0200, Ondrej Kozina wrote:
>> On 04/10/2017 03:45 PM, 7heo wrote:
>>> Hello Milan,
>>> Please tell me if my current assumptions are correct:
>>> 1. Any non-open LUKS data-only drive contains 100% random looking data
>>> (i.e. No metadata at all).
>> It depends. Old data is _not_ automatically re-written by luksFormat
>> operation during format operation. There may be old plain text data on
>> luks data device, unrelated to luks...
> By that question I didn't mean to ask what the data drive would contain from previous usages; but what dm-crypt/LUKS related data it would contain. Since you answered a different interpretation of my question, I am unsure as to what the answer of my current question is.
> So do the data-only devices contain any more LUKS/dm-crypt relevant information than the binary data itself?
No, cryptsetup doesn't store any metadata on data device if you use
detached header scenario.
>>> 2. The UUID needs to match the header during drive opening only (after
>>> that it is in RAM).
>> No, it's checked (header uuid must match active dm-crypt device) also
>> with different cryptsetup commands.
> Ok so the header is continuously checked. I did not expect that, and expected all of it to be copied in memory until hibernation/shutdown. Thanks for the information.
>>> 3. It is therefore possible to change the UUID on the fly while
>>> activating the disk, when putting the key in memory.
>> No you can't change UUID of active dm-crypt device without deactivating
>> it. It's device-mapper restriction and it has a good reason.
> The idea was/is to change it while opening/activating it, not after.
No, you can't change uuid even during dm-crypt activation. The uuid has
to match the one found in header.
>>> 4. The on-the-fly UUID can be computed using partially the detached
>>> header UUID and a hash of the data drive being opened.
>> There's no connection between detached luks header and inactive (no
>> dm-crypt mapping active) separate data device, again on purpose.
> I am not sure what you are answering to, the "on the fly UUID" was referring to the previous point, it does not make much sense without it.
Well in that case I truly don't understand the question. There's no
connection between luks header and data device while being inactive or
even while being activated. You may activate whatever data device if you
supply correct passphrase for the header.
To follow on answer to Q1. there's data/information on data device that
would link it to the detached header and vice versa.
For user the only indication he paired the right header with right data
device is that the decrypted data (activated dm-crypt device) makes
sense. iow user is able to mount fs because there's visible fs
superblock and not 'garbage/noise'.
More information about the dm-crypt