[dm-crypt] Detached headers, multiple drives and UUIDs

7heo 7heo at mail.com
Mon Apr 10 16:33:17 CEST 2017


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? 

> 
> > 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.

> 
> > 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. 

> 
> >
> > Or is any of this wrong? If it isn't possible, I could see a wrapper
> > around cryptsetup copying the headers around in a ramfs while doing the
> > aforementioned substitution. Or would that be impossible?
> 
> I'd say use the walkthrough Milan outlined. Create X copies of the 
> original header and have different (generated) UUID on each of those.
> 
> Having 2 or more devices with same UUID can lead only to problems. Don't 
> try to workaround it.

I am pretty sure at this point that we are failing to understand each other. What I meant is to ask wether or not it was a good idea (let alone possible)  to automatize the creation of the headers Milan advised me to create (and wipe them afterwards). I am very well aware of the problems that a non-unique UUID would cause; that is the main reason for my first email.

> 
> Kind regards
> Ondrej

Thanks for your time,
Theo.


More information about the dm-crypt mailing list