Re: [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data

[Milan Broz <gmazyland@gmail.com>]

On 12/30/2012 09:42 AM, Sven Eschenberg wrote:
> Hi Milan,
> 
> What happens though, if signatures are not accessible during luksFormat?
> (Or alternatively, are not found, because they are misaligned from the
> current setup's perspective?)
> 
> Scenario, create a md volume with 1.0 metadata (end of device), start md
> device, do luks format.

Well, there are priorities but in fact these configurations need some
external info (or admin knowledge).

> Now, in intial unused state, the luks header and md metadata is visible.
> While cryptsetup might be able to realize that the md device should first
> be started, this might not be true for all tools (unfortunately). Possible
> similiar scenarions with leftover superblocks etc. can surely be created.

Yes, and in the MD format (end of device) case the problem repeats very often.

> I am aware this is a specific case due to the end of device policy of the
> md metada v1.0. What I am trying to say is, not all cases can
> automagically be resolved, sometimes the knowledge and interaction of an
> admin might really be required. And for educated guessing, the admin needs
> to be educated beforehand ;-).

Yes, fully agree. I can mention other situations, which can be configured
this way (LVM has several such undocumented scenarios) where you cannot
automatically say which signature is the first...

(I can write very long description about plans about "block device assembly"
library under util-linux project which should help to solve this, but I am
afraid that I will not work on this project anymore.)

And because we are on dmcrypt list - there is always need from security
(or paranoid ;) people to separate or hide metadata (e.g. LUKS header or
hidden container). In this situation you simply must know some info in advance
to properly activate such storage...

Milan