Support for encrypted root filesystem (cryptsetup)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cryptsetup (Ubuntu) |
Fix Released
|
Wishlist
|
Unassigned |
Bug Description
No support for LUKS encrypted root filesystems in ubuntu initramfs
Ubuntu initramfs has no support for encrypted root device.
This bug contains link to initramfs-
Ilkka Tuohela (hile) wrote : | #1 |
Ilkka Tuohela (hile) wrote : | #2 |
- Implements encrypted root filesystem support for initramfs (i386 only initially) Edit (5.0 KiB, text/plain)
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=
- 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.
Ilkka Tuohela (hile) wrote : | #3 |
As I told on -devel mailing lists, I have now written a separate
initramfs-
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=
Until we manage to get this package to normal pkg repositories, I'll develop and
make it available from address
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.
George Klein (gk-t-t-l-deactivatedaccount) wrote : | #4 |
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}
# Where is the encrypted partition and what device do we map it to
echo '/dev/hda3 cdisk' >${DESTDIR}
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#
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.
George Klein (gk-t-t-l-deactivatedaccount) wrote : | #5 |
- Changed script for georgek's setup Edit (682 bytes, text/plain)
Created an attachment (id=5608)
Changed script for georgek's setup
Ilkka Tuohela (hile) wrote : | #6 |
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
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
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.
George Klein (gk-t-t-l-deactivatedaccount) wrote : Find encrypted device for root filesystem | #7 |
- Find encrypted device for root filesystem Edit (803 bytes, text/plain)
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.
Ilkka Tuohela (hile) wrote : | #8 |
I added this package to be a cryptsetup wishlist bug - since the patch is not for
initramfs, but a separate initramfs-
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.
Changed in initramfs-tools: | |
assignee: | jbailey → nobody |
status: | Fix Committed → Unconfirmed |
description: | updated |
summary: | + No support for LUKS encrypted root filesystems in ubuntu initramfs |
jbj (jbj-ubu) wrote : | #9 |
This seems to be more important in dapper since mkinitrd relies on devfs and the kernel seems to be moving past that.
dguido (dguido) wrote : | #10 |
Looks like the UI for this made it into Fedora Core 5. Any chance we can use some of their work?
I don't know how much coordination Redhat has with Gnome regarding their code for this.
dguido (dguido) wrote : | #11 |
It should also be said that the wiki article on full disk encryption (https:/
Ilkka Tuohela (hile) wrote : Re: [Bug 21878] Re: Support for encrypted root filesystem (cryptsetup) | #12 |
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://
>
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-
encryption, I'm actually writing this mail from such a system ;) See
http://
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
Gustavo Sverzut Barbieri (barbieri-profusion) wrote : | #13 |
Any idea if this will be in Dapper Drake? I really miss it!
Ilkka Tuohela (hile) wrote : | #14 |
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://
- discusses same problem as this, + changes to initramfs to change
ROOT cleanly (>0.6.0 initramfs-tools)
http://
- 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://
' 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.
robotpoet (robotpoet) wrote : | #15 |
So is it possible to upgrade to Dapper by first installing the initramfs-
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.
Changed in cryptsetup: | |
status: | Unconfirmed → Confirmed |
Gustavo Sverzut Barbieri (barbieri-profusion) wrote : | #16 |
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
Reinhard Tartler (siretart) wrote : | #17 |
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
Changed in cryptsetup: | |
status: | Confirmed → Fix Committed |
Ilkka Tuohela (hile) wrote : Re: [Bug 21878] Re: Support for encrypted root filesystem (cryptsetup) | #18 |
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*
George Klein (gk-t-t-l-deactivatedaccount) wrote : | #19 |
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).
George Klein (gk-t-t-l-deactivatedaccount) wrote : | #20 |
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/
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/
/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: Ia7Ek2XowWxeCQl
/dev/mapper/
fstype: FSTYPE=ext3 FSSIZE=838860800
file -Lkbs: Linux rev 1.0 ext3 filesystem data (large files)
So unfortunately neither looks good enough.
Eli Criffield (launchpad-zendo) wrote : | #21 |
- new cryptroot for mkinitramfs Edit (4.2 KiB, text/plain)
I have a patched /usr/share/
I'll attach the new cryptroot file, just drop that in /usr/share/
http://
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://
Eli Criffield
Ilkka Tuohela (hile) wrote : | #22 |
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/
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
Ilkka Tuohela (hile) wrote : | #23 |
- Patch to wait for device nodes in ramdisk cryptroot script (script broken, use later version) Edit (792 bytes, text/plain)
Ilkka Tuohela (hile) wrote : | #24 |
- Patch to load correct block cipher algorithm for encrypted root in cryptroot-hook Edit (585 bytes, text/plain)
Ilkka Tuohela (hile) wrote : Revised (working) local-top/cryptroot device waiting patch | #25 |
- Patch for lvm support in ramdisk cryptroot script Edit (1.7 KiB, text/plain)
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/
- 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
Ilkka Tuohela (hile) wrote : | #26 |
- Patch for lvm support in ramdisk cryptroot script (without unncessary changes) Edit (1.3 KiB, text/plain)
... 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...
Eli Criffield (launchpad-zendo) wrote : | #27 |
- working cryptroot in 7.04 Edit (5.3 KiB, text/plain)
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/
Sven Lilienthal (sven-lilienthal) wrote : | #28 |
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
Eli Criffield (launchpad-zendo) wrote : | #29 |
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-
/usr/share/
---snip---
# Make sure the cryptsource device is available
if [ ! -e $cryptsource ]; then
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
fi
# Prepare commands
if /sbin/cryptsetup isLuks $cryptsource > /dev/null 2>&1; then
Eduard Wulff (mail-eduard-wulff) wrote : Re: patch from Eli Criffield | #30 |
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.
Ilkka Tuohela (hile) wrote : | #31 |
Feisty and gutsy now correctly support booting from encrypted LVM properly with cryptsetup package.
Changed in cryptsetup: | |
status: | Fix Committed → Fix Released |
scudette (scudette-gmail) wrote : | #32 |
Gutsy fails to find the root device in /usr/share/
while read device mount type options dump pass; do
if [ "$mount" = "/" ]; then
fi
done
This is not correct for gutsy because the first entry is actually a UUID of the volume (using lvm).
UUID=afc6476b-
So it fails to find the device in the crypttab and therefore does not add it to the conf/conf.
If I remove the UUIDs and replace them back with a device name it works.
Reinhard Tartler (siretart) wrote : Re: [Bug 21878] Re: Support for encrypted root filesystem (cryptsetup) | #33 |
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
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...