Bug 448665 - mkinitrd overrides /dev/urandom encrypted swap
Summary: mkinitrd overrides /dev/urandom encrypted swap
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: mkinitrd
Version: 9
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-05-28 05:40 UTC by Jason Farrell
Modified: 2008-11-27 23:55 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-11-27 23:55:49 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jason Farrell 2008-05-28 05:40:39 UTC
Description of problem:
Manually setting up encrypted swap post-install using "/dev/urandom" as the key,
and "swap" as an option in /etc/crypttab to reformat it works fine (supported by
/etc/rc.sysinit) until a kernel update comes along and does its mkinitrd, which
then overrides this by using the first swap in /etc/fstab as an encrypted
swsuspdev resume device. You're then prompted to manually enter the luks
password, which doesn't exist in this case, because encrypted swap is being
recreated with a random key on each boot.

Version-Release number of selected component (if applicable):
mkinitrd-6.0.52-2.fc9.x86_64

How reproducible:
After installing a kernel update

Steps to Reproduce:
1. Do a default F9 install (without any disk encryption)
2. Convert LogVol01 swap to luksFormat encrypted swap using /dev/urandom as key:
 a. swapoff /dev/mapper/VolGroup00-LogVol01
 b. cryptsetup -d /dev/urandom create luks-VolGroup00-LogVol01
/dev/mapper/VolGroup00-LogVol01
 c. mkswap /dev/mapper/luks-VolGroup00-LogVol01
 d. swapon /dev/mapper/luks-VolGroup00-LogVol01
 e. echo "luks-VolGroup00-LogVol01  /dev/mapper/VolGroup00-LogVol01 
/dev/urandom  swap" >> /etc/crypttab
 f. modify /etc/fstab to use "/dev/mapper/luks-VolGroup00-LogVol01" as the new
encrypted swap device (which needs to be the first swap in fstab for mkinitrd to
use it)
3. Reboot and "swapon -s" to verify that encrypted swap was automatically setup
using /dev/urandom as key per /etc/crypttab.
4. Update the kernel, or manually run mkinitrd: mkinitrd -v -f
/boot/initrd-$(uname -r).img $(uname -r)
5. Reboot once more
  
Actual results:
the newly generated initrd is now doing its own early cryptsetup for swap and
prompting for a non-existent luks password.

Expected results:
mkinitrd should parse /etc/crypttab and exclude doing cryptsetup for swap if the
user is using /dev/urandom, /dev/random, or /dev/hw_random as a reinitialization
key.  (akaik, /dev/urandom can't exist in initrd so excluding it is the best option)

Additional info:
there might be similar issues if using a keyfile VS /dev/urandom

As a temporary workaround I've just hacked /sbin/mkinitrd to exclude my specific
swap device:

emitcrypto()
{
    # parse /etc/crypttab instead at some point and exclude any entry
    # where field #3 is /dev/urandom and #4 is "swap"
    # also: add "export noresume=1" to /etc/sysconfig/mkinitrd
    if [ "$2" != "luks-vgr10-swapcrypt" ]; then
        emit "echo Setting up disk encryption: $1"
        emit "cryptsetup luksOpen $1 $2"
    fi
}

Comment 1 Mike C 2008-08-07 21:43:39 UTC
Confirmed in F9 using keyfile (held in encrypted root) for unlocking swap.

Comment 2 Mike C 2008-08-07 22:07:11 UTC
In my case I allowed the f9 install to create an encrypted swap and encrypted root partition.

Once the install was complete then in the early boot phase the luks passphrase for root is requested, followed immediately by the request for the luks passphrase for the swap partition.  

Creating a keyfile that is stored in /root, and adding this (luksAddKey) to the swap partition, and then adding the 3rd field to /etc/crypttab with the path to the keyfile does not allow the swap partition to be opened without a passphrase prompt at boot. Manually executing mkinitrd to create a new initial ramdisk file still gives a passphrase prompt for the swap partition during boot.

Presumably a modified mkinitrd would bypass this in a newly created initrd?

So there would need to be an additional search on /etc/crypttab 
   # where field #3 is /dev/urandom and #4 is "swap" (or blank?)
and then exclude the swap partition when running mkinitrd?

Comment 3 Mike C 2008-08-07 22:11:03 UTC
In comment #2
   # where field #3 is /dev/urandom and #4 is "swap" (or blank?)
Should perhaps be
   # where field #3 is /dev/urandom OR !NONE and #4 is "swap" (or blank?)

Any filename replacing /dev/urandom, and within the /root area or other place in the root partition would make sense provided the root partition is also encrypted.

Comment 4 Chris Underhill 2008-08-20 21:24:49 UTC
I've just been bitten by this bug. Only encrypted partition I have is for swap. Entry in /etc/crypttab is

swap1   /dev/sda6       /dev/urandom    swap,cipher=aes-cbc-essiv:sha256

so I was somewhat perplexed that after rebooting to a new kernel, I was prompted for the LUKS passphrase!

The /etc/fstab entry corresponding to this is:

/dev/mapper/swap1       swap                    swap    defaults        0 0

mkinitrd version is mkinitrd-6.0.52-2.fc9.x86_64.

Comment 5 Warren Togami 2008-08-22 16:06:13 UTC
Is this still an issue with mkinitrd in rawhide?

Comment 6 Jason Farrell 2008-08-24 01:03:29 UTC
(In reply to comment #5)
> Is this still an issue with mkinitrd in rawhide?

I wasn't able to reproduce with mkinitrd.6.0.62-1 in rawhide, no. I don't see /etc/crypttab being parsed for exclusions, but neither did I see dm-crypt added or the new emit plymouth cryptsetup added to the initrd this time.

When "Looking for driver for device mapper/luks-VolGroup00-LogVol01", it's no longer found. A quick look at the old vs new diff doesn't tell me if that's a fix, or a happy coincidence.

Comment 7 Jason Farrell 2008-11-27 23:55:49 UTC
fixed in f10. I've converted my swap as above, re-ran mkinitrd, and am not prompted for a password, as expected.


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