Bug 468062 - Encrypted LV has mismatching UUID
Encrypted LV has mismatching UUID
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: cryptsetup-luks (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Milan Broz
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F10AnacondaBlocker
  Show dependency treegraph
 
Reported: 2008-10-22 12:10 EDT by Eric Paris
Modified: 2013-02-28 23:06 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-30 07:02:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
first 40k of LV (40.00 KB, application/octet-stream)
2008-10-24 15:12 EDT, Eric Paris
no flags Details

  None (edit)
Description Eric Paris 2008-10-22 12:10:55 EDT
I installed F10-Snap2 reusing an existing partition layout from a previous F10 install.  On installer boot it ask for my encrypted partitions p-word and I gave it the p-word.

/dev/mapper/F10686VG00-LogVol00 swap
/dev/mapper/F10686VG00-LogVol01 /home
/dev/mapper/F10686Vg00-LogVol02 /

On all three LV's I selected to 'format as ext3' and for /home I selected 'encrypted'.  It did NOT ask me for a new /home p-word (which I think it should have)

After install the system failed to boot and dropped into maint mode because it couldn't mount /home.

/etc/fstab has:
/dev/mapper/luks-b30e9682-3df8-414b-a698-1d19764f1a2b /home  ext3 defaults        1 2

/etc/crypttab has:
luks-b30e9682-3df8-414b-a698-1d19764f1a2b UUID=b30e9682-3df8-414b-a698-1d19764f1a2b none

blkid shows:
/dev/mapper/F10686VG00-LogVol01: UUID="9c6023c5-c15e-4859-9b60-f4b3c510b8b4" TYPE="ext4" 

cryptsetup luksUUID /dev/mapper/F10686VG00-LogVol01 shows:
b30e9682-3df8-414b-a698-1d19764f1a2b

So notice that blkid UUID for the LV in question is not the same UUID that everything else is using and the TYPE= is clearly wrong and a remnant from a long past (at least 2 installs back) point in history.  In every install I do In at least the last 2 installs I selected to 'format' and to 'encrypt' this LV.

Changing /etc/crypttab to be:
luks-b30e9682-3df8-414b-a698-1d19764f1a2b UUID=9c6023c5-c15e-4859-9b60-f4b3c510b8b4 none

Caused the system to ask me for the p-word for /home and everything booted and mounted correctly.
Comment 1 David Lehman 2008-10-22 12:14:49 EDT
When writing out /etc/crypttab we are using the LUKS UUID, but we should instead be using whatever blkid sees as the UUID.
Comment 2 David Lehman 2008-10-23 14:23:27 EDT
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?
Comment 3 Eric Sandeen 2008-10-23 15:04:20 EDT
Eric, can you attach the first several sectors of the block device in question?
Comment 4 Eric Paris 2008-10-24 15:12:36 EDT
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...
Comment 5 David Lehman 2008-10-24 15:32:46 EDT
(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.
Comment 6 Eric Paris 2008-10-24 15:43:55 EDT
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....
Comment 7 David Lehman 2008-10-24 15:57:13 EDT
(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...
Comment 8 Eric Sandeen 2008-10-29 13:16:05 EDT
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
Comment 9 Eric Sandeen 2008-10-29 13:21:17 EDT
ok, mke2fs does already zero the first 1k.

-Eric
Comment 10 Eric Sandeen 2008-10-29 13:39:30 EDT
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.
Comment 11 Milan Broz 2008-10-29 14:33:15 EDT
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.
Comment 12 Milan Broz 2008-10-30 07:02:11 EDT
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.
Comment 13 Eric Paris 2008-10-30 09:08:00 EDT
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....
Comment 14 David Lehman 2008-10-30 09:18:32 EDT
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.
Comment 15 David Lehman 2008-11-06 16:47:05 EST
It's fairly important that this fix get into F10. Milan, can you please do a build and a request to get it in?
Comment 16 Till Maas 2008-11-06 17:02:45 EST
(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
Comment 17 Milan Broz 2008-11-07 03:35:49 EST
Build was already in updates and now it is tagged to F10 too.
Also I committed patch to upstream svn a few days ago.

Note You need to log in before you can comment on or make changes to this bug.