Support for encrypted root filesystem (cryptsetup)

BTW, I started working on initramfs-tools support - now I have the parts which will
 - add cryptsetup to ramfs if installed
 - check if /etc/crypttab has encrypted root and echo $dmname $partition to
/etc/cryptoroot on ramfs
 - Ask for cryptoroot passphrase for LUKS formatted partitions (started with
these, it's easier)

So, when I find out why dmsetup does not work with cryptsetup from ramfs I'll
send the patch here as well...
really simple, basic support but anyway, at least it works.

Later that support should be maybe extended to read another script which will
supply the passphrase,
for example from a USB stick or even a smart card (which would require
pcsc-stack and stuff, so probably
is not going to happen)

I'll try to get this done ASAP, pro'lly not going to be in breezy but...

Created an attachment (id=3926)
Implements encrypted root filesystem support for initramfs (i386 only
initially)

This impelemntation of cryptoroot adds support for
- LUKS and raw encrypted plain partitions
- I think that same applies to LVM partitions, but haven't tested it

Ipmlementation:
- Required modules and cryptsetup are added to the image if /sbin/cryptsetup is

  installed
- The raw partition is given as kernel boot parameter encrypted, i.e.
  root=/dev/mapper/cryptoroot encrypted=/dev/hda2
- Should have no effect on systems without cryptsetup of systems with
  cryptsetup but using normal root partition

I will test LVM-root cases (plain LVM root, encrypted LVM root) later

NOTE: there is one known platform bug already: I could test this only with
i386 and thus the encryption module loaded is aes_i586. I have no idea what
are the correct modules for other architectures, and these should be of course
loaded per platform. Look for dm-crypt from hook-functions to fix this.

As I told on -devel mailing lists, I have now written a separate
initramfs-cryptsetup package, which adds the cryptsetup hooks to initramfs and does
not require any patching.

This package is still a little rough, it could for example ask passphrase
_before_ loading usplash, so that the splash screen is not cleared when we
have to ask passphrase when mounting root filesystem. This is just normal
package development, though...

See README in package's docs, basically you have to set kernel boot parameter
'encrypted=/dev/foo' which tells the raw partition to use.

Until we manage to get this package to normal pkg repositories, I'll develop and
make it available from address

    http://ner.dy.fi/deb/

I'm not yet official developer so someone should adopt the package, or whatever
is required to make me a devel... The package must go to universe
as long as cryptsetup is there.

Finally got round to trying Hile's package. Thanks for doing this - it would
have taken me far longer even to work out where to start. However, I've clearly
built my laptop quite differently and as Hile says, his package doesn't handle
LVM yet.

I have a physical partition which is encrypted and then on top of that I have 4
logical volumes. After as much playing as I had time for, I decided that trying
to generalise Hile's scripts was far too difficult so I just chopped them around
to work for me. I also decided that I needed an extra parameter for the
encrypted device name and I decided to put this in a file in the initrd rather
than have another boot parameter. Nothing wrong with using boot parameters of
course, just a personal preference.

So, apart from wanting the sha256 module instead of blowfish, I added the
following lines at the end of the the hooks:
# Make sure lvm will look at mapped files
mkdir -p ${DESTDIR}/etc/lvm
echo 'devices { types = [ "device-mapper", 16 ] }' >${DESTDIR}/etc/lvm/lvm.conf
# Where is the encrypted partition and what device do we map it to
echo '/dev/hda3 cdisk' >${DESTDIR}/etc/cryptoboot

I just did a quick and dirty hack on local-top once I decide it was too
difficult to generalise and I've attached it. Some comments though:
Obviously I had to change from reading boot parameters to reading /etc/cryptoboot.
lvm isn't a pre-requisite - I didn't need to make cryptsetup a pre-requisite for
lvm either.
I couldn't work out the stuff with $vg - if I'm not totally baffled shouldn't
the first line read:
vg=${ENCRYPTED#/dev/mapper/} (extra /)
As I don't need it I just deleted those lines.
I think that the following test must be true so I stripped the test but
obviously kept the block inside it:
if [ -n "${ENCRYPTED}" ]

As for generalising this I think we have 3 possible cases to handle:
1. Encrypted root on a physical partition
2. Root on a logical volume on top of an encrypted partition
3. Encrypted root on a logical volume

And that's ignoring multiple physical volumes. Given this I suspect that to get
a general case the cryptsetup and lvm scripts will need to be combined but
that's way beyond any time I've got at the moment. I am happy to test out stuff
for case 2 above now I've set up my test box though.

Created an attachment (id=5608)
Changed script for georgek's setup

I created new package, version 0.40, which has following changes:
- LVM cryptoroot is supported (actually, since I've moved myself to
  LVM cryptoroot, I haven't tested the _normal_ way this time)

- existing cryptoroot is by default automatically detected by
  mkinitramfs hook script - this can be overriden by configuration
  file

- cryptoswap can be configured to be used

- no more needed to pass encrypted= on command line - if config file
  contains required variables, or automatic detection is used, it
  Just Works

Hook scripts will use configuration file /etc/mkintramfs/crypto.conf which is
by default configured to detect encrypted root automatically and not to do
anything with encrypted swap.

Other notes:

- Any automatically detected settings are stored on the initramfs to file
  /conf/crypto.conf

- Modules are added to end of /conf/modules on ramdisk instaed of being loaded
  by the cryptsetup script itself

- Modules to load can be selected in the /etc/mkintramfs/cryptsetup.conf
  file. By default, and for safery, more modules are loaded than really are
  needed (aes-i586 aes blowfish sha256 sha512) - I did not find a way to
  reliably detect which module would be required for current filesystem.

The packages are signed with my key, for which the fingerprint is
E80A 55FB 9CC0 BF82 0D8D E41F B508 8FBA 4659 28DC and the key is available from
standard keyservers.

Hile, I've had a look at your version 0.41. Unfortunately it won't work for me as my root partition != my encrypted partition.

I've produced this little script to print the cryptsetup command which is needed. It works for my case but I can't test it for your case as I haven't built another box. Can you see if it works for you too.

I added this package to be a cryptsetup wishlist bug - since the patch is not for
initramfs, but a separate initramfs-cryptsetup package, I think it's logical that
this package would be generated from cryptsetup source package, really no
need for a separate source package.

Of course I'm not going to suggest integrating this to cryptsetup itself, it can be
a separate package built from cryptsetup sources.

This seems to be more important in dapper since mkinitrd relies on devfs and the kernel seems to be moving past that.

Looks like the UI for this made it into Fedora Core 5. Any chance we can use some of their work?

http://blog.fubar.dk/?p=64

I don't know how much coordination Redhat has with Gnome regarding their code for this.

It should also be said that the wiki article on full disk encryption (https://wiki.ubuntu.com/FullDiskEncryptionHowto) it woefully out of date. An update with current work on LUKS would bring more developers to this bug.

su, 2006-04-09 kello 05:35 +0000, dguido kirjoitti:
> Looks like the UI for this made it into Fedora Core 5. Any chance we can use some of their work?
>
> http://blog.fubar.dk/?p=64
>

Nope. Similar support has been in ubuntu for over a year, though the
redhat version is better integrated and cleaner.

What they have is just support for encrypted removable media, there is
no support for initializing encrypted media (system-tools stuff) or for
installing to encrypted system.

FYI, if you are interested - after I wrote my first patch I found out
it's possible to a chain where there is
  - encrypted raw partition (cryptsetup luksOpen /dev/hda2 system)
  - LVM inside this encrypted partition (vgchange -ay system, requires
    one line added to /etc/lvm/lvm.conf so that device mapper nodes are
    recognized by lvm)
  - System installed completely to LVM, including swap

My current packages for dapper initramfs-cryptsetup support this type of
encryption, I'm actually writing this mail from such a system ;) See
http://ner.dy.fi/deb/ directory for packages if you're interested.

On my todo list is making a cryptsetup udeb for installer and adding
support for cryptsetup to d-i partmap-crypto module, just haven't done
it.

--
Ilkka Tuohela / Nixu Oy <email address hidden>
PGP-fingerprint: EAE2 B9CF BFE3 A6A1 09DD 3C12 C721 CF5A EB00 F285
Mobile phone: +358-40-5233174

Any idea if this will be in Dapper Drake? I really miss it!

Sorry, this is not going to make it into dapper. I have as well stopped developing my own packages for now, since cryptsetup upstream and initramfs upstream are going to implement this as well.

See following related debian pages:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348147
- discusses same problem as this, + changes to initramfs to change
  ROOT cleanly (>0.6.0 initramfs-tools)
http://wiki.debian.org/DebianInstaller/PartmanCrypto
- discusses support for setting up encryption during boot

I'm still going to maintain my own package, and soon I'd like to test if the proposed debian packages support all features I have in my pkg.

Of course, my packages in http://ner.dy.fi/deb/ are still working just as before, and I suggest best way to use it is to create a
' LVM pv on encrypted partition' type of system - ask me for more information. I'm writing this from dapper with my own packages, it's still PITA to set up but works fine when installed.

So is it possible to upgrade to Dapper by first installing the initramfs-cryptsetup at http://ner.dy.fi/deb/ ? (I have encrypted root using cipher=aes-cbc-essiv:sha256 and I don't use LUKS.)

IMO there ought to be a solution to this or some warning about it when trying to upgrade Breezy. Having your system rendered unbootable is no fun.

I found out a strange behaviour in hooks/cryptsetup, rootdetect function.

If you don't use nothing else from device mapper, it will try to use rootfs (ie /dev/mapper/root) to discover it's dependencies, and it will find something not in dm, so cannot be listed in "dmsetup info". In my case, dependency is /dev/hda3 (3,3) and will fail at "dmsetup info -c --noheadings -o name -j 3 -m 3".

I tried to overcome this, but I cannot understand what you mean to get "deps" and the comment "This is not the real root device - find it now".

In my case, just use CRYPTOROOT=$rootfs

could you please check if package version 1.0.4-8ubuntu1 does work for you? there have been many many changes merged from debian, including crypted root filesystem.

I'm setting this bug to 'Fix committed'. Please check if this bug has been fixed for you and set it to either confirmed or fix released

I'll check it after work today. I don't think it supports my exact setup,
because afaik official
package does not even try supporting my setup, which is:

   LUKS partition - LVM VG in decrypted LUKS partition - root and swap in
LVM VG

Anyway, I'll test the package, maybe we could at support for this weird but
nice setup
in later versions - for most people it _is_ just fine if they can us
separately encrypted
root and other partitions from crypttab.

I'll do the testing with my dump partition, no problem.

My setup has the benefit of basiclaly hiding the partitions completely if
you don't have
passphrase to open the LUKS, in addition encrypted swap + resume from that
comes
with single boot passphrase trivially. It's drawback is that you need to
modify lvm.conf
and add a types = [ "device-mapper", 16 ], or LVM does not recognize
partitions inside
a LUKS encryption at all, this makes debugging more interesting.

--

     *hile*

I'd like to test 2:1.0.4-8ubuntu1 but I can only find the source. As I'm testing on a small old box with just the cli system installed I can't sensibly install the toolchain. Is there a binary package for edgy anywhere or can I usefully test by just taking the scripts from this source package.

BTW testing so far with 2:1.0.3-3ubuntu3 works fine with a single encrypted root partition. I guess the system is too small/simple to show up bug 62571 (although when I first tried on a usb disk I couldn't get it to boot - I'll see if there's a relevant bug for this next)

Like hile I want to have lvm on top of my encrypted partition but this doesn't work. (I'm sure I saw a suggested fix somewhere but I can't find it again). Going back to first principles it seems to me that lvm and cryptsetup need be addressed in the same script unless we don't want to allow users to choose whether to put lvm on top of crypt or vice versa (and simpler cases as well of course).

I've done some more testing now with the local-top and hook scripts from 1.0.4-8ubuntu1 (everything else was default edgy packages). There are two things that are still broken for me.

To be clear, I have /dev/hda3 as a LUKS partition which gets mounted on /dev/mapper/cdisk. This then uses lvm to give me /dev/mapper/ubuntu-root and /dev/mapper/ubuntu-home which are mounted at the obvious points. I have also only installed a minimal system so I haven't tested usplash issues I've seen elsewhere (I can do that when the basics are working).

1. The local-top/lvm script will wait a LONG time due to the loop waiting for the root device to appear (ubuntu-root) which can't happen before cryptroot is run. This is easy to bodge and I will add to bug #69217 (although there is no visible action there).

2. The fstype test in local-top/cryptroot returns the wrong answer (ext3 not lvm). If I bodge the test to accept ext3 then boot continues successfully, so this is the only critical problem for me. I looked at the results from /usr/lib/klibc/bin/fstype <$1 and file -Lkbs $1 at all points of the chain getting the following results:

/dev/hda3
fstype: FSTYPE=luks FSSIZE=0
file -Lkbs: data

/dev/mapper/cdisk
fstype: FSTYPE=ext3 FSSIZE=4515147776
file -Lkbs: LVM2 (Linux Logical Volume Manager) , UUID: Ia7Ek2XowWxeCQlu5s5ZfdrbmKv0mTw\012- Linux rev 1.0 ext3 filesystem data (large files)

/dev/mapper/ubuntu-root
fstype: FSTYPE=ext3 FSSIZE=838860800
file -Lkbs: Linux rev 1.0 ext3 filesystem data (large files)

So unfortunately neither looks good enough.

I have a patched /usr/share/initramfs-tools/scripts/local-top/cryptroot to work with a encrypted physical volume and root on lvm. The key is it runs _before_ lvm, thats the only major change, that and it doesn't call "/sbin/vgchange" but calls "lvm vgchange" (nothing should be calling "/sbin/vgchange" in the initrd, it doesn't exist.)

I'll attach the new cryptroot file, just drop that in /usr/share/initramfs-tools/scripts/local-top/ and you should be fine, well if your using edgy, if your using dapper get the deb i made to add cryptlvm support to the initrd at
http://eli.criffield.net/auto_crypted_lvm/cryptlvm-initramfs_1-1_i386.deb

I'm yet to see feisty load any crypted fs from the initrd, see bug 74432

If you want to install on an encrypted lvm from scratch see my post on ubuntuforums
http://ubuntuforums.org/showthread.php?t=293299

Eli Criffield

Hmm, I don't think you really need to modify the scripts for
LUKS - LVM PV - ROOT-ON-LVM configuration, if you use correct
parameters everywhere.

My root command line is simply:
root=/dev/mapper/sys-root resume=/dev/mapper/sys-swap ro quiet

And crypttab contains following line:
sys /dev/sda2 none luks,lvm=sys-root

These work correctly with my setup using 1.0.4-8ubuntu1 from feisty, while there still are following problems with this package:

- 2.6.19 kernel separated cbc to a different module, so I needed to add cbc to hooks/cryptroot module loading function - this is trivial of course

- I added same loops as the initramfs lvm script has to wait for device nodes to appear - my SATA disk in AHCI mode takes a while to init and the cryptroot script has already at that point failed miserably.

I'll add these changes as patches to this bug later

Duh, I don't know what I thought with previous device nodes waiting
patch, it's of course broken, and to prevent waiting in LVM script for
the devices (that's why it worked for me), we need to actually run
before lvm anyway, as was previously told.

So, This patch includes following changes to local-top/cryptroot:

- Load the script before lvm script, since it's doing lvm setup itself for encrypted LVMs (already reported previously)

- Create the symlinks for vgchange and pvscan (done by lvm script, this
is why the script said 'failed to activate lvm' for some people when run before lvm script - lvm script activated them itself, that's why it eventually worked anyway)

- Wait for the raw partition (now in correct place and with timeout inside loop, unlike my broken attempted patch earlier)

- Wait for LVM device similarly instead of just calling vgchange -ay - this is not usually needed but there's no reason to do this right anyway

... and once again I messed up - the patch I submitted last contains some
unnecessary testing code (to allow activating VG by name, it's never done anyway).

Attached is the patch without this part.

More coffee needed, I think...

Thats pretty much what i came up with to get it working.

except that theres no need to create symlinks to vgchange, it should instead call `lvm vgchange`, the lvm script does it incorrectly to by making symlinks.

And yeah it has to run _before_ lvm, it takes care of all the lvm stuff it self, having the lvm script in the initrd is redundant but doesn't hurt anything either.

I'll attach my working /usr/share/initramfs-tools/scripts/local-top/cryptroot

I have the same problems with a normal disk (/dev/hda1) as cryptroot. Introducing a "sleep 5" let me boot my system.

 # Make sure the cryptsource device is available
 if [ ! -e $cryptsource ]; then
  activate_vg $cryptsource
 fi

+ if [ ! -e $cryptsource ]; then
+ sleep 5;
+ fi

 if [ ! -e $cryptsource ]; then
  echo "cryptsetup: Source device $cryptsource not found"
  return 1
 fi

This works a little better, It will check every 1/2 a second for the device, then as soon as it shows up it continues. Should speed things up from the above fix a bit.

Other then this fix cryptsetup-1.0.4+svn26-1ubuntu1 Works for me using lvm on top of a single Luks partition.

/usr/share/initramfs-tools/scripts/local-top/cryptroot
---snip---
        # Make sure the cryptsource device is available
        if [ ! -e $cryptsource ]; then
                activate_vg $cryptsource
                activate_evms $cryptsource
        fi
+ # Check that the cryptsource is there, give it a min to show up
+ count=0
+ while [ $count -lt 360 ]; do
+ count=$(( $count + 1 ))
+ if [ -e $cryptsource ] ; then
+ break
+ fi
+ sleep .5
+ done

        if [ ! -e $cryptsource ]; then
                echo "cryptsetup: Source device $cryptsource not found"
                return 1
        fi

        # Prepare commands
        if /sbin/cryptsetup isLuks $cryptsource > /dev/null 2>&1; then

what do you think of my patch in bug 85640 ?

this applies to feisty though and there might be changes in the init procedures compared to edgy.

Feisty and gutsy now correctly support booting from encrypted LVM properly with cryptsetup package.

Gutsy fails to find the root device in /usr/share/initramfs-tools/hooks/cryptroot because it blindly looks at the fstab entry for root and takes the first entry like so:

while read device mount type options dump pass; do
                if [ "$mount" = "/" ]; then
                        echo "$device"
                        return
                fi
        done

This is not correct for gutsy because the first entry is actually a UUID of the volume (using lvm).
UUID=afc6476b-a4a7-47ac-be56-d2aaafc1136d / ext3 defaults 0 2

So it fails to find the device in the crypttab and therefore does not add it to the conf/conf.d/cryptroot in the initramfs.

If I remove the UUIDs and replace them back with a device name it works.

scudette <email address hidden> writes:

> If I remove the UUIDs and replace them back with a device name it
> works.

Yes, the installer was fixed to not do the UUID conversion for
/dev/mapper/*_crypt devices anymore. You have used a broken version of
the installer, please undo that mangling by hand. Make sure that
/etc/crypytab matches the entry for /etc/fstab for the root device.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4