Bug 124789 - [PATCH] Add encrypted root filesystem support to mkinitrd
[PATCH] Add encrypted root filesystem support to mkinitrd
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
:
: 115366 127183 157301 (view as bug list)
Depends On:
Blocks: FC7Target 211247 F8Target F9Blocker
  Show dependency treegraph
 
Reported: 2004-05-29 22:36 EDT by W. Michael Petullo
Modified: 2013-01-22 20:33 EST (History)
50 users (show)

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


Attachments (Terms of Use)
Patch to add support for encrypted root filesystems to mkinitrd (11.11 KB, patch)
2004-05-29 22:39 EDT, W. Michael Petullo
no flags Details | Diff
Patch to add support for encrypted root filesystems to mkinitrd (14.48 KB, patch)
2004-06-19 23:50 EDT, W. Michael Petullo
no flags Details | Diff
Patch to add support for encrypted root filesystems to mkinitrd (14.60 KB, patch)
2004-07-05 22:40 EDT, W. Michael Petullo
no flags Details | Diff
Patch to add support for encrypted root filesystems to mkinitrd (15.80 KB, patch)
2004-08-17 00:06 EDT, W. Michael Petullo
no flags Details | Diff
Patch to add support for encrypted root filesystems to mkinitrd (5.92 KB, patch)
2004-08-28 17:20 EDT, W. Michael Petullo
no flags Details | Diff
Patch to add support for encrypted root filesystems to mkinitrd (5.92 KB, patch)
2004-08-28 17:20 EDT, W. Michael Petullo
no flags Details | Diff
Patch to add support for encrypted root filesystems to mkinitrd (7.11 KB, patch)
2004-09-02 22:44 EDT, W. Michael Petullo
no flags Details | Diff
Patch to add support for encrypted root filesystems to mkinitrd (7.56 KB, patch)
2004-10-19 14:32 EDT, W. Michael Petullo
no flags Details | Diff
Patch to add support for encrypted root filesystems to mkinitrd (3.47 KB, patch)
2004-12-01 23:30 EST, W. Michael Petullo
no flags Details | Diff
Patch to add support for encrypted root filesystems to mkinitrd (5.20 KB, patch)
2004-12-02 12:11 EST, W. Michael Petullo
no flags Details | Diff
Patch to add support for encrypted root filesystems to mkinitrd (5.97 KB, patch)
2004-12-08 22:53 EST, W. Michael Petullo
no flags Details | Diff
Patch to add support for encrypted root filesystems to mkinitrd (6.08 KB, patch)
2005-04-21 23:41 EDT, W. Michael Petullo
no flags Details | Diff
Patch to add support for encrypted root filesystems to mkinitrd (6.20 KB, patch)
2005-06-19 23:07 EDT, W. Michael Petullo
no flags Details | Diff
Utility to provide stdin to cryptsetup in nash. (461 bytes, text/plain)
2005-08-15 14:18 EDT, R. Suter
no flags Details
Patch to add support for encrypted root filesystems to mkinitrd (6.54 KB, patch)
2006-08-10 07:22 EDT, W. Michael Petullo
no flags Details | Diff
Patch to add support for encrypted root filesystems to mkinitrd (9.50 KB, patch)
2006-08-13 17:05 EDT, W. Michael Petullo
no flags Details | Diff
Patch to add support for encrypted root filesystems to mkinitrd (9.50 KB, patch)
2006-08-20 17:23 EDT, W. Michael Petullo
no flags Details | Diff
Patch to add support for encrypted root filesystems to mkinitrd (9.50 KB, patch)
2006-08-20 17:29 EDT, W. Michael Petullo
no flags Details | Diff
Patch to add support for encrypted root filesystems to mkinitrd (9.50 KB, patch)
2006-08-20 17:30 EDT, W. Michael Petullo
no flags Details | Diff
Patch to add support for encrypted root filesystems to mkinitrd (9.50 KB, patch)
2006-08-20 17:32 EDT, W. Michael Petullo
no flags Details | Diff
Patch to provide encrypted root filesystem support in mkinitrd, updated for mkinitrd-5.1.9 (8.97 KB, patch)
2006-08-20 20:05 EDT, Michael Hampton
no flags Details | Diff
Patch to add support for encrypted root filesystems to mkinitrd (9.59 KB, patch)
2006-08-27 14:10 EDT, W. Michael Petullo
no flags Details | Diff
Patch to add support for encrypted root filesystems to mkinitrd (11.88 KB, patch)
2006-09-03 13:25 EDT, W. Michael Petullo
no flags Details | Diff
Patch to add support for encrypted root filesystems to mkinitrd (11.71 KB, patch)
2006-09-08 21:39 EDT, W. Michael Petullo
no flags Details | Diff
Patch to add support for encrypted root filesystems to mkinitrd (11.66 KB, patch)
2006-09-11 20:34 EDT, W. Michael Petullo
no flags Details | Diff
Patch to add support for encrypted root filesystems to mkinitrd (11.79 KB, patch)
2006-11-19 13:52 EST, W. Michael Petullo
no flags Details | Diff
Simple program to query password from user and store it to a file (870 bytes, text/plain)
2006-12-16 12:24 EST, Stefan Becker
no flags Details
Patch to add support for encrypted root filesystems to mkinitrd (12.93 KB, patch)
2006-12-25 11:04 EST, wesley.wright
no flags Details | Diff
Patch to add encrypted root fs support to mkinitrd w/modular CBC (12.95 KB, patch)
2007-02-10 09:50 EST, Andy Walls
no flags Details | Diff
Patch to add encrypted swap and root fs support to mkinitrd w/modular CBC (15.78 KB, patch)
2007-02-18 12:11 EST, Andy Walls
no flags Details | Diff
Patch to add encrypted swap and root fs support to mkinitrd w/modular CBC on F7 (15.86 KB, patch)
2007-05-17 14:42 EDT, Tim Niemueller
no flags Details | Diff
Patch to add encrypted swap and root fs support to mkinitrd w/modular CBC on F7 (15.86 KB, patch)
2007-05-28 10:32 EDT, Tim Niemueller
no flags Details | Diff
Patch to add encrypted swap and root fs support to mkinitrd w/modular CBC on F7 (16.28 KB, patch)
2007-06-01 12:22 EDT, Karsten Hopp
no flags Details | Diff
Patch to add encrypted swap and root fs support to mkinitrd w/modular CBC on F7 (58.40 KB, patch)
2007-07-25 12:40 EDT, Kevin R. Page
no flags Details | Diff
Patch to add encrypted swap and root fs support, also with encrypted PV (21.39 KB, patch)
2007-08-19 20:07 EDT, Kevin R. Page
no flags Details | Diff
Additions for encrypted Physical Volumes (6.26 KB, patch)
2007-08-19 20:12 EDT, Kevin R. Page
no flags Details | Diff
Patch to add encrypted swap and root fs support, also with encrypted PV (22.26 KB, patch)
2007-08-20 13:49 EDT, Kevin R. Page
no flags Details | Diff
Diff between previous patch and current patch with encrypted PV (7.35 KB, patch)
2007-08-20 13:56 EDT, Kevin R. Page
no flags Details | Diff
HOWTO: Creating an encrypted Physical Volume using Fedora and patched mkinitrd (4.09 KB, text/plain)
2007-08-20 14:14 EDT, Kevin R. Page
no flags Details
Patch to add support for encrypted root filesystems to mkinitrd (22.10 KB, patch)
2007-11-12 08:58 EST, W. Michael Petullo
no flags Details | Diff
Patch to add support for encrypted root filesystems to mkinitrd (22.12 KB, patch)
2007-11-26 12:29 EST, W. Michael Petullo
no flags Details | Diff
Patch to add support for encrypted root filesystems to mkinitrd (22.13 KB, patch)
2007-12-17 18:34 EST, Robert Scheck
no flags Details | Diff

  None (edit)
Description W. Michael Petullo 2004-05-29 22:36:59 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.6)
Gecko/20040312 Epiphany/1.1.12

Description of problem:
I am interested in seeing Fedora support encrypted root filesystems. 
I wrote a patch for mkinitrd that adds this ability.

Eventually, I would like to see support for setting this stuff up
using anaconda.  Right now it has to be done by hand.  Here are the
steps to using this new feature:

1.  Install cryptsetup 0.2, which includes the new libcryptsetup. 
This package is available at: 

http://www.saout.de/misc/dm-crypt/cryptsetup-0.2-pre1.tar.bz2

2.  Add -lselinux to cryptsetup's main Makefile, as this is needed on
Fedora.

3.  Create a VFAT filesystem on a memory stick and mount it at /<mntpt>.

4.  Create a filesystem key using: dd if=/dev/random of=/<mntpt>/efsk
bs=1 count=32.

5.  Prepare the encrypted device using: cat /<mntpt>/efsk | cryptsetup
-h plain create root /dev/<realrootdev>.

6.  Create the encrypted filesystem: mkfs.ext3 /dev/<realrootdev>. 
Populate the filesystem.

7.  Create your initrd: mkinitrd --keydev=/dev/<memorystickdevice>
--keypath=efsk --keymat-fstype=vfat --initrd-fstype=<realrootfstype>
-f <locationofinitrdimage> <kernelversion>.

Version-Release number of selected component (if applicable):
mkinitrd-3.5.22

How reproducible:
Always

Steps to Reproduce:
Notice that mkinitrd does not support encrypted root filesystems.  

Additional info:
Comment 1 W. Michael Petullo 2004-05-29 22:39:18 EDT
Created attachment 100700 [details]
Patch to add support for encrypted root filesystems to mkinitrd
Comment 2 Alasdair Kergon 2004-06-03 14:47:00 EDT
Anything like this has to be done generically, so it would work for
all supported system configurations.

Hard-coding like 
'mknod $MNTIMAGE/dev/mapper/control c 10 63' 
is a complete no-no.

Ought to sort out the required generic functionality first - e.g. what
options for entering keys are reasonable in a boot-up situation for
different people to choose between?

Does cryptsetup 0.2 still pull in an unnecessary(?) libgcrypt
dependency?  Is it simpler to use dmsetup directly sometimes?
Comment 3 Jeremy Katz 2004-06-04 16:40:00 EDT
Note that hard-coding /dev/mapper/control like that is unnecessary
with nash's mkdmnode function.  But I agree that there are a lot of
unanswered questions before applying this makes sense -- we need to
have the whole system-wide picture of how encrypted filesystems works.
Comment 4 W. Michael Petullo 2004-06-07 11:02:53 EDT
My plan is to continue working on this patch to make it more generic,
etc.  Whether this work serves as simply a proof of concept or is
actually integrated into mkinitrd, I hope to start getting things
moving forward.  I appreciate the feedback so far and look forward to
receiving more in the future.
Comment 5 W. Michael Petullo 2004-06-19 23:50:14 EDT
Created attachment 101270 [details]
Patch to add support for encrypted root filesystems to mkinitrd

This new patch has the following additions over the last one:

o use nash's mkdmnod instead of mknod
o took USB module loading code; use --with-usb instead
o requires patch to initscripts (see bug #125086)
o start to add support for other authentication methods
Comment 6 W. Michael Petullo 2004-07-05 22:40:36 EDT
Created attachment 101644 [details]
Patch to add support for encrypted root filesystems to mkinitrd

This version add the ability to read /etc/sysconfig/rootfs, a configuration
file that should be created when the root filesystem is formatted.  Here is an
example of the contents of this file:

AUTHTYPE=filesystem
KEYDEV=/dev/sda
KEYPATH=efsk
KEYMAT_FSTYPE=vfat
ROOT_CIPHER=aes

This allows mkinitrd to be run from RPM %post scripts and such without any
special command line arguments.  Arguments like --authtype will still override
the contents of /etc/sysconfig/rootfs.
Comment 7 Jeremy Katz 2004-07-06 18:25:05 EDT
*** Bug 115366 has been marked as a duplicate of this bug. ***
Comment 8 Matt Domsch 2004-07-12 08:58:00 EDT
*** Bug 127183 has been marked as a duplicate of this bug. ***
Comment 9 Russell Coker 2004-08-15 23:44:05 EDT
I think that using a /etc/crypttab file in the same format as Debian 
will make things a lot easier.  Here is a sample crypttab: 
 
# <target device> <source device> <key file> <options> 
swap    /dev/V0/swap       /dev/random     swap 
root    /dev/V0/fc2       /etc/root-key     defaults 
 
For example the above file would specify that the 
device /dev/mapper/swap would be /dev/V0/swap encrypted with a key 
from /dev/random.  In Debian the "swap" parameter at the end of the 
line indicates that after the encrypted device is setup the command 
"mkswap" should be run on it. 
 
Now mkinitrd could check /etc/fstab, see that the root device 
is /dev/mapper/root, look for the appropriate entry in /etc/crypttab 
then know it needs to put /etc/root-key in the initrd and do the 
mapping from /dev/V0/fc2 . 
 
Comment 10 W. Michael Petullo 2004-08-17 00:06:17 EDT
Created attachment 102779 [details]
Patch to add support for encrypted root filesystems to mkinitrd

Please: NO STABLE SYSTEMS YET!

This new patch has the following changes over the last one:

1.  Now reads /etc/crypttab instead of /etc/sysconfig/rootfs to be consistent
with bug #127378.

2.  Now provides a new authentication type "paranoid" that assumes the initrd
will be installed on a removable device.  This device is assumed to be
physically secured and will contain a plaintext copy of the encryption key.  To
use this mode: mkinitrd --authtype=paranoid -f /boot/initrd.gz 2.6.8.

3.  Patch is against mkinitrd 4.0.5.
Comment 11 W. Michael Petullo 2004-08-28 17:20:09 EDT
Created attachment 103215 [details]
Patch to add support for encrypted root filesystems to mkinitrd

Please: NO STABLE SYSTEMS YET!

This new patch has the following changes over the last one:

1.  No longer requires libcryptsetup.  This patch may now be used with the
stock Fedora cryptsetup RPM, as long as it is compiled statically (see bug
#129926).

2.  The "filesystem" authtype is no longer worked due to change 1.

3.  The patch is against 4.1.8, but I have been having trouble with 4.1.8 on my
iBook.	The patch applies cleanly against 4.1.1 and this is the version I am
currently using.
Comment 12 W. Michael Petullo 2004-08-28 17:20:21 EDT
Created attachment 103216 [details]
Patch to add support for encrypted root filesystems to mkinitrd

Please: NO STABLE SYSTEMS YET!

This new patch has the following changes over the last one:

1.  No longer requires libcryptsetup.  This patch may now be used with the
stock Fedora cryptsetup RPM, as long as it is compiled statically (see bug
#129926).

2.  The "filesystem" authtype is no longer worked due to change 1.

3.  The patch is against 4.1.8, but I have been having trouble with 4.1.8 on my
iBook.	The patch applies cleanly against 4.1.1 and this is the version I am
currently using.
Comment 13 W. Michael Petullo 2004-09-02 22:44:28 EDT
Created attachment 103419 [details]
Patch to add support for encrypted root filesystems to mkinitrd

Please: NO STABLE SYSTEMS YET!

This new patch has the following changes over the last one:

1.  Now assumes that a statically linked cryptsetup exists in /sbin (see bug
#129926).

2.  Now handles the fourth field in /etc/crypttab, the options field.  For
example, "cipher=aes."

3.  The patch is against 4.1.9.
Comment 14 W. Michael Petullo 2004-10-19 00:56:16 EDT
Cryptsetup is now statically linked.  Can we get this encrypted root
code in?  If not, what needs to be done?
Comment 15 W. Michael Petullo 2004-10-19 14:32:38 EDT
Created attachment 105456 [details]
Patch to add support for encrypted root filesystems to mkinitrd

Patch is now against mkinitrd 4.1.18.
Comment 16 Jeremy Katz 2004-10-19 14:40:20 EDT
It's far too late in the FC3 cycle to add things like this.  But I'll
look at it again after FC3 goes out for FC4.
Comment 17 W. Michael Petullo 2004-11-28 11:43:19 EST
The patch against mkinitrd-4.1.18 still applies cleanly to
mkinitrd-4.1.19-1.
Comment 18 W. Michael Petullo 2004-12-01 23:30:43 EST
Created attachment 107752 [details]
Patch to add support for encrypted root filesystems to mkinitrd

Please: NO STABLE SYSTEMS YET!

The --authtype option has been removed.  This was done so that initrds may be
created for encrypted root systems by new-kernel-pkg (no difference in argument
signature vs. standard non-encrypted system).  Instead of using the
--authconfig argument, mkinitrd not automatically determines if the root
filesystem is encrypted by looking at /etc/fstab and /etc/crypttab.  The
"paranoid" authtype is for now the only method supported.  This method stores
the root filesystem key in the initrd and assumes the initrd is on some type of
removable medium.
Comment 19 W. Michael Petullo 2004-12-02 12:11:02 EST
Created attachment 107778 [details]
Patch to add support for encrypted root filesystems to mkinitrd

Please: NO STABLE SYSTEMS YET!

This version of the patch adds to grubby the ability to detect a system with an
encrypted root filesystem.  Grubby not notices when the device of the mounted
root filesystem != the bootloader's root= configuration.  If these two values
are not equal,	grubby looks for "root XXX..." in /etc/crypttab where XXX
equals the device of the mounted root.
Comment 20 Russell Coker 2004-12-08 10:23:00 EST
One thing you miss in the latest patch is support for an encrypted 
root device on top of an LVM volume. 
 
With your patch the code does the following starting at about line 
730 in mkinitrd: 
 
if [ "$kernelmajor" == "2.4" ]; then 
# kernel 2.4.x LVM stufff 
elif [ -n "$root_enc" ]; then 
# crypto-root stuff 
else 
# kernel 2.6.x LVM stuff 
fi 
 
What you really want is to have the crypto root stuff occurring 
outside the if statement in question.  Also inside the "if [ -n 
"$root_enc" ]; then" block you want to have "if [ -z $root_lvm ]; 
then" around the "mkdmnod" bit so that mkdmnod doesn't get called 
twice. 
 
 
Also in recent kernels the AES module is aes-i586 (maybe we should 
have an alias in the module-init-tools config). 
 
Comment 21 W. Michael Petullo 2004-12-08 22:44:06 EST
I'm sorry, but I don't have any experience with LVM volumes.  What I
do know is that right now if root_enc=1 then root_lvm=1 but root_lvm=1
does NOT mean root_enc=1.  The tests go like this (line 852):

if [ is LVM (actually is device mapper) ]; then
  root_lvm=1
  if [ is encrypted ]; then
    root_enc=1
  fi
fi

So, how can I support both of these cases:

LVM volume, unencrypted
LVM volume encrypted

?

I need a way to test if a root filesystem is really an LVM volume and
not possibly just a DM/encrypted volume.  In other words, how can I
ask "is this device mapper volume truly a LVM volume?"  Root_enc and
root_lvm need to be decoupled.

===

In my recent kernels, aes is not aes-i586 because my kernel is built
for PowerPC.  So I imagine an alias from aes to aes-i586 would make
i586 more consistent with other architectures.
Comment 22 W. Michael Petullo 2004-12-08 22:53:49 EST
Created attachment 108173 [details]
Patch to add support for encrypted root filesystems to mkinitrd

Please: NO STABLE SYSTEMS YET!

This version modifies new-kernel-pkg.  The change ensures that if a system's
root filesystem is /dev/mapper/root and a corresponding entry exists in
/etc/crypttab (meaning that / is encrypted), then the REAL device (ie:
/dev/hda5) specified in the kernel's "root=" command line argument.  Grub's
configuration file or /etc/yaboot.conf will contain "root=/dev/hda5" instead of
"root=/dev/mapper/root" after a kernel RPM is installed.  This is what
mkinitrd's initrd expects in the case of an encrypted root filesystem.
Comment 23 W. Michael Petullo 2004-12-13 11:19:23 EST
Some interesting concepts related to this RFI have been introduced on
the hal mailing list.  See:

http://lists.freedesktop.org/pipermail/hal/2004-December/001423.html
Comment 24 W. Michael Petullo 2005-04-21 23:41:56 EDT
Created attachment 113508 [details]
Patch to add support for encrypted root filesystems to mkinitrd

Now checks to see if /etc/crypttab exists before doing anything.
Comment 25 Matthew Miller 2005-04-26 12:30:06 EDT
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.
Comment 26 Robin Green 2005-06-15 18:56:43 EDT
SECURITY ISSUE:

I assume this patch uses the standard kernel dm-crypt. However, the developer of
loop-aes has argued last year that dm-crypt, in common with its predecessor, is
insufficiently secure. Have these security concerns been addressed yet?

See http://archives.free.net.ph/message/20040725.114236.8143e157.html (from July
2004) where he claims

"...both cryptoloop and dm-crypt use ciphers in insecure
and exploitable way."

and http://wiki.boum.org/TechStdOut/LinuxCryptoFSBrainStroming for some context.
Comment 27 Anchor Systems Managed Hosting 2005-06-16 06:26:02 EDT
(In reply to comment #26)
> SECURITY ISSUE:

Short answer: Yes. Mostly.

To summarise, there have traditionally been two long standing security issues
with the usage of Linux encrypted block devices.

1) Watermarking attack

The use of an Initialisation vector IV based on the sector number leads to
watermarking attacks.

As of kernel 2.6.10, the kernel contains the ESSIV generation mode. This IV
generator should defend against the attack (for new crypto devices which
specifically use this IV generator when created only!).

Details: It is easily possible to check for the existence of a specially
crafted file on the encrypted file system by taking advantage of the fact that
an IV based purely on the sector number will change only in the LSB (more
specificaly, a single known bit depending on padding scheme) between two
consecutive sectors out of any contiguous 3 sectors on the disc. This allows
an attacker to feed identical plaintext into CBC mode, generating identical
ciphertext. A sequence of identical ciphertexts over the disc can then be used
to leak a watermark. See http://clemens.endorphin.org/LinuxHDEncSettings for
details on ESSIV.

2) Key management

Humans suck at using passwords. Secure cryptographic keys are even worse. The
standard way of getting around this fact is to generate a strong random key
for the bulk encryption and then protect the key with a (much weaker) password
that a human can remember. To help prevent brute force attacks against the
password, a combination of salting and stretching is used.

Clemens Fruhwirth has created a meta-data format for use with encrypted block
devices which does the above. The format is available in his patched version
of cryptsetup:

    http://luks.endorphin.org/

(this should already be in FC. See bug 147313)



Using dm-crypt/cryptoloop in a scenario where an attacker can observe/modify
encrypted device data (whilst in/between use) is very likely to have
insecurities though.



To properly support encrypted block devices, I would hope/recommend that:

1) Only support devices with the LUKS meta data. Trying to auto-decrypt/perform    
   magic will only lead to bugs, data loss, and eventual madness. Plus there
   are already patches in the pipeline for hal/dbus support of LUKS formatted
   devices (for example, hot plugging of USB keys and having a passphrase
   dialog pop up).

2) Do NOT use /etc/crypttab, or key files. That is just crack. An encrypted
   block device with the LUKS meta-data block has a UUID. Use it. To make
   things friendly for humans make use of devlabel (may require patching).

   mkinitrd can be made to auto detect the use of dm-crypt via tracing the
   stack of block devices underneath the root FS (for example, mdadm -D for
   MD devices, dmsetup deps for LVM/dm-crypt devices). Basically have a list
   of handlers for all block device types in /proc/devices. I would hope that
   this would be used in general in order to make mkinitrd more robust against
   configuration file errors.

   Key data to only be supplied via user passphrases or from /dev/random
   (for those who choose to use encrytped swap). Eventually having support
   for key storage on smartcards/TPM would be cool, but not needed for first
   version of distribution support, and it is best to not encourage use of
   plaintext keys sitting in files on the computer.

3) Make sure that any initscripts recursively go through all block device
   setup routines (MD, LVM, dm-crypt, etc) so as to allow all (sane/insane) 
   device configurations to "just work". Can be easily implemented by having
   all block device setup scripts reside in a single directory. Iteratively
   loop over all scripts in directory and only stop once all scripts report
   no further changes (or a high loop limit is hit (eg 7)).
Comment 28 W. Michael Petullo 2005-06-16 11:26:26 EDT
Thank you for the suggestions in comment #27.

I have a question about point number two, "...[the] LUKS meta-data block has a
UUID."  How would this UUID be used?  

Currently, if /etc/fstab contains /dev/mapper/root then the parameters to create
/dev/mapper/root are looked up in /etc/crypttab.

I understand your recommendation of replacing /etc/crypttab with LUKS' meta-data.

This is how I would implement this:

For every UUID in /etc/fstab, the boot script checks every partition in
/proc/partitions for the LUKS UUID.  If it exists, then setup the dm-crypt
device.  Set /dev/root to point to the dm-crypt device.

In order to avoid the additional logic in the boot script then util-linux would
need to be patched.  But this effort seems stalled (see bug #56698) and has been
frustrated by the transition from cryptoloop to dm-crypt to LUKS/dm-crypt.

I would be interested to hear more specifics about what you envision.
Comment 29 Emmanuel Galanos 2005-06-17 22:40:20 EDT
(In reply to comment #28)
> I would like to hear more about the concepts that you spoke of. 
> Specifically, I have a question about point number two, "...[the] LUKS
> meta-data block has a UUID."  How would this UUID be used?

Its main use would be to ensure that the proper LUKS device is "opened"
during initrd's linuxrc execution (i.e. scan all block devices
in /proc/partitions and check the LUKS UUID against what is recorded in
initrd image from mkinitrd). This will ensure that the root device is
always constructed properly regardless of how discs change between
boots. There isn't much other use for it in the mkinitrd scenario. The
name of the dm-crypt device that gets created in linuxrc should be
copied from what it was at mkinitrd execution time.

On a more general distribution wide usage (e.g. multiple encrypted
partitions), there are two naming issues to consider:

1) Persistent name for a block device containing luks meta data.
2) Persistent name for dm-crypt mapped device from (1).

For the first version of distribution support, both of these issues can
be safely ignored though. I envisage that Anaconda could "open" LUKS
devices using the name /dev/mapper/dm-crypt-${UUID}. For any device with
a FS, Anaconda can actually just use the FS UUID and forget that the
FS is on an encrypted block device, otherwise /etc/fstab can contain:

/dev/mapper/dm-crypt-${UUID}  /something  some_fs_that_has_no_uuid

During system initialisation (and after driver setup), the first
initscript to run should do all block device setup (via the iterative
method mentioned previously and using the default name above for
dm-crypt devices).

> This is how I would implement this:
> 
> For every UUID in /etc/fstab, the boot script checks every partition in
> /proc/partitions for the LUKS UUID.  If it exists, then setup the dm-crypt
> device.  Set /dev/root to point to the dm-crypt device.

Are you referring to the initrd boot script, mkinitrd, or rc.sysinit
scripts ?

/etc/fstab is outside the scope of linuxrc in the initrd.

mkinitrd need only consult the fstab for the root FS (and then trace
devices needed and also compare against /proc/cmdline and mount table).
It can then add all dependent devices to linuxrc.

rc.sysinit scripts can ignore the fstab and just scan all partitions and
setup all block devices.

> In order to avoid the additional logic in the boot script then util-linux
> would need to be patched.  But this effort seems stalled (see bug #56698)
> and has been frustrated by the transition from cryptoloop to dm-crypt to
> LUKS/dm-crypt.

If all LUKS devices are either setup at boot or as plugged in (via the
hal daemon magic), then no util-linux patching is needed. Whilst some
people may like to be able to specify:

LUKS:f5d62883-2ea0-4dc2-99e7-d58080abb0b2 /backups auto defaults,noauto

it is not needed for initial distribution support.
Comment 30 W. Michael Petullo 2005-06-19 23:07:08 EDT
Created attachment 115668 [details]
Patch to add support for encrypted root filesystems to mkinitrd

This patch uses LUKS to store encryption parameters instead of using
/etc/crypttab.	I have begun to implement some of the recommendations in recent
comments.

A variation of the following will prepare a LUKS-encrypted root filesystem:

cryptsetup luksFormat /dev/hdaX /etc/root-key
cryptsetup -d /etc/root-key luksOpen /dev/hdaX root
mkfs.ext3 /dev/mapper/root
mount /dev/mapper/root /mnt
cp -ax / /mnt

At this point, the use of /etc/root-key is hard-coded into mkinitrd.  I hope to
replace this at some point.  Currently, it seems that the init script has
trouble reading a passphrase entered manually.	I am not yet sure if this is
because of limitations of nash or a missing stdin-related device.  Until this
is figured out, /etc/root-key will exist (encrypted) on / and also unencrypted
on the removable boot media.
Comment 31 Jeremy Katz 2005-08-08 18:15:00 EDT
*** Bug 157301 has been marked as a duplicate of this bug. ***
Comment 32 R. Suter 2005-08-15 14:18:31 EDT
Created attachment 117763 [details]
Utility to provide stdin to cryptsetup in nash.

Necessity being the mother of invention...  My need to be able to enter a
passphrase for the root partition became acute over the weekend and lead to
this quick and very dirty C program.  It simply closes the sdtin, stdout, and
stderr file descriptors and reopens them to the console device.  Then, it
shifts it's arguments and execs the new argv [0].  I compile it with the
following:

gcc -Wall console.c -static -static-libgcc -o console

My init nash script is as follows:

#!/bin/nash

mount -t proc /proc /proc
setquiet
echo Mounted /proc filesystem
echo Mounting sysfs
mount -t sysfs /sys /sys
echo Creating /dev
mount -o mode=0755 -t tmpfs /dev /dev
mknod /dev/console c 5 1
mknod /dev/null c 1 3
mknod /dev/zero c 1 5
mkdir /dev/pts
mkdir /dev/shm
mkdir /dev/mapper
mknod /dev/mapper/control c 10 63
echo Starting udev
/sbin/udevstart
echo -n "/sbin/hotplug" > /proc/sys/kernel/hotplug
echo "Loading scsi_mod.ko module"
insmod /lib/scsi_mod.ko
echo "Loading sd_mod.ko module"
insmod /lib/sd_mod.ko
echo "Loading libata.ko module"
insmod /lib/libata.ko
echo "Loading ata_piix.ko module"
insmod /lib/ata_piix.ko
echo "Loading jbd.ko module"
insmod /lib/jbd.ko
echo "Loading ext3.ko module"
insmod /lib/ext3.ko
echo "Loading LUKS modules"
insmod /lib/dm-mod.ko
insmod /lib/dm-crypt.ko
insmod /lib/aes-i586.ko
/sbin/udevstart
echo Creating root device
mkrootdev /dev/root
/sbin/console /sbin/cryptsetup luksOpen /dev/root root
echo Mounting root filesystem
mount -o defaults --ro -t ext3 /dev/mapper/root /sysroot
echo Switching to new root
switchroot --movedev /sysroot

It assumes /dev/mapper is setup correctly and the necessary .ko files are
included as well as cryptsetup.

This has the desired effect of pausing the boot until a passphrase is entered. 
This is only a proof of concept so use at your own discretion and risk.  I
consider it public domain so do with it as you will...
Comment 33 W. Michael Petullo 2005-08-26 21:58:49 EDT
I no longer have the time to maintain/promote this patch.  Does anyone who is
watching this bug wish to take over?
Comment 34 Stefan Pfab 2005-08-29 08:11:26 EDT
has anyone tested the tool + init-script mentioned in comment #32? I tried it on
stock fedora core 3 and it only says at boot time: "EXIT: /sbin/console exited
abnormally". When I try something like "./console ls" in a normal shell it works
as expected.
Comment 35 R. Suter 2005-08-29 08:54:43 EDT
I'm using it now in FC4.  I have not tested beyond that single install.

Did you link it statically?:

gcc -Wall console.c -static -static-libgcc -o console
Comment 36 Stefan Pfab 2005-09-05 04:39:49 EDT
it works now under FC3 :-)
1. I updated nash to 4.2.15 (new mkinitrd rpm of FC 4) + udev to 058-1. The
"switchroot" command in FC3 nash doesn't know the option --movedev
2. switchroot doesn't move the devicemapper correctly. In my init nash script it
says 
"/sbin/console /sbin/cryptsetup luksOpen /dev/root root"
which creates /dev/mapper/root. The following mount and switchroot works
correctly with /dev/mapper/root
But the rc script which tries to do an fsck on /dev/mapper/root fails because
there is no /dev/mapper/root and drops me to a rescue shell. Instead there is
/dev/dm-0 which is the devicemapper entry of the root-partition! I changed the
fstab from 
/dev/mapper/root              /            ext3   defaults 1 1
to
/dev/dm-0                     /            ext3   defaults 1 1
and now it works fine.
Comment 37 R. Suter 2006-01-09 16:43:51 EST
In comment #32, I introduced a simple program I called "console".  It is
actually unnecessary.  Instead, do the following:

/sbin/cryptsetup luksOpen /dev/root root < /dev/console > /dev/console
echo Mounting root filesystem
mount -o defaults --ro -t ext3 /dev/mapper/root /sysroot
Comment 38 Michael Hampton 2006-07-07 00:27:00 EDT
Hm, I'd like to see this patch updated for mkinitrd-5.0. I'll do it myself if I
can, but don't expect it to be perfect. :)
Comment 39 W. Michael Petullo 2006-08-10 07:22:06 EDT
Created attachment 133932 [details]
Patch to add support for encrypted root filesystems to mkinitrd

I've found some time to start working on this again.

This patch is against mkinitrd-5.1.2-1.  The user is now prompted for a
passphrase when the system boots.  I performed the following steps to create an
encrypted root partition after applying this patch:

1.  Install Fedora, leaving a spare partition, call it /dev/hda6.

2.  cryptsetup luksFormat /dev/hda6

3.  cryptsetup luksOpen /dev/hda6 root

4.  mkfs.ext3 /dev/mapper/root

5.  mount /dev/mapper/root /mnt

6.  cp -ax / /mnt

7.  Edit /mnt/etc/fstab and change the root filesystem device to
/dev/mapper/root

8.  mkinitrd --fstab=/mnt/etc/fstab /boot/initrd-enc <kernelversion>

9.  Edit yaboot.conf (or GRUB's config), set root to /dev/hda6 and set initrd
to /boot/initrd-enc.

The patch contains a few comments that contain the text "FIXME."  I am hoping
to get feedback from the mkinitrd maintainer on two of those comments.
Comment 40 Michael Hampton 2006-08-10 20:49:42 EDT
I can't put the encrypted filesystem inside an LVM logical volume? That's going
to ruin my day...

Anyway, your new patch 133932 applies cleanly to mkinitrd-5.0.32 (%patch -p2 in
the spec file) so I'm off to try it out and see what happens on a fresh FC5 box.
Comment 41 Michael Hampton 2006-08-10 23:18:58 EDT
It works! My fresh FC5 install asks for the passphrase, decrypts the partition
(which I DID put into an LVM LV and that works too) and boots right up. I
couldn't login though, probably because I had to do the above steps from an
SELinux-disabled live CD (cryptsetup wouldn't work from the FC5 rescue mode). So
I touched /.autorelabel and rebooted, and after that everything was good.
Comment 42 Michael Hampton 2006-08-11 02:26:09 EDT
Hm, perhaps I spoke too soon. After updating to kernel-2.6.17-2157_FC5 and
making a new initrd with the patched mkinitrd, I get the following cryptic error
on boot:

  Reading all physical volumes.  This may take a while...
  Found volume group "VolGroup00" using metadata type lvm2
  3 logical volume(s) in volume group "VolGroup00" now active
Command failed: Can't get device information.

On inspecting grub.conf I found that the root device had been reset to
/dev/mapper/root, rather than being preserved as /dev/VolGroup00/LogVol00. Once
I changed it back manually, everything works, though this does suggest some
further patching is needed. :)
Comment 43 Michael Hampton 2006-08-11 02:49:28 EDT
Okay, last comment tonight. I promise. On upgrading the kernel (again to 2174)
from yum it appears a script is failing:

  Installing: kernel                       ######################### [2/3]
Usage: cryptsetup [-?] [-?|--help] [--usage] [-v|--verbose]
        [-c|--cipher STRING] [-h|--hash STRING] [-y|--verify-passphrase]
        [-d|--key-file STRING] [-s|--key-size BITS] [-b|--size SECTORS]
        [-o|--offset SECTORS] [-p|--skip SECTORS] [-r|--readonly]
        [-i|--iter-time msecs] [-q|--batch-mode] [--version]
        [-t|--timeout secs] [OPTION...] <action> <action-specific>]
cryptsetup: status: requires <name> as arguments

When I then run mkinitrd -f /boot/initrd-2.6.17-1.2174_FC5.img 2.6.17-1.2174_FC5
then the initrd is generated correctly and all is well.
Comment 44 W. Michael Petullo 2006-08-13 17:05:18 EDT
Created attachment 134108 [details]
Patch to add support for encrypted root filesystems to mkinitrd

This should address the issue identified in comment #43.
Comment 45 Michael Hampton 2006-08-16 04:19:23 EDT
After the patch in #44, I no longer get the error message on upgrading the
kernel, but the generated initrd now gives a bizarre error saying that it can't
resume from /dev/mapper/swap (but I don't use suspend to disk!). I still have to
run mkinitrd manually after upgrading the kernel.
Comment 46 W. Michael Petullo 2006-08-20 17:23:54 EDT
Created attachment 134534 [details]
Patch to add support for encrypted root filesystems to mkinitrd

The new-kernel-pkg script no longer uses the findall or vecho functions, which
are not available.
Comment 47 W. Michael Petullo 2006-08-20 17:29:40 EDT
Created attachment 134535 [details]
Patch to add support for encrypted root filesystems to mkinitrd

The new-kernel-pkg script no longer uses the findall or vecho functions, which
are not available.
Comment 48 W. Michael Petullo 2006-08-20 17:30:49 EDT
Created attachment 134536 [details]
Patch to add support for encrypted root filesystems to mkinitrd

The new-kernel-pkg script no longer uses the findall or vecho functions, which
are not available.
Comment 49 W. Michael Petullo 2006-08-20 17:32:06 EDT
Created attachment 134537 [details]
Patch to add support for encrypted root filesystems to mkinitrd

The new-kernel-pkg script no longer uses the findall or vecho functions, which
are not available.
Comment 50 Michael Hampton 2006-08-20 20:05:47 EDT
Created attachment 134538 [details]
Patch to provide encrypted root filesystem support in mkinitrd, updated for mkinitrd-5.1.9

I regret to say the new patch didn't apply cleanly either to mkinitrd-5.0.32
(FC5) or to mkinitrd-5.1.9, (development) so I rebuilt a patch that does apply
cleanly, at least to 5.1.9. (A minor change should let it apply cleanly to
5.0.32 as well.)

I also regret to say that it's still writing a bad grub.conf entry, setting
root=/dev/mapper/root instead of the actual filesystem (in my case,
root=/dev/VolGroup00/LogVol00). I changed this manually, but I continue to get
the oddball error:

Red Hat nash version 5.1.9 starting
Unable to access resume device (/dev/mapper/swap)
Command failed: Can't get device information.

I'm going to try backporting this to mkinitrd-5.0.32 shortly.
Comment 51 W. Michael Petullo 2006-08-27 14:10:17 EDT
Created attachment 135006 [details]
Patch to add support for encrypted root filesystems to mkinitrd

I think devices such as /dev/VolGroup00/LogVol00 don't work because of my
reliance on the get_traditional_devnod shell function in new-kernel-pkg.  This
function, given /dev/root, looks at the devices major and minor numbers and
uses sysfs to determine the traditional, e.x., /dev/hda1, device.

I suspect this technique fails for something like dev/VolGroup00/LogVol00. 
This patch adds a test to make this failure more explicit.

I'm not very familiar with volume groups, so I could use some help determining
how to handle this case.
Comment 52 W. Michael Petullo 2006-09-02 17:04:10 EDT
Michael Hampton:

Some questions about your LVM setup:

1.  What device is listed for "/" in /etc/fstab?

2.  What does "cryptsetup status $rootdevice" say, where $rootdevice is the
device from question one?

3.  If the answer to question two is /dev/VolGroup00/LogVol00, then stop.  Else,
can you provide a command that takes the answer to question two as input and
prints /dev/VolGroup00/LogVol00?  Right now my code looks up the "real" name for
/dev/root by using sysfs.  But I don't think this works for LVM.
Comment 53 Michael Hampton 2006-09-02 18:01:44 EDT
1.
/dev/mapper/root        /               ext3    defaults        1 1

2. 

# cryptsetup status root

/dev/mapper/root is active:

  cipher:  aes-cbc-plain

  keysize: 128 bits

  device:  /dev/root

  offset:  1032 sectors

  size:    42865656 sectors

  mode:    read/write

# cryptsetup --version

cryptsetup-luks 1.0.3-rc2


3.
Hm, I can't think of any way right now to get from /dev/mapper/root back to
/dev/VolGroup00/LogVol00.
Comment 54 W. Michael Petullo 2006-09-03 13:25:01 EDT
Created attachment 135462 [details]
Patch to add support for encrypted root filesystems to mkinitrd

This patch adds support for encrypted logical volumes.	In order to use an
encrypted logical volume, perform the following steps:

1.  Install Fedora, leaving a spare logical volume, call it
/dev/VolGroup01/LogVol00.

2.  cryptsetup luksFormat /dev/VolGroup01/LogVol00

3.  cryptsetup luksOpen /dev/VolGroup01/LogVol00 root

4.  mkfs.ext3 /dev/mapper/root

5.  mount /dev/mapper/root /mnt/

6.  cp -ax / /mnt

7.  Edit /mnt/etc/fstab and change the root filesystem device to
/dev/mapper/root

8.  mkinitrd --fstab=/mnt/etc/fstab /boot/initrd-enc <kernelversion>

9.  Edit yaboot.conf (or GRUB's config), set root to /dev/VolGroup01/LogVol00
and set initrd to /boot/initrd-enc.
Comment 55 W. Michael Petullo 2006-09-08 21:39:30 EDT
Created attachment 135894 [details]
Patch to add support for encrypted root filesystems to mkinitrd

Please note that new-kernel-pkg will fail when RPM attempts to upgrade a kernel
while SELinux is enforcing its policy.	Please ** turn off SELinix ** before
trying to test this patch's upgrade functionality.  I will look into this
SELinux issue after more testing.  Please help test:

1.  Creating a new encrypted root partition (see instructions in previous
comment.)

2.  Upgrading a kernel using RPM (new-kernel-pkg should properly create an
initrd and update /etc/yaboot.conf.)

Both of these operations should work with physical or logical volumes.
Comment 56 Michael Hampton 2006-09-10 03:57:45 EDT
  Installing: kernel                       ######################### [1/1]

Found backing device /dev/VolGroup00/LogVol00 (dm-1) for /dev/mapper/root


The latest patch (135894) creates a perfectly workable initrd and I can finally
boot kernel 2.6.17-2174 from it! It does print out a whole list of devices just
before asking for the passphrase though.

It also works with the latest mkinitrd (5.1.15) with %patch -p1 in the spec file.

I regret to say that when I installed the kernel I forgot to turn off SELinux,
and so grubby failed with a Floating point exception.
Comment 57 W. Michael Petullo 2006-09-11 20:34:52 EDT
Created attachment 136049 [details]
Patch to add support for encrypted root filesystems to mkinitrd

This patch has the following improvements over the previous one:

1.  Consolidated code that creates dm control device to avoid code duplication.


2.  Removed debug statements mentioned in the previous comment.

3.  Added ability to store a key on a removable device.  This is the technique
I used to use before adding support for keyboard input.  The key and initrd are
placed on a removable device (e.g., thumb drive.)  This allows the key to be a
random number with maximum entropy for the keyspace.  The removable device
needs to be protected.	This technique is used if /etc/root-key exists on an
encrypted root device.	I need to test this.
Comment 58 W. Michael Petullo 2006-09-15 19:28:22 EDT
I just tested the "key on removable device" feature.  It seems to work.  This
allows one to have a key with maximum entropy on a removable device.  The
removable device must be physically protected like a house key.  Again, the
existance of /etc/root-key causes mkinitrd to use this technique.  See [1] for
more information.  Here are the steps for installing boot files and a key on a
USB flash drive:

First, prepare the encrypted root filesystem.

1.  Create a key: dd if=/dev/urandom of=/etc/root-key bs=1c count=32
2.  LUKS Format: cat /etc/root-key | cryptsetup luksFormat /dev/hdaX
3.  Setup crypto: cryptsetup -d /etc/root-key luksOpen /dev/hdaX root
4.  Create FS: mkfs.ext3 /dev/mapper/root
5.  Mount: /dev/mapper/root /mnt
6.  Populate: cp -ax / /mnt

NOTE: temporarily storing /etc/root-key on an unencrypted filesystem is not safe
UNLESS the partition hosting it is randomized after creating the encrypted
filesystem.

Now, install the boot system onto the USB flask disk.  This example is for a
PowerPC-based computer that uses OpenFirmware.

1.  Determine OpenFirmware path to USB flash disk (see [1].)

2.  Set up partition table: parted /dev/sda
(parted) mklabel mac
(parted) mkpart primary hfs 0.031 62.500
(parted) set 2 boot on
(parted) name 2 Apple_Boot
(parted) quit

3.  Create FS: hformat /dev/sdaX

4.  Configure /mnt/etc/yaboot.conf, based on the following example:

boot=/dev/sdaX
ofboot=/pci@f2000000/usb@1b,1/disk@1:2
partition=X
install=/usr/lib/yaboot/yaboot
magicboot=/usr/lib/yaboot/ofboot
default=linux
image=/vmlinux
        label=linux
        root=/dev/hdaX
        initrd=/initrd.gz
        read-only

5.  Install bootstrap files and kernel to /dev/sdaX:

ybin --config /mnt/encroot/etc/yaboot.conf -v
mount /dev/sda2 /media
cp /boot/<Linux kernel> /media

6.  Edit /mnt/etc/fstab, setting the root filesystem to /dev/mapper/root.

7.  mkinitrd --fstab=/mnt/etc/fstab /media/initrd-enc <Linux kernel version>

8.  umount /media

[1] http://www.linuxjournal.com/article/7743
Comment 59 Michael Hampton 2006-10-21 02:07:41 EDT
The latest patch fails on mkinitrd-5.1.19-1 on Fedora Core 6. It says I'm not
using LUKS, when I am. This is the same system I've been using all along!

root@roam ~ # mkinitrd -v -f /boot/initrd-2.6.18-1.2798.fc6.img 2.6.18-1.2798.fc6

Creating initramfs

Looking for deps of module uhci-hcd

Looking for deps of module ohci-hcd

Looking for deps of module ehci-hcd

Looking for deps of module ext3: jbd 

Looking for deps of module jbd

Found backing device  for /dev/mapper/root

Encryption on /dev/mapper/root does not use LUKS, aborting.
Comment 60 W. Michael Petullo 2006-10-22 09:42:09 EDT
Do the two recent dependencies added to this bug (marked as security issues, so
I can't see their contents) imply that Red Hat may be interested in implementing
this feature?
Comment 61 Michael Hampton 2006-10-22 21:03:56 EDT
I suspect the addition of FC7Target implies that Red Hat may be interested in
implementing this feature. :)
Comment 62 W. Michael Petullo 2006-11-19 13:52:46 EST
Created attachment 141591 [details]
Patch to add support for encrypted root filesystems to mkinitrd

This patch applies cleanly to mkinitrd-5.1.19.

It works fine with a "traditional" block device (e.x., /dev/hdaX).  It also
supports booting from removable media with a strong encryption key (see comment
#58).

But...

Booting from volume groups is again broken.  This is because a device node like
/dev/dm-1 is not longer created when a volume group is set up.	This device
node is used, along with sysfs, to determine the backing device for an
encrypted volume group.

Could someone tell me why /dev/dm-X is no longer created for device mapper
devices?  What component had this responsibility before?

Everything works fine if /dev/dm-X is created by hand using mknod before
mkinitrd is run.
Comment 63 Michael Hampton 2006-11-19 14:28:28 EST
It seems to me that if you have a dm-?? device you could just skip /dev entirely
and go directly to sysfs and walk backward through there; it appears that
everything you need can be pulled out of there. You'd have to rewrite or replace
the get_logvol_devnod function though. (This might have pitfalls I'm not aware
of, though.) Here's an example:

root@underground ~ # dmsetup list --tree
[...snip...]
vol1 (253:4)
 `-VolGroup01-LogVol00 (253:3)
    `- (8:17)
root@underground ~ # cat /sys/block/dm-4/dev
253:4
root@underground ~ # ls /sys/block/dm-4/slaves
dm-3
root@underground ~ # cat /sys/block/dm-3/dev
253:3
root@underground ~ # ls /sys/block/dm-3/slaves
sdb1
root@underground ~ # cat /sys/block/sdb/sdb1/dev
8:17
Comment 64 W. Michael Petullo 2006-11-20 18:22:14 EST
This lack of /dev/dm-? nodes affects other components.  See bug #216538.
Comment 65 Michael Hampton 2006-11-20 19:27:01 EST
Oh, so that explains why my encrypted USB stick doesn't mount! I reported that
as bug 213601.
Comment 66 Michael Hampton 2006-11-20 19:32:11 EST
Er, that should be bug 213801. Sorry.
Comment 67 W. Michael Petullo 2006-11-27 17:57:34 EST
This should fix the problem mentioned in comment #62:

Comment out "KERNEL=="dm-[0-9]*", OPTIONS+="ignore_device"" in
/etc/udev/rules.d/50-udev.rules.

I am not sure why udev has this rule.
Comment 68 Stefan Becker 2006-12-16 12:24:54 EST
Created attachment 143860 [details]
Simple program to query password from user and store it to a file

Good, somebody else is working on this too. I would really like to see an
official solution in FC. This should also include support in installer/rescue
mode, ie. you could directly install on an encrypted partition without having
to use a temporary partition.

Here is a little bit from my very simplistic approach used with FC6: a simple
program which reads a password from the console and stores it to
/luks_password. This file can then be used to open all other partitions in
initrd, i.e. the user can use a single password (PointSec-like):

  luks_password
  echo Unlocking swap device.
  cryptsetup -d /luks_password luksOpen /dev/VolGroup00/LogVol01 encrypted_swap

  resume /dev/mapper/encrypted_swap
  echo Unlocking root device.
  cryptsetup -d /luks_password luksOpen /dev/VolGroup00/LogVol00 encrypted_root

  rootdev=mapper/encrypted_root
  echo Unlocking home device.
  cryptsetup -d /luks_password luksOpen /dev/VolGroup00/LogVol02 encrypted_home


The file is in the initrd root, i.e. it will disappear when the root is
switched. This is probably not really secure and the initrd memory should be
wiped after root switch to destroy any traces of the password.

BTW: I've successfully tested hibernate & resume using an encrypted swap
partition. So it would be nice if the final solution would include a password
for a swap partition too, not only the usually suggested solution with a random
password & mkswap at every boot.
Comment 69 wesley.wright 2006-12-25 11:04:12 EST
Created attachment 144351 [details]
Patch to add support for encrypted root filesystems to mkinitrd

I had the same issues as in comment #62, and while Michael in comment #67
mentions a feasible workaround, the block device necessary to boot is available
even without the dm device file.  My concern was that a future install of udev
would overwrite commenting the rule change, so I've updated the patch to work
in the scenario where the user has a stock FC6 install (Logical Volume root
partition and the udev rules intact).  The update basically does:

1) Check to see if the /dev/dm-# device exists and is a valid block device.  If
yes then proceed with the normal method.

2) If no then check to see if the crypto device is a valid block device and if
so try to use it to derive the necessary boot info instead.  

I believe this should be backwards compatible with other setups, but would
appreciate someone validating this approach.  In the mean time this worked for
me in a FC6 kernel upgrade test and using mkinitrd manually.
Comment 70 Bruno Wolff III 2007-01-06 01:08:29 EST
Is there a task list for this, that I could look at for things to help out with?
I would like to see this get into FC7 (or whatever it will be called).
Comment 71 Bruno Wolff III 2007-01-06 01:12:01 EST
Is there a task list for this, that I could look at for things to help out with?
I would like to see this get into FC7 (or whatever it will be called).
Comment 72 Andy Walls 2007-02-10 09:50:18 EST
Created attachment 147835 [details]
Patch to add encrypted root fs support to mkinitrd w/modular CBC

This is a modification of Wesley Wright's patch from Comment #69.

Following Michael Hamptons procedure at 
http://linux.ioerror.us/2006/09/encrypting-your-root-partition-on-fedora-core-5/

and using these bugzilla comments as a guide, I discovered two things:

1.  The latest kernel for FC6 (2.6.19-1.2895.fc6) has the CBC support built as
modules.  I had to add "findmodule -blkcipher" and "findmodule -cbc" to the
mkinitrd patch in comment #67 to get a "aes-cbc-essiv:sha256" LUKS device to
work from the initrd environment.  The attached patch file has the simple
change.

2. When working from a chroot'ed environment from a Gentoo minimal Live CD, per
Michael Hampton's blueprint, I had to force mkinitrd to include lvm support
(added	"vg_list=VolGroup00" at line 1168 in mkinitrd temporarily), because the
lvm tools didn't think any LV's existed in the chroot'ed environment and
mkinitrd wouldn't include lvm support. 

Here's how I ran mkinitrd in the chroot environment to force lvm support:

  chroot /mnt/disk1
  mount -t proc proc /proc
  mount -t sysfs sysfs /sys
  dmsetup mknodes
  vi /etc/fstab    (change /dev/VolGroup00/LogVol00 to /dev/mapper/root)
  vi /sbin/mkinitrd (add vg_list=VolGroup00 at line 1168)
  mkinitrd -v -f /boot/initrd-2.6.19-1.2895.fc6.img  2.6.19-1.2895.fc6
  vi /sbin/mkinitrd (comment out vg_list=VolGroup00 at line 1168)
  umount /sys
  umount /proc
  exit

The patch does not address lvm and running mkinitrd in a chroot environment.
Comment 73 Andy Walls 2007-02-10 10:01:39 EST
Oops.  There's a typo above.  Both comment refernces should be to commnet #69.
Comment 74 Andy Walls 2007-02-18 12:11:50 EST
Created attachment 148297 [details]
Patch to add encrypted swap and root fs support to mkinitrd w/modular CBC

This is a modification of my patch from Comment #72.

1. Since 

a. an encrypted root does not offer complete protection of data at rest
without an encrypted swap, and since

b. laptop users are most likely to need both protection of data at rest 
and suspend to disk functionality,

this patch to mkinitrd provides support for a LUKS formated encrypted swap
volume with the ability to resume from a suspend that wrote the machine
state to the encrypted swap volume.

It does require one to enter two passwords at bootup when not resuming.
(Comment #68 discussed a possible one password solution that is not in this
patch for those willing to make the required security trade-offs.)

The changes are simply a modification of what was done for encrypted root,
except the swap partition's name is not constarined to "/dev/mapper/swap".
It could be "/dev/mapper/foobar" if you like, but 
/dev/mapper/VolGroup00-LogVol01, the name of the backing volume, would
obviously be a bad choice...



2. When working from a chroot'ed environment from a Gentoo minimal Live CD, per

Michael Hampton's blueprint, but creating encrypted swap as well as an
encrypted
root, I still had to force mkinitrd to include lvm support 
(added "vg_list=VolGroup00" at line 1210 in mkinitrd temporarily), because the
lvm tools didn't think any LV's existed in the chroot'ed environment and 
mkinitrd wouldn't include lvm support. 

Here's how I ran mkinitrd in the chroot environment to force lvm support:

  chroot /mnt/disk1
  mount -t proc proc /proc
  mount -t sysfs sysfs /sys
  dmsetup mknodes
  ln -s /dev/mapper/VolGroup00-LogVol01 /dev/VolGroup00/LogVol01
  vi /etc/fstab    (change /dev/VolGroup00/LogVol00 to /dev/mapper/root
		       and /dev/VolGroup00/LogVol01 to /dev/mapper/swap)
  vi /sbin/mkinitrd (add vg_list=VolGroup00 at line 1210)
  mkinitrd -v -f /boot/initrd-2.6.19-1.2895.fc6.img  2.6.19-1.2895.fc6
  vi /sbin/mkinitrd (comment out vg_list=VolGroup00 at line 1210)
  umount /sys
  umount /proc
  exit

The patch does not address lvm and running mkinitrd in a chroot environment.
Comment 75 Dick Thomas 2007-03-12 18:34:52 EDT
my work around for the more then 1 volume / partition to save having to re-enter
passwords
is a small partition (i called vault)
that is encrypted and stores keyfiles for unlocking root/swap/home etc etc

I have not yet managed to inplement this under fedora 
as I only started using Fedora a few weeks ago after using Gentoo in the past

I doubt this could be easy to add to the automagical mkinitrd method. but for
the manual method may save time
Comment 76 Michael Hampton 2007-04-24 17:52:44 EDT
I've successfully applied this patch to RHEL 5, and in the latest Fedora Core 6
as well. Maybe it's time to roll it in?
Comment 77 Jim Perrin 2007-05-02 13:30:35 EDT
Michael, 
would you be able to provide some steps for how you applied this to RHEL5? I
would like to roll this out to some of the laptops I have within the DoD space,
at least for protecting /home. 
Comment 78 Michael Hampton 2007-05-02 14:09:51 EDT
Eh? You don't need this patch for encrypting non-root partitions. Just set them
up normally.

But the basic process I use is this:

* Download the mkinitrd SRPM
* Edit the spec file, adding in the latest patch
* Rebuild the RPMs from the spec file
* Install the new RPMs

To actually install a system, since anaconda doesn't yet support encrypted
partitions, I get a scratch hard drive gathering dust somewhere, install fresh
over whatever was on it, including the patched RPMs from above, and then boot
from a rescue CD (usually Gentoo) and transfer the freshly installed system onto
the encrypted drive. Then I chroot into the encrypted disk and run mkinitrd
manually (the first time). When later kernel updates come through, mkinitrd will
do the right thing.

See also bug 211247. Red Hat is going to need some encouragement from its
customers for this feature.
Comment 79 Tim Niemueller 2007-05-17 14:42:28 EDT
Created attachment 154948 [details]
Patch to add encrypted swap and root fs support to mkinitrd w/modular CBC on F7

This patch is a slightly modified version of the patch from Comment #74. It
adds encryption support for encrypted root and swap devices to the mkinitrd
that comes with Fedora 7.

I have tested this with my machine and it works just fine. I wrote a small
HOWTO based on Michael's describing how this can be done just with the Fedora
media and without the Gentoo mini CD. The Gentoo media don't work on x86_64 as
there is not matching media for this system. You can find it at
http://www.niemueller.de/wiki/?Fedora7WithCryptoRootNSwap. Suspend2disk to the
encrypted swap partition works like a charm.

I hope this will finally make it into F8 and with support in anaconda.
Comment 80 Tim Niemueller 2007-05-28 10:32:20 EDT
Created attachment 155547 [details]
Patch to add encrypted swap and root fs support to mkinitrd w/modular CBC on F7

Fixes inst call for swap device. Eliminates a small error (which didn't prevent
the former patch from working, though).

Is there a chance that we see this included at some point (in the near future)?
Has someone tested this on a machine without root encryption to see if it
interferes somehow. If it does not it should be save to put this patch into the
package, even without support in the installer but accompanied with a useful
HOWTO for now. I just had the problem that my mkinitrd was updated from the
repo and then installing new kernels would not work anymore...
Comment 81 Karsten Hopp 2007-06-01 12:22:25 EDT
Created attachment 155901 [details]
Patch to add encrypted swap and root fs support to mkinitrd w/modular CBC on F7

This is a patch similar to the 155547 (comment #80), but can handle all lvm
volumes, not only those created by anaconda which are named VolGroup??
It also adds a check if sbackingdev really is a Linux Swap partition before it
bails out
Comment 82 Michael Hampton 2007-06-09 22:27:24 EDT
Patch 155901 is still misidentifying the swap partition as the one on which it
should operate, at least on my system. Once I commented the swap out of
/etc/fstab, then it picked up the correct root partition.
Comment 83 Kevin R. Page 2007-06-10 18:13:12 EDT
I don't think the configuration below is supported by the current patch - I've
attempted to set it up and it doesn't work; if it should do I can try again,
obviously.

I'm looking to encrypt the physical volume upon which the volume group is
created, which in turn contains the logical volumes used for /, swap, and
everything else on the laptop. Only /boot is unencrypted. On boot, I would enter
one password for the luks partition, after which the lvm volumes are found and
the system boots.

e.g. a "stack" of devices, going down from a filesystem, is:
/ (ext3)
/dev/mapper/vg0-lv_root (lv)
/dev/mapper/vg0 (vg)
/dev/mapper/pv0_crypt (luks encrypted pv)
/dev/sdb2

This is the sort of setup I need:
http://gentoo-wiki.com/SECURITY_LVM_and_EVMS_over_cryptsetup-LUKS
It seems like a sensible way to set things up for a laptop - more sensible than
entering a LUKS passphrase for each partition, swap etc.
Comment 84 Karsten Hopp 2007-07-12 07:57:56 EDT
re: comment #83
If I understand correctly, you'd like to have to type just one LUKS password
and set up the other encrypted filesystems automatically via passwords in files ?
That is supposed to work. Just put the key files on the root filesystem and
reference them in /etc/crypttab (the third parameter). Just make sure to leave
the third parameter of the root FS as 'none'
Comment 85 Kevin R. Page 2007-07-12 08:42:22 EDT
Not really: ideally I'd like to encrypt a single device, upon which all the
filesystems I use (via LVM) are built.

e.g.
1) partition laptop with /dev/sda1 (small, unenrypted, for /boot) and /dev/sda2
2) use LUKS to encryt /dev/sda2, which appears when decrypted as
/dev/mapper/crypt_device
3) use /dev/mapper/crypt_device as the physical volume from which my primary LVM
volume group (e.g. /dev/mapper/vg0) is built
4) create logical volumes for filesystem partitions from vg0, as per usual

When you start the machine, /boot is unencrypted, initrd bootstraps, asks you
for one LUKS passphrase which decrypts /dev/sda2, and off you go. LVM handles
everything from /dev/mapper/crypt_device up.

Caveat: I actually tried this on a _second_ internal hard drive in a laptop,
i.e. /dev/sdb rather than /dev/sda. Clearly this shouldn't make a difference,
but I'm unable to mess with /dev/sda to test.


The motivation / use-case: it's all about the balance of intrusiveness vs.
performance vs. security. On my workstation I may want to encrypt just /tmp,
swap, /home/XXX (and use pam_mount), not least because I want the machine to be
able to reboot unattended. On my laptop, I'm much more paranoid about loss of
the physical machine, so I put a higher value on encrypting the _entire_ hard
drive; but at the same time I'm always at the console when it boots, so entering
a passphrase early in the boot process isn't a problem; and there aren't
multiple users to worry about passphrase management.

It's this latter scenario I'm interested in; I want to encrypt the entire drive,
so I don't want the hassle of maintaining LUKS passphrases for separate
partition/filesystems (and associated maintenance overheads when it comes to
resizing partitions, etc.). I suspect I could solve this with multiple
partitions, but as far as I can see the only thing preventing an encrypted LVM
PV is the initrd (see the gentoo link).

When building a laptop from scratch, this seems like the obvious way to do it.
(I can see why you'd want to deal with partitions if "upgrading" a machine to LUKS).

(For the truly paranoid, I encrypting the PV rather than each LV will also hide
"secondary" data, such as volume information - metadata, partition sizes, etc.) 
Comment 86 Kevin R. Page 2007-07-25 12:40:42 EDT
Created attachment 159957 [details]
Patch to add encrypted swap and root fs support to mkinitrd w/modular CBC on F7

Patch fixes a bug in mkinitrd.get_traditional_devnod() - there needs to be an
additional for loop to step through all the possible logical volumes in each of
$vgdevices (there might be a shorter way of doing this with some bash
expansion/braces foo, but I'm no bash expert!).

Also now patched against mkinitrd-6.0.9-7.1

(This doesn't address the requirements I mentioned in my previous comments)
Comment 87 Kevin R. Page 2007-07-25 12:50:03 EDT
Comment on attachment 159957 [details]
Patch to add encrypted swap and root fs support to mkinitrd w/modular CBC on F7

Scratch that - definitely not a bash expert! There's a problem there, but that
patch still isn't right.
Comment 88 Kevin R. Page 2007-07-25 13:10:29 EDT
Comment on attachment 159957 [details]
Patch to add encrypted swap and root fs support to mkinitrd w/modular CBC on F7

Apologies for the flip flop - I think it's ok after all. I'm seeing a similar
symptom but for different reasons, it would seem.
Comment 89 Karsten Hopp 2007-08-07 08:50:08 EDT
Peter, can we get this patch into F8 , please ?  This would help us to get
everyone at the same level and go on from there...
Comment 90 Tim Niemueller 2007-08-15 09:08:10 EDT
It would be great if this could be added to mkinitrd before F8 freeze. After
three years of usage it should be possible to have it at least in there for
people like us keen to test and use this. Since I use crypto root support I feel
a lot better traveling with my laptop. Having a crypted backup at home/office
makes a loss of a laptop a matter of just the material...

Even if there is no support in Anaconda to use the crypto support, there could
be a "do it and risk it" entry in the wiki for the brave.

Having this in F8 would give us a base for further development.
Comment 91 Kevin R. Page 2007-08-19 20:07:09 EDT
Created attachment 161831 [details]
Patch to add encrypted swap and root fs support, also with encrypted PV

Firstly, my bugfix in comment #88 is correct and neccesary. The bug was
actually in get_logvol_devnod(), not get_traditional_devnod(), which probably
explains my confusion last month. Ahem.

Secondly, the attached patch adds functionality for an encrypted Physical
Volume, as descibed in my scenario of comment #85.

e.g. you boot your laptop and enter a passphrase to unlock a large partition.
This partition forms the Physical Volume for an LVM Volume Group, which in turn
contains Logical Volumes for root, swap, etc.

The patch includes the most up to date previous patch, and my earlier bugfix.
Comment 92 Kevin R. Page 2007-08-19 20:12:18 EDT
Created attachment 161832 [details]
Additions for encrypted Physical Volumes

For easier comparison and review of my changes, I'm attaching a diff between
mkinitrd patched with the previous version of the patch and mkinitrd with the
complete newer encrypted PV patch.
Comment 93 Kevin R. Page 2007-08-20 13:49:56 EDT
Created attachment 161909 [details]
Patch to add encrypted swap and root fs support, also with encrypted PV

An update to my previous patch. Bugfixes:
1) fixes careless use of echo rather than vecho.
2) when booting from LiveCD, lvdisplay returns /dev/dm-X over /dev/mapper/*, so
added get_mapper_dev() and associated checks.

See comment #91 for more details.
Comment 94 Kevin R. Page 2007-08-20 13:56:30 EDT
Created attachment 161910 [details]
Diff between previous patch and current patch with encrypted PV

As per comment #92, a diff between the old version of the patch and my latest
patch with encrypted PV (I'll just attach full patches in the future, so this
gives a good overview of the extra code needed to support encrypted PVs).
Comment 95 Kevin R. Page 2007-08-20 14:14:00 EDT
Created attachment 161912 [details]
HOWTO: Creating an encrypted Physical Volume using Fedora and patched mkinitrd

By following the attached HOWTO with a mkinitrd package patched according to
comment #93 I successfully installed - and am running - a copy of Fedora 7 on
an encrypted Physical Volume. The Volume Group built from the encrypted PV then
contains Logical Volumes for my root directory and swap.

A second hard drive or partition is required to use this method.

Since Fedora, by default, installs the root directory and swap to a single
Volume Group, it should also be possible to adapt this method to (relatively!)
easily convert a non-encrypted install to an encrypted one (i.e. to pvmove the
existing install to a temporary PV, then encrypt the original PV before moving
the installation back).
Comment 96 Kevin R. Page 2007-08-20 15:00:04 EDT
Questions:

1) In step 10 of the attached HOWTO, above, I populate the /dev directory of the
chroot environment by copying the /dev entries from the running /dev. Is there a
better way to do this? (I tried using start_udev, but it didn't seem to pick up
everything needed from LVM and the crypt devices).

2) I think there's a bug in the patched version of grubby. isRootEnc() segfaults
for me with the encrypted PV setup described above, HOWEVER it also segfaults in
the same way when built and tested on a machine without any encrypted
partitions. On this PC root is just an LVM Logical Volume (albeit with the PV on
a RAID1 partition, e.g. /dev/md0).

I suspect it may do this on all "standard" Fedora installs (i.e. root on
VolGroup00/LogVol00), though LVM-on-RAID is a common enough setup for this to be
a problem if this is going into F8!

(Obviously this only happens on a kernel install; manual runs of mkinitrd are fine)

It segfaults on the:
  strcomp(target_type, CRYPT_TARGET)
just after:
  next = dm_get_next_target(dmt, next, &start, &length, &target_type, &params);

I haven't looked in details a what's going on here, but I suspect there may be
an assumption that all device mapper devices that got this far are crypt devices
, when they could be LVM, RAID, whatever.

I don't think this is the selinux incompatibility mentioned earlier - at least,
it still occurs with selinux set to permissive (does the selinux problem still
exist in F7?).

I don't really know what's going on inside grubby, so perhaps the author of that
part of the patch could take a look?
Comment 97 Kevin R. Page 2007-08-22 06:54:01 EDT
Bug in comment #96 confirmed:

# rpm -ivvh kernel-2.6.22.1-41.fc7.i686.rpm

...

+ /bin/sed -i -e 's/^DEFAULTKERNEL=kernel-smp$/DEFAULTKERNEL=kernel/'
/etc/sysconfig/kernel
+ /sbin/new-kernel-pkg --package kernel --mkinitrd --depmod --install
2.6.22.1-41.fc7
end_request: I/O error, dev fd0, sector 0
/sbin/new-kernel-pkg: line 121: 30109 Segmentation fault      $grubby
--add-kernel=$bootPrefix/$kernelName-$version $INITRD --copy-default
$makedefault --title
"$title" ${mbkernel:+--add-multiboot="$mbkernel"} ${mbargs:+--mbargs="$mbargs"}
--args="root=$rootdevice $kernargs" --remove-kernel="TITLE=$title"


(I think the "end_request: I/O error, dev fd0, sector 0" is harmless - it
certainly occurs well away from the segfault?)

This is on a clean F7 installation, accepting all the defaults. No RAID, no
crypt, root on VolGroup00/LogVol00 and swap on VolGroup00/LogVol01. Only
non-standard thing is the patched mkinited RPM.

I presume this patch still works on F7 for folks with crypt on Logival Volumes
or straight block devices?

However much I really, really, want to see this patch go into F8, I think this
bug is probably a showstopper - it breaks kernel updates for everyone without
encrypted root.
Comment 98 Kevin R. Page 2007-08-27 17:36:21 EDT
N.B. root-on-encrypted-PV doesn't require a patched grubby; if you delete the
part of the patch which modifies grubby, kernel updates work fine. I'd be
interested to hear how anyone else gets on with an encrypted PV - it would seem
to be a more elegant solution than multiple encrypted LVs, particularly for laptops.

As far as getting this patch into Fedora, this bugzilla pre-dates this wiki page:
http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems
which mentions this bug and other discussion.

I also hadn't seen the various discussions on fedora-devel-list - it's pretty
obvious from these that this patch isn't going to be accepted anytime soon.
Amongst other things, there's resistance to encrypting _any_ block devices which
require password entry on boot due to locale and keyboard mapping problems (i.e.
a lack of i18n).

(Personally I see the merit in these reservations, but having had a laptop
stolen I know from experience that potential theft of data is more of a worry
than the inconvenience and cost of loosing the hardware - so anything is better
than nothing, and the sooner the better. Oh well.)
Comment 99 Till Maas 2007-08-28 08:40:46 EDT
(In reply to comment #98)

> Amongst other things, there's resistance to encrypting _any_ block devices which
> require password entry on boot due to locale and keyboard mapping problems (i.e.
> a lack of i18n).

There is already support for using encrypted filesystems and afaik encrypted lvm
devices that require a password entry on boot with /etc/crypttab. So imho this
should not block adding support for the root filesystem, too. And how is this
problem solved for bootloader (grub) passwords? Maybe this solution can be used
here, too. Or is there no solution, too?
Comment 100 Kevin R. Page 2007-08-28 10:23:32 EDT
Till: absolutely. And while I can see both sides of the argument, my personal
needs would obviously be best served by inclusion of the patch.

I just thought it might be useful to reference these discussions as I suspect
others, like me, didn't realise they'd happened. e.g.
https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02030.html
Comment 101 W. Michael Petullo 2007-10-06 17:21:31 EDT
Please also see http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems.
Comment 102 W. Michael Petullo 2007-11-04 03:13:24 EST
Ray Strode has been contemplating using icons instead of text to prompt for an
encryption key. See http://fedoraproject.org/wiki/Releases/FeatureBetterStartup.
The "Graphical Boot Sequence" effort may allow this and it might get around the
internationalization issue.
Comment 103 W. Michael Petullo 2007-11-10 04:35:12 EST
David Lehman has written an initial attempt at support for creating LUKS-encrypted
partitions at install time. See
https://www.redhat.com/archives/anaconda-devel-list/2007-November/msg00066.html.
Comment 104 W. Michael Petullo 2007-11-12 08:58:25 EST
Created attachment 255221 [details]
Patch to add support for encrypted root filesystems to mkinitrd

I did my best to collect all of the open patches into one. I also ensured that
the new patch will apply against mkinitrd 6.0.19 (Fedora 8). I have not yet
tested this code, other than verifying that it applies cleanly.

The number of open patches has become confusing. In the future, please obsolete
previous patches when a new one is proposed. Also, ensure that you submit clear
comments documenting what is changed by the new patch.

I appologize if I have dropped a feature implemented in the last few patches.
If this is the case, then submit a new patch that returns the dropped feature
and obsolete this patch.
Comment 105 Kevin R. Page 2007-11-19 19:35:47 EST
I've tested the patch from comment #104 on a fresh Fedora 8 install, creating an
encrypted LVM Physical Volume as per comment #95. This works fine, except the
error I reported in comment #96 and comment #97 still stands:

# rpm -ivvh kernel-2.6.23.1-49.fc8.i686.rpm

...

D:   install: %post(kernel-2.6.23.1-49.fc8.i686) asynchronous scriptlet start
D:   install: %post(kernel-2.6.23.1-49.fc8.i686)        execv(/bin/sh) pid 2971
++ uname -i
++ uname -i
+ '[' i386 == x86_64 -o i386 == i386 ']'
+ '[' -f /etc/sysconfig/kernel ']'
+ /bin/sed -i -e 's/^DEFAULTKERNEL=kernel-smp$/DEFAULTKERNEL=kernel/'
/etc/sysconfig/kernel
+ /sbin/new-kernel-pkg --package kernel --mkinitrd --depmod --install
2.6.23.1-49.fc8
grubby recieved SIGSEGV!  Backtrace (7):
/sbin/grubby[0x804b18f]
[0x110420]
/sbin/grubby[0x804c8d2]
/sbin/grubby[0x804c952]
/sbin/grubby[0x804f019]
/lib/libc.so.6(__libc_start_main+0xe0)[0x811390]
/sbin/grubby[0x80493f1]
D:   install: waitpid(2971) rc 2971 status 0 secs 16.353
D: opening  db index       /var/lib/rpm/Triggername create mode=0x42
D: running post-transaction scripts
D: closed   db index       /var/lib/rpm/Filemd5s
D: closed   db index       /var/lib/rpm/Sha1header
D: closed   db index       /var/lib/rpm/Sigmd5
D: closed   db index       /var/lib/rpm/Installtid
D: closed   db index       /var/lib/rpm/Provideversion
D: closed   db index       /var/lib/rpm/Requireversion
D: closed   db index       /var/lib/rpm/Dirnames
D: closed   db index       /var/lib/rpm/Triggername
D: closed   db index       /var/lib/rpm/Conflictname
D: closed   db index       /var/lib/rpm/Providename
D: closed   db index       /var/lib/rpm/Requirename
D: closed   db index       /var/lib/rpm/Group
D: closed   db index       /var/lib/rpm/Basenames
D: closed   db index       /var/lib/rpm/Name
D: closed   db index       /var/lib/rpm/Packages
D: closed   db environment /var/lib/rpm/Packages
D: May free Score board((nil))
#


For an encrypted PV the grubby patch isn't required - if I drop it and rebuild
the mkinitrd package everything works great, including suspend to disk to a LV
based on the encrypted PV.

As I mentioned in earlier comments, I'm not familiar enough with what the grubby
patch is doing - could the original author take a look? I believe this problem
will break kernel updates for ANY user who DOESN'T have encrypted LVs.
Comment 106 W. Michael Petullo 2007-11-20 10:04:48 EST
I just installed a new kernel on a PowerPC system with an encrypted root
(directly on a partition). I did not encounter the crash mentioned in comment
#105. In fact, everything worked fine. I am using the patch from comment #104.
Has anyone else seen the crash Kevin mentioned?

I have not tried LVM yet. I will have to recreate my root filesystem.
Comment 107 Kevin R. Page 2007-11-20 11:40:28 EST
Mike: just to be clear, does your system have either any LVM or RAID? If it
does, is the encrypted root filesystem in any way "on" either of these?

If you don't have any LVM or RAID, but do have an encrypted partition, I
wouldn't expect you to experience the bug - see comment #96. The crasher issue
is that a default Fedora install _does_ use LVM (without encryption); i.e. if
this patch were included as is it would break kernel updates on default Fedora
installs (which will have LVM, but won't have encryption).

It would also be useful to know what your encrypted root filesystem is built upon:
1) directly on a LUKS partition
2) on a LUKS encrypted Logical Volume
3) on Logical Volume within a LUKS encrupted Physical Volume

I'm guessing 1)? Do others with 2) or 3) experience the crash?


P.S. I think that, when I attached patches, I could only obsolete my own
previous patches but not those of others. I guess that as reporter you have more
perms?
Comment 108 W. Michael Petullo 2007-11-25 04:57:27 EST
Okay, I just installed Fedora on a unencrypted LVM volume. I did see the crash
Kevin mentioned when I did a "rpm -ivvh kernel && rpm -evv kernel," although the
crash was on the uninstall not the install. However, when I recompiled mkinitrd
to retest, I could no longer get grubby to segfault. Kevin, have you built and
tested the latest patch on Fedora 8?
Comment 109 Kevin R. Page 2007-11-26 03:30:57 EST
As per comment #105, I have tested (and am using) an encrypted PV on a clean
Fedora 8 install with the latest patch. I have not tested with with a plain
unencrypted install.

Note that when the error occurs with a kernel RPM the RPM installation itself
completes - the kernel files are installed and the RPM database updated - the
only part that fails (with crash) is the post-install scriptlet updating of
grub.conf, which is the part that grubby does.

Mike: does the stack trace show your crash occured in grubby?
It looks like you committed the original patch to grubby (comment #19 ?). Can
you confirm that the grubby patch is designed to deal with root being on a dm
device other than an encrypted device? It looks like your isRootEnc() function
might get tripped up by this - in particular that it gets to, and calls
dm_get_next_target() when root is on an LV that is not an encryped device? I'll
examine in more detail if you think it should work.
Comment 110 W. Michael Petullo 2007-11-26 08:08:52 EST
I think the crash was happening in grubby in the isRootEnc function. However, by
gdb backtrace was not quite right, due to PowerPC compiler optimization, I
think. When I tried to recompile, the crash went away. If it is in fact the
strcmp call in isRootEnc, then I can't see what would cause the crash. The first
parameter is checked to by non-NULL before the strcmp call and the second is a
constant string.

I wrote the isRootEnc function to handle non-encrypted dm devices. I may have
made a mistake, but I did try to handle all cases. I'm not a dm-API expert by
any means.

The frustrating this is, again, that since I recompiled (even the same source
code), I have not been able to reproduce the crash. 
Comment 111 Kevin R. Page 2007-11-26 09:21:45 EST
(In reply to comment #110)
> The frustrating this is, again, that since I recompiled (even the same source
> code), I have not been able to reproduce the crash. 

That is strange - have you removed the kernel RPM and reverted grub.conf? I know
I wasn't consistently getting the crash due to grubby behaving differently due
to different grub.conf contents - it gets munged quite a lot testing this stuff!
In some cases I was generating incomplete grub.conf entries.

(I don't have the source in front of me so I can't see what dm_get_next_target
is doing, but I guess the first parameter must be a non-null but invalid
pointer? It's not initialised to null, I see)
Comment 112 W. Michael Petullo 2007-11-26 12:29:12 EST
Created attachment 269101 [details]
Patch to add support for encrypted root filesystems to mkinitrd

This patch now sets target_type to NULL before dm_get_next_target is called.
This should ensure that it is a valid pointer in addition to the non-NULL check
before passing it to strcmp.

Does this fix the problem?
Comment 113 Kevin R. Page 2007-11-26 18:08:00 EST
Yes, that works for me on my test machine with an encrypted PV. I haven't tried
a clean F8 install with LVM without any encryption, though I suspect it will fix
the problem there too.
Comment 114 Robert Scheck 2007-12-05 07:01:21 EST
Folks, you did a great job. You just forgot to mention, that SELinux has to be
set to permissive on the Live CD. You also forgot to tell, that if you're not
using LVM, the entries in /etc/fstab have to be adjusted to e.g.
/dev/mapper/root and /dev/mapper/swap before re-creating the initrd.

As I definately want to see this feature in Fedora 9, I'm marking this as
blocker bug therefore. We're early enough in the process to get this into the
release.
Comment 115 Tim Niemueller 2007-12-08 10:51:09 EST
The supplied patch for me does not work for me. I have a system which I
installed with Fedora 7 and crypto root with LVM on the PV and two encrypted
partitions inside the VG as LV.

The problem occurs in get_logvol_devnod() around line 209 (I patched my file to
find the bug so I don't have the exact number). The line reads:

[ "$mapperdev" = "$(ls -l $device | awk '{ print $10 }')" ] && logvol=$device

In my case ls -l /dev/VolGroup00/LogVol00 gives:
lrwxrwxrwx 1 root root 31  7. Dez 12:44 /dev/VolGroup00/LogVol00 ->
/dev/mapper/VolGroup00-LogVol00

We see two things here: 1.) the string depends on LANG, so LANG should be set to
C to have reproducible results for all system languages. And 2.) there is -> at
position 10, even with LANG=C. So it is in fact $11. Do you get different output
without "->"? If not it might be an idea to use

ls -l $device | awk -F"-> " '{print $2}'

such that it does not matter how many entries we have, we just make sure that we
get what it points to.
Comment 116 W. Michael Petullo 2007-12-09 05:48:06 EST
# ls -l /dev/VolGroup00/LogVol01
lrwxrwxrwx 1 root root 31 2007-12-08 23:42 /dev/VolGroup00/LogVol01 ->
/dev/mapper/VolGroup00-LogVol01

10th index, LANG=en_US.iso88591.

# LANG=C ls -l /dev/VolGroup00/LogVol01
lrwxrwxrwx 1 root root 31 Dec  8 23:42 /dev/VolGroup00/LogVol01 ->
/dev/mapper/VolGroup00-LogVol01

11th index, LANG=C.
Comment 117 Robert Scheck 2007-12-17 18:34:17 EST
Created attachment 289833 [details]
Patch to add support for encrypted root filesystems to mkinitrd

Tim, can you please test whether the patch now works for you? I included your 
suggestion of the use of awk. I just had to change the quoting a bit.
Comment 118 Tim Niemueller 2007-12-17 19:43:17 EST
The patch works fine for me. I have successfully installed and booted a new kernel.

I have uploaded (S)RPMs to http://fedorapeople.org/~timn/.
Comment 119 Matt McCutchen 2007-12-22 17:22:44 EST
Using the RPMs from comment 118, I successfully resumed from a LUKS-encrypted
swap partition with cipher aes-lrw-benbi, but I needed to add "findmodule -lrw"
to the lists of encryption modules in mkinitrd so that the kernel could handle
the cipher.
Comment 120 Simon Goodall 2008-01-27 12:41:57 EST
Apart from the grubby issue described in an earlier comment, this patch has been
working well for me.
Comment 121 W. Michael Petullo 2008-02-07 02:14:24 EST
Most of this functionality has been implemented in anaconda / mkinitrd as we
lead up to Fedora 9. I am closing this bug. If you find problems with the
implementation in anaconda and mkinitrd, then please open more specific bugs
against those packages.

The document at
http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems contains a
test plan for this feature.

Thanks, everyone.
Comment 122 Kevin R. Page 2008-06-12 10:25:50 EDT
For the information of anyone else who wants to upgrade an encrypted PV to F9, I
have done so successfully through the temporary use of an external USB disk.

(Upgrade of an encrypted PV is scheduled for F10: bug #437604)

This is roughly what I did:

1) Boot into F8
1a) add unencrypted partition on external USB disk as a new PV in main VG
2) Boot into F9 LiveCD
2a) pvmove LVs from encrypted PV to PV on external disk
2b) vgreduce the encrypted PV out of the main VG
3) Upgrade with F9 upgrade DVD
4) Boot into newly install F9
4a) luksOpen the encrypted partition; vgextend it back into the main VG
4b) run mkinitrd
5)
5a) pvmove the LVs back from the external PV back to the encrypted PV
5b) vgreduce the external PV from the main VG
5c) run mkinitrd

The only issue I had was that in step 5) the external disk was created as
/dev/sda and the internal disk as /dev/sdb. When I booted without the external
disk the internal disk returned to /dev/sda BUT the initrd couldn't find the
encrypted PV any more.

Booting into the rescue DVD, chrooting to the installed system, and re-running
mkinited fixed this.
Comment 123 Kevin R. Page 2008-06-12 10:31:07 EDT
Ooops: step 5 was from the F9 LiveCD.

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