Bug 468062

When writing out /etc/crypttab we are using the LUKS UUID, but we should instead be using whatever blkid sees as the UUID.

Having thought about this a little bit, I don't think that anaconda is the place to fix this. What is happening is libblkid is misinterpreting the device as ext4. Is this random data that happens to match the magic, or is it residual data on the device? I'd guess the latter.

One thing (dirty trick, I guess) that I expect would solve this is to move the LUKS entry to the beginning of the types array in probe.c. Thoughts?

Eric, can you attach the first several sectors of the block device in question?

Created attachment 321457 [details]
first 40k of LV

dd if=/dev/F10686VG00/LogVol01 of=/tmp/beginning bs=4096 count=10

Facts:
This LV was created BEFORE I ran anaconda.
At some point long ago it was formatted unencrypted ext4
Before this install it was formatted (from the beta anaconda) encrypted ext4 (it didn't work probably due to the same problem, but I didn't run it down)
In anaconda this I chose to format as encrypted ext3.

I don't like the fact that if anaconda queries for the p-word for a partition and you chose to format and encrypt that partition it doesn't give you the option to change the p-word...

(In reply to comment #4)
> I don't like the fact that if anaconda queries for the p-word for a partition
> and you chose to format and encrypt that partition it doesn't give you the
> option to change the p-word...

For the sake of simplicity we chose between:
 1. newly formatted fs means new luks header
 2. luks header only gets nuked if the user unchecks 'encrypt' and then hits 'ok'

The first option violates the principle of least surprise. Showing a dialog asking which you want just seems like yet another annoying dialog (to me).

So, to nuke your luks header, you uncheck 'encrypt', hit 'ok', then re-edit as you like. Not perfect, but not scary either.

3. add a little box to the right of the encrypt tick box, "set password"

if on new creation they don't click the box you ask them like they do now.  If someone wants to change it they have to click the box.  I don't think it would make it more annoying....

(In reply to comment #6)
> 3. add a little box to the right of the encrypt tick box, "set password"
> 
> if on new creation they don't click the box you ask them like they do now.  If
> someone wants to change it they have to click the box.  I don't think it would
> make it more annoying....

I know. We can put it next to the widgets that allow users to choose the encryption algorithm, key size, &c. Hmm, maybe move that into an "Advanced" tab that is initially hidden. If we're going that far, maybe it's time for system-config-luks... /me starts to cry

Seriously, for now, I had to draw the line somewhere. Who knows what the future may hold...

Ok, so, yes - both signatures are there.

[root@inode ~]# hexdump -C beginning  | more
00000000  4c 55 4b 53 ba be 00 01  61 65 73 00 00 00 00 00  |LUKS....aes.....|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  63 62 63 2d 65 73 73 69  |........cbc-essi|
00000030  76 3a 73 68 61 32 35 36  00 00 00 00 00 00 00 00  |v:sha256........|
00000040  00 00 00 00 00 00 00 00  73 68 61 31 00 00 00 00  |........sha1....|
...
00000400  00 00 01 00 00 00 04 00  33 33 00 00 9b ce 03 00  |........33......|
00000410  f5 ff 00 00 00 00 00 00  02 00 00 00 02 00 00 00  |................|
00000420  00 80 00 00 00 80 00 00  00 20 00 00 35 8d ec 48  |......... ..5..H|
00000430  83 90 ec 48 01 00 ff ff  53 ef 01 00 01 00 00 00  |...H....S.......|

(53 ef is the ext2/3/4 magic)

Based on Eric's details, the ext magic is old.

So really, mke2fs should be zeroing the first 1K up to it's superblock (maybe it is already, I need to double check) and cryptsetup (?) should probably be splatting some zeros over the first part of the device, as well.

I'll look at both ...

-Eric

ok, mke2fs does already zero the first 1k.

-Eric

I'm going to punt this over to cryptsetup-luks.  It looks like when it is creating a new volume, it should zero out a bit of the block device past the header that it is writing; would be simplest to just splat a few kilobytes of zeros or so onto the device, *then* write the header at the beginning.

This would erase older signatures.

FWIW, mkfs.xfs gave up trying to track all the ranges that needed to be hit, and just writes 128k of 0s to the beginning and end of the device to obliterate anything that might be there.

Hm, I think cryptsetup wipes enough space to remove all previous signatures but need to check it.
There is quite large area where are the keyslots stored (with the AF shuffle, so it iw rewrited) + writing visible header in the beginning, if there is still some remaining data between these areas, it is surely cryptsetup bug.

Cryptsetup save (uncrypted) physical header, current length is 2 sectors in the start of device.
From the 0x1000 ofset is stores crypted keyslot data.
Unfortunatelly there is space between this two areas which is not wiped and old data remains there - including ext2/3/4 magic.

I checked in patch to rawhide which wipes first 8 sectors with zeroes before the real header is written (8 sector is space before the keyslot data).

This should be problably fixed in new LUKS header revision by header padding, but for the time being the patch is enough.
I'll try to fix this upstream somehow too.

Anyway, old LUKS formatted volumes possibly contains these relic data, so blkid can fail fo them...

Fixed in build cryptsetup-luks-1.0.6-6.fc10.

While I'm sure this fixes that blkid thinks the type is ext4 does it fix that fact that the UUID from blkid != UUID from cryptsetup luksUUID yet the /etc/crypttab file was created as if they were the same?  If so, great, if not, we need to reopen....

In short: yes, it fixes it.

They will be the same if libblkid correctly detects the device as a LUKS device. The problem is that it incorrectly detected the device as an ext device and therefore used the ext UUID instead of the LUKS UUID. Had it correctly identified the device in the first place it would have used the correct UUID and there would not have been a problem.

It's fairly important that this fix get into F10. Milan, can you please do a build and a request to get it in?

(In reply to comment #15)
> It's fairly important that this fix get into F10. Milan, can you please do a
> build and a request to get it in?

Here is a ticket for this:
https://fedorahosted.org/rel-eng/ticket/991

Build was already in updates and now it is tagged to F10 too.
Also I committed patch to upstream svn a few days ago.