Re: [dm-crypt] what touches the LUKS header?

[epvdm@limpoc.com]

On Sun, Aug 08, 2010 at 02:53:47AM +0200, Arno Wagner wrote:
> 
> So this is an n-way (n>2) RAID1?
> 

It's a 2-way raid1, but i've (prior to the failure, of course) pulled copies 
of it by breaking one member out, and resyncing a new blank drive to it. 
I've done this many times in the past without trouble but I'm willing to 
accept that it could be bad... 


> > I'm wondering if the header area ever gets written to under normal operation
> > such that a crash could have left it corrupted, or if it's only written when
> > modifying keyslots, etc... 
> 
> As far as I am aware of, nothing gets written unless you change
> a key-slot.

That makes sense, and it's what I expected. 

> AFAIK the above error will also happen if the key has been corrupted.
> As you can see from the FAQ, every key is about 128kB in size. Any bit 
> changed in the key-stripes will result in unrecoverability.
> 
> I have been using md-RAID for a long time, also in a 3-way RAID1
> configuration and never had any corruption that I know of. For 
> the time I would rule that out, especially if the data area on all
> mirrors is equal. I think you should compare the  header, keyslots and
> key-stripes though. One way to do that would be to use 'cmp' on the 
> raw devices and see where the first different byte is.


> The one possibility when md will ever corrupt somethin is when
> you get a manual mapping of the RAIDed area wrong and the 
> RAID superblock happens to fall into a data area.
> 
> There is a second possibility: Keyboard input problems. I know
> it sounds stupid, but try every character and symbol you have in
> your passphrase and see whether it echos right.

Oh, certainly. I spent a long time on this before even looking into other
possibilities. I put the disks on another machine to test, and tried with
the passphrase in a keyfile, loaded with --key-file, with and without
trailing cr/lf, as well as typing the passphrase in the clear and cut-n-pasting
it into the cryptsetup prompt. 

for what it's worth, the partitions are identical at least for a few gigabytes
in. Though I haven't compared the whole 900+ GB, I assume 3 or 4 GB should be
more than enough to cover any possible key material. So whatever corruption
has happened would seem to have been above the disk level. 

here's a couple of questions - first, how do I determine the total extent
of the partition in which corruption could cause this problem; i.e, header,
all key material? And second, is that area sparse, or should it all be
filled in. I was thinking of looking through it manually trying to find 
patterns of data that might have been dropped on top of it from buffer cache
or elsewhere, for instance readable text, raid or filesystem superblocks,
magic numbers of common executable or other file types, etc. This could at 
least provide a clue. But if the area is sparse and might normally contain 
data that was already on the raw partition before it was luksFormatted, it 
would be more difficult. 

thanks very much for your help,  btw. 

eric
> 
> Arno
> -- 
> Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
> GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
> ----
> Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
> 
> If it's in the news, don't worry about it.  The very definition of 
> "news" is "something that hardly ever happens." -- Bruce Schneier 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt