Bug 448665 - mkinitrd overrides /dev/urandom encrypted swap
mkinitrd overrides /dev/urandom encrypted swap
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-28 01:40 EDT by Jason Farrell
Modified: 2008-11-27 18:55 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-27 18:55:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jason Farrell 2008-05-28 01:40:39 EDT
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 17:43:39 EDT
Confirmed in F9 using keyfile (held in encrypted root) for unlocking swap.
Comment 2 Mike C 2008-08-07 18:07:11 EDT
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 18:11:03 EDT
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 17:24:49 EDT
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 12:06:13 EDT
Is this still an issue with mkinitrd in rawhide?
Comment 6 Jason Farrell 2008-08-23 21:03:29 EDT
(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 18:55:49 EST
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.