Bug#397887: Re: Re: Bug#397887: Re: Bug#397887: [Pkg-cryptsetup-devel] Bug#397887: resume support renders system unbootable
also sprach David Härdeman [EMAIL PROTECTED] [2006.11.13.0014 +0100]: So that means that suspend2disk actually removes the swap signature from disk when you suspend. I seemed to recall that the suspend solutions didn't do that but reading the source it seems I'm wrong. Aparently. Also note that there are two different implementations of suspend2disk... I wrote a quick patch to add detection of swsusp, suspend2 and uswsusp to fstype and sent it to the to the klibc ML and as a BR against klibc-utils a couple of minutes ago. You rock. Thanks! -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems signature.asc Description: Digital signature (GPG/PGP)
Bug#397887: Re: Re: Bug#397887: Re: Bug#397887: [Pkg-cryptsetup-devel] Bug#397887: resume support renders system unbootable
On Mon, November 13, 2006 10:39, martin f krafft said: also sprach David Härdeman [EMAIL PROTECTED] [2006.11.13.0014 +0100]: So that means that suspend2disk actually removes the swap signature from disk when you suspend. I seemed to recall that the suspend solutions didn't do that but reading the source it seems I'm wrong. Aparently. Also note that there are two different implementations of suspend2disk... I take it that you're referring to the in-kernel swsusp and out-of-kernel suspend2 projects? If yes, they are both supported by the patch I wrote (and also the new and shiny in-kernel uswsusp). If no, please tell me which suspend implementation I've missed. And on a related note, this bug now seems to be as fixed as can be in the sense of cryptsetup. The bug report to watch is now #398302 (add suspend detection to fstype). -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397887: [Pkg-cryptsetup-devel] Bug#397887: resume support renders system unbootable
On Sat, Nov 11, 2006 at 05:52:35PM +0100, martin f krafft wrote: also sprach David Härdeman [EMAIL PROTECTED] [2006.11.11.1239 +0100]: cryptswap /dev/hda2 cryptroot keyscript=/root/decrypt_derived,hash=sha256,size=256,cipher=aes-cbc-essiv:sha256 So how do I initialise /dev/hda2 for this to work? Am I expected to run the decrypt_derived script and take the output as keyphrase? If the encrypted swap partition is already setup, remove it with swapoff -a; cryptsetup remove cryptswap Then, provided that the swap entry is configured in /etc/crypttab, run /etc/init.d/cryptdisks start and it'll do the setup for you. After that you'll need to run mkswap on the newly created /dev/mapper/cryptswap device and swapon -a again. After this is done you should have an encrypted swap up an running again (but based on the derived key), so regenerate the initramfs image and see whether it is now able to setup the swap device during the initramfs stage of the boot. -- David Härdeman
Bug#397887: [Pkg-cryptsetup-devel] Bug#397887: resume support renders system unbootable
On Sat, Nov 11, 2006 at 05:09:44PM +0100, martin f krafft wrote: also sprach David Härdeman [EMAIL PROTECTED] [2006.11.11.1239 +0100]: Ok, I've committed fixes for both your bugs to the SVN repo. Could you please test the package? Either by downloading it from: http://www.hardeman.nu/~david/cryptsetup_1.0.4-7_i386.deb I installed it, made the changes you suggested, and was left with an unbootable system, but I think it was my fault. So I tried again, with this crypttab: cr_hda5 /dev/hda5 none luks cr_hda2 /dev/hda2 cr_hda5 keyscript=/tmp/decrypt_derived,hash=sha256,size=256,cipher=aes-cbc-essiv:sha256 [...] But when creating the initramfs, all I got was: update-initramfs: Generating /boot/initrd.img-2.6.18-2-686 cryptsetup: WARNING: target cr_hda2 uses a key file, skipped and /conf/conf.d/cryptroot does not list cr_hda2. That means that the keyscript option wasn't accepted for some reason. I'm not able to reproduce this (by using a valid keyscript which is present and executable) Are you sure the script was present and that it was executable? If it is, could you edit /usr/share/initramfs-tools/hooks/cryptsetup and add some debugging statements around the keyscript part of the get_device_opts function and also towards the end of the same function where the uses a key file text is printed and then run update-initramfs -u? -- David Härdeman
Bug#397887: Re: Bug#397887: [Pkg-cryptsetup-devel] Bug#397887: resume support renders system unbootable
also sprach David Härdeman [EMAIL PROTECTED] [2006.11.12.1645 +0100]:
Then, provided that the swap entry is configured in /etc/crypttab, run
/etc/init.d/cryptdisks start and it'll do the setup for you.
lapse:~# grep hda2 /etc/crypttab
cr_hda2 /dev/hda2 cr_hda5
keyscript=/root/decrypt_derived,hash=sha256,size=256,cipher=aes-cbc-essiv:sha256
lapse:~# /etc/init.d/cryptdisks start
Starting remaining crypto disks... cr_hda5(running) cr_hda6(running)
cr_hda7(running) cr_hda8(running) cr_hda9(running) cr_hda2(starting)-e
- The device /dev/hda2 contains a valid filesystem type swap.
the precheck for '/dev/hda2' failed, skipping
It doesn't... I had to dd /dev/zero for a bit, then it worked. Just FYI.
After this is done you should have an encrypted swap up an running again
(but based on the derived key), so regenerate the initramfs image and
see whether it is now able to setup the swap device during the initramfs
stage of the boot.
Nope, I am only getting
cryptsetup: unknown fstype, bad password or options?
[...]
ad inifitum...
The problem seems to be the lack of /usr/bin/wc in the initrd, which
the keyscript needs -- the init.d script later complains about
a missing wc.
So I hacked the attached version, which does without wc and cut, but
the initramfs still does not boot. In retrospect, busybox should be
providing all these...
I think the reason is that even though my cryptswap gets
created/setup correctly, /bin/fstype returns unknown for FSTYPE, and
thus the cryptroot script thinks that something went wrong and loops
endlessly. For some reason, mkswap didn't work. It did, however,
when I tried again.
Anyway, the problem continues to exist once I tried suspend2disk,
since now surely fstype doesn't recognise the partition type
anymore. I am not sure what the point is of verifying a valid
filesystem type -- fstype is never going to know about all of them.
So why not just skip the $FSTYPE = unknown check and continue if the
mapping was set up properly?
--
.''`. martin f. krafft [EMAIL PROTECTED]
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
#!/bin/sh
NODE=$1
ME=${0##*/}
if [ -z $NODE ]; then
echo $ME: must be executed with a crypto device as argument 2
exit 1
fi
if ! device=$(dmsetup table 2/dev/null | grep $NODE); then
echo $ME: failed to read device-mapper table 2
exit 1
fi
if [ -z $device ]; then
echo $ME: device $NODE doesn't exist 2
exit 1
fi
seen=0
IFS_old=$IFS; IFS='
';
for i in $device; do seen=$(($seen + 1)); done
IFS=$IFS_OLD
if [ $seen -ne 1 ]; then
echo $0: more than one device match $1 2
exit 1
fi
eval set -- $device
if [ $4 != crypt ]; then
echo $ME: device $NODE is not a crypto device 2
exit 1
fi
echo $6
exit 0
signature.asc
Description: Digital signature (GPG/PGP)
Bug#397887: Re: Bug#397887: [Pkg-cryptsetup-devel] Bug#397887: resume support renders system unbootable
also sprach David Härdeman [EMAIL PROTECTED] [2006.11.12.1715 +0100]: I'm not able to reproduce this (by using a valid keyscript which is present and executable) Of course I forgot to make it +x. More in the other reply. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems signature.asc Description: Digital signature (GPG/PGP)
Bug#397887: Re: Bug#397887: [Pkg-cryptsetup-devel] Bug#397887: resume support renders system unbootable
On Sun, Nov 12, 2006 at 09:48:16PM +0100, martin f krafft wrote: also sprach David Härdeman [EMAIL PROTECTED] [2006.11.12.1645 +0100]: Then, provided that the swap entry is configured in /etc/crypttab, run /etc/init.d/cryptdisks start and it'll do the setup for you. lapse:~# grep hda2 /etc/crypttab cr_hda2 /dev/hda2 cr_hda5 keyscript=/root/decrypt_derived,hash=sha256,size=256,cipher=aes-cbc-essiv:sha256 lapse:~# /etc/init.d/cryptdisks start Starting remaining crypto disks... cr_hda5(running) cr_hda6(running) cr_hda7(running) cr_hda8(running) cr_hda9(running) cr_hda2(starting)-e - The device /dev/hda2 contains a valid filesystem type swap. the precheck for '/dev/hda2' failed, skipping It doesn't... I had to dd /dev/zero for a bit, then it worked. Just FYI. Probably some old signature left on the disk. I'm not sure but it's completely possible that e.g. luks leaves the first block or two untouched. After this is done you should have an encrypted swap up an running again (but based on the derived key), so regenerate the initramfs image and see whether it is now able to setup the swap device during the initramfs stage of the boot. Nope, I am only getting cryptsetup: unknown fstype, bad password or options? [...] ad inifitum... The problem seems to be the lack of /usr/bin/wc in the initrd, which the keyscript needs -- the init.d script later complains about a missing wc. So I hacked the attached version, which does without wc and cut, but the initramfs still does not boot. In retrospect, busybox should be providing all these... Ah, that's right. I've used the suggestions you've made to change my local version of the script. I think the reason is that even though my cryptswap gets created/setup correctly, /bin/fstype returns unknown for FSTYPE, and thus the cryptroot script thinks that something went wrong and loops endlessly. For some reason, mkswap didn't work. It did, however, when I tried again. I think the reason is that you changed the script slightly when you rewrote it, in the attached script, the last line says echo ... while it used to say echo -n ... so now the passphrase which the swap partition was setup with included a newline so the first time you used your changed script you also got a different key for the swap partition. Anyway, the problem continues to exist once I tried suspend2disk, since now surely fstype doesn't recognise the partition type anymore. I am not sure what the point is of verifying a valid filesystem type -- fstype is never going to know about all of them. So you did manage to boot using the script after rewriting it and rerunning mkswap? And then it failed after you'd done a suspend2disk for the first time, correct? So why not just skip the $FSTYPE = unknown check and continue if the mapping was set up properly? fstype is the only way that the initramfs script can know if a dm-crypt device has been setup with the right passphrase or not since the only thing that differences the wrong key from the right one is that the dm-crypt device that is setup contains gibberish. -- David Härdeman
Bug#397887: Re: Bug#397887: Re: Bug#397887: [Pkg-cryptsetup-devel] Bug#397887: resume support renders system unbootable
also sprach David Härdeman [EMAIL PROTECTED] [2006.11.12.2308 +0100]: created/setup correctly, /bin/fstype returns unknown for FSTYPE, and thus the cryptroot script thinks that something went wrong and loops endlessly. For some reason, mkswap didn't work. It did, however, when I tried again. I think the reason is that you changed the script slightly when you rewrote it, in the attached script, the last line says echo ... while it used to say echo -n ... so now the passphrase which the swap partition was setup with included a newline so the first time you used your changed script you also got a different key for the swap partition. Good spot. This sound plausible, we'll just assume this is what happened. :) Anyway, the problem continues to exist once I tried suspend2disk, since now surely fstype doesn't recognise the partition type anymore. I am not sure what the point is of verifying a valid filesystem type -- fstype is never going to know about all of them. So you did manage to boot using the script after rewriting it and rerunning mkswap? And then it failed after you'd done a suspend2disk for the first time, correct? Yes. So why not just skip the $FSTYPE = unknown check and continue if the mapping was set up properly? fstype is the only way that the initramfs script can know if a dm-crypt device has been setup with the right passphrase or not since the only thing that differences the wrong key from the right one is that the dm-crypt device that is setup contains gibberish. Ouch. I guess this is fixed with luks, huh? Anyway, so we need to add detection for uswsusp and suspend2 swap partitions to fstype I guess... -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems signature.asc Description: Digital signature (GPG/PGP)
Bug#397887: Re: Bug#397887: Re: Bug#397887: [Pkg-cryptsetup-devel] Bug#397887: resume support renders system unbootable
On Sun, Nov 12, 2006 at 11:24:53PM +0100, martin f krafft wrote: also sprach David Härdeman [EMAIL PROTECTED] [2006.11.12.2308 +0100]: created/setup correctly, /bin/fstype returns unknown for FSTYPE, and thus the cryptroot script thinks that something went wrong and loops endlessly. For some reason, mkswap didn't work. It did, however, when I tried again. I think the reason is that you changed the script slightly when you rewrote it, in the attached script, the last line says echo ... while it used to say echo -n ... so now the passphrase which the swap partition was setup with included a newline so the first time you used your changed script you also got a different key for the swap partition. Good spot. This sound plausible, we'll just assume this is what happened. :) Anyway, the problem continues to exist once I tried suspend2disk, since now surely fstype doesn't recognise the partition type anymore. I am not sure what the point is of verifying a valid filesystem type -- fstype is never going to know about all of them. So you did manage to boot using the script after rewriting it and rerunning mkswap? And then it failed after you'd done a suspend2disk for the first time, correct? Yes. So that means that suspend2disk actually removes the swap signature from disk when you suspend. I seemed to recall that the suspend solutions didn't do that but reading the source it seems I'm wrong. So why not just skip the $FSTYPE = unknown check and continue if the mapping was set up properly? fstype is the only way that the initramfs script can know if a dm-crypt device has been setup with the right passphrase or not since the only thing that differences the wrong key from the right one is that the dm-crypt device that is setup contains gibberish. Ouch. I guess this is fixed with luks, huh? Yup (although the initramfs scripts still run a fstype check, and I think it'll stay that way for now, it's better to fix fstype) Anyway, so we need to add detection for uswsusp and suspend2 swap partitions to fstype I guess... I wrote a quick patch to add detection of swsusp, suspend2 and uswsusp to fstype and sent it to the to the klibc ML and as a BR against klibc-utils a couple of minutes ago. -- David Härdeman
Bug#397887: [Pkg-cryptsetup-devel] Bug#397887: resume support renders system unbootable
On Fri, Nov 10, 2006 at 01:43:05PM +0100, martin f krafft wrote: also sprach David Härdeman [EMAIL PROTECTED] [2006.11.10.1331 +0100]: The hook should warn about these situations though and then skip adding the resume partition details to the initramfs image...I'll fix that That's what I meant. Thanks for reading through my blather. Ok, I've committed fixes for both your bugs to the SVN repo. Could you please test the package? Either by downloading it from: http://www.hardeman.nu/~david/cryptsetup_1.0.4-7_i386.deb or, if you don't want to install deb's built by non-DD's, get the source yourself from the svn repo (svn://svn.debian.org/pkg-cryptsetup/) On a related note, if you do want to be able to resume from swap without needing extra passphrases, the solution that I spoke with Erich about (which I have working locally) is to first setup the root partition (using e.g. LUKS) and then derive a key for the swap partition using a hash of the root partition key. This would give the swap partition a static key which does not need to be stored in the image, thus allowing (u)swsusp. Okay, but why a hash? Why not just the same passphrase then? Two reasons: 1) Most importantly, I'm a lazy bastard. The easiest way to get the root key from an independent script is to call dmsetup table which provides the key as a hex-ascii string which would need to be converted back to binary representation. 2) Paranoia, I'm not sure it's a good idea to have several pieces of known source data (i.e. superblocks) encrypted with the same key. Not something I can back up with any authority or research of course :) The script is very simple, I've attached it as an example. If you want to use it, just plop it somewhere (let's say under /root) and make it executable. The change /etc/crypttab so that it says something like: cryptroot /dev/hda1 none luks cryptswap /dev/hda2 cryptroot keyscript=/root/decrypt_derived,hash=sha256,size=256,cipher=aes-cbc-essiv:sha256 The keyscript will be copied into the initramfs image at creation time and after that you'll have a static key for swap without having to enter two passphrases. I'm planning to commit it once I've written some more documentation for it (so it might be post-Etch). -- David Härdeman #!/bin/sh if [ -z $1 ]; then echo $0: must be executed with a crypto device as argument 2 exit 1 fi if ! device=$(dmsetup table 2 /dev/null | grep $1); then echo $0: failed to read device-mapper table 2 exit 1 fi if [ -z $device ]; then echo $0: device $1 doesn't exist 2 exit 1 fi if [ $(echo $device | wc -l) -ne 1 ]; then echo $0: more than one device match $1 2 exit 1 fi type=$(echo -n $device | cut -d' ' -f4) if [ $type != crypt ]; then echo $0: device $1 is not a crypto device 2 exit 1 fi echo -n $device | cut -d' ' -f6 exit 0
Bug#397887: [Pkg-cryptsetup-devel] Bug#397887: resume support renders system unbootable
also sprach David Härdeman [EMAIL PROTECTED] [2006.11.11.1239 +0100]: Ok, I've committed fixes for both your bugs to the SVN repo. Could you please test the package? Either by downloading it from: http://www.hardeman.nu/~david/cryptsetup_1.0.4-7_i386.deb I installed it, made the changes you suggested, and was left with an unbootable system, but I think it was my fault. So I tried again, with this crypttab: cr_hda5 /dev/hda5 none luks cr_hda2 /dev/hda2 cr_hda5 keyscript=/tmp/decrypt_derived,hash=sha256,size=256,cipher=aes-cbc-essiv:sha256 [...] But when creating the initramfs, all I got was: update-initramfs: Generating /boot/initrd.img-2.6.18-2-686 cryptsetup: WARNING: target cr_hda2 uses a key file, skipped and /conf/conf.d/cryptroot does not list cr_hda2. Thanks for your efforts! -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems signature.asc Description: Digital signature (GPG/PGP)
Bug#397887: [Pkg-cryptsetup-devel] Bug#397887: resume support renders system unbootable
also sprach David Härdeman [EMAIL PROTECTED] [2006.11.11.1239 +0100]: cryptswap /dev/hda2 cryptroot keyscript=/root/decrypt_derived,hash=sha256,size=256,cipher=aes-cbc-essiv:sha256 So how do I initialise /dev/hda2 for this to work? Am I expected to run the decrypt_derived script and take the output as keyphrase? If I do that, I get: lapse:~# cryptsetup luksFormat /dev/hda2 #[1,376] WARNING! This will overwrite data on /dev/hda2 irrevocably. Are you sure? (Type uppercase yes): YES Enter LUKS passphrase: the hash output from /root/decrypt_derived cr_hda5 Verify passphrase: the hash output from /root/decrypt_derived cr_hda5 Command successful. lapse:~# /etc/init.d/cryptdisks start#[377] Starting remaining crypto disks... cr_hda5(running) cr_hda6(running) cr_hda7(running) cr_hda8(running) cr_hda9(running) cr_hda2(starting)-e - The device /dev/hda2 contains a valid filesystem type crypto_LUKS. the precheck for '/dev/hda2' failed, skipping -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems signature.asc Description: Digital signature (GPG/PGP)
Bug#397887: [Pkg-cryptsetup-devel] Bug#397887: resume support renders system unbootable
On Fri, November 10, 2006 10:34, martin f krafft said: As of late, cryptsetup figures out what swap device I need to resume from disk and tells initramfs to also initialise that device even before root is brought up. The problem is quite simply that some of us have previously configured the swap device with a random passphrase, or a keyfile stored somewhere in /etc. Now, all of a sudden, we're expected to enter the key during initramfs? I am sorry, I cannot remember 2048 bytes of key material, nor would I remember what random string the kernel used to set up the swap device before the latest cryptsetup upgrade. You're using the derive-passphrase-from-another-crypto-mapping thing that I mentioned earlier in private email correspondence, right? (If so, I have a really simple solution which uses a keyscript instead and which will work without any further changes) -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397887: [Pkg-cryptsetup-devel] Bug#397887: resume support renders system unbootable
On Fri, November 10, 2006 12:10, David Härdeman said: On Fri, November 10, 2006 10:34, martin f krafft said: As of late, cryptsetup figures out what swap device I need to resume from disk and tells initramfs to also initialise that device even before root is brought up. The problem is quite simply that some of us have previously configured the swap device with a random passphrase, or a keyfile stored somewhere in /etc. Now, all of a sudden, we're expected to enter the key during initramfs? I am sorry, I cannot remember 2048 bytes of key material, nor would I remember what random string the kernel used to set up the swap device before the latest cryptsetup upgrade. You're using the derive-passphrase-from-another-crypto-mapping thing that I mentioned earlier in private email correspondence, right? Sorry, I'm confused, that was a conversation I had with Erich Schubert. My crypttab says cr_hda2 /dev/hda2 /etc/keys/hda2.luks luks cryptsetup should ensure that /etc/keys/hda2.luks is available as such during initramfs. If the key is specified as /dev/urandom, cryptsetup must react differently and prompt the user for a new, static passphrase. It can't provide you with the keyfile during boot because that would require the keyfile to be stored inside the initramfs image unencrypted. Similarly, if you have a random key, there is no way the resume would work so a resume partition shouldn't be specified in the relevant scripts. The hook should warn about these situations though and then skip adding the resume partition details to the initramfs image...I'll fix that On a related note, if you do want to be able to resume from swap without needing extra passphrases, the solution that I spoke with Erich about (which I have working locally) is to first setup the root partition (using e.g. LUKS) and then derive a key for the swap partition using a hash of the root partition key. This would give the swap partition a static key which does not need to be stored in the image, thus allowing (u)swsusp. -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397887: [Pkg-cryptsetup-devel] Bug#397887: resume support renders system unbootable
also sprach David Härdeman [EMAIL PROTECTED] [2006.11.10.1331 +0100]: The hook should warn about these situations though and then skip adding the resume partition details to the initramfs image...I'll fix that That's what I meant. Thanks for reading through my blather. On a related note, if you do want to be able to resume from swap without needing extra passphrases, the solution that I spoke with Erich about (which I have working locally) is to first setup the root partition (using e.g. LUKS) and then derive a key for the swap partition using a hash of the root partition key. This would give the swap partition a static key which does not need to be stored in the image, thus allowing (u)swsusp. Okay, but why a hash? Why not just the same passphrase then? -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems signature.asc Description: Digital signature (GPG/PGP)
