Bugzilla – Bug 397411
Hibernation won't work with encrypted swap
Last modified: 2011-08-26 10:58:35 UTC
11.0 lets you encrypt root / home. If done so, hibernation doesn't work as the hibernation file is not decrypted (screen goes blank).
I am using suspend to disk with an encrypted home partition and it works well. Please provide the /var/log/pm-susepnd.log of the machine after it failed to suspend to disk.
Are you hibernating to an encrypted partition? Am currently not at home, will post a suspend log later..
No, i don't use encrypted swap. That will probably not work with suspend to disk (i have not tried it yet). I just use s2disk's encryption for suspend.
I was not able to create encrypted / (root), but i am installing with encrypted swap right now. Will report back. Do you have a pointer on how to set up encrypted root with YaST?
Ok. Suspending with encrypted swap indeed does not work, since the encrypted dm-setup is done much too late in the boot process, we would need to access the swap much earlier to resume. However, it fails gracefully, because pm-utils detects that the swap partition used (/dev/mapper/cr_sda1) is different from the partition given to the kernel with "resume=" option (/dev/sda1) and thus refuses to suspend. So i get an error message from kpowersave and can see in the logfile why it failed. This might not be the best solution from an UI perspective and we will surely improve this in the future, but it is not too bad, since it does not cause data loss or data corruption.
Our current scenario means I can't encrypt root, because otherwise there's no partition to hibernate to. If I understand correctly, one can encrypt the swap file during hibernation with s2disk, but the hibernation would have to happen to an UN-encrypted partition. Since (at least on a laptop) hibernation is a must for an effective workflow, the option of an encrypted root becomes pretty redundant, because then I can't use hibernation anymore... But for a laptop, IMHO encryption is a must (I use my laptop for work and I can't afford my data to be flying around in case it gets stolen/lost). Correct? Why encrypt root? http://en.opensuse.org/Encrypted_Root_File_System#Why_encrypt_the_root_file_system.3F
#6: Okay, first, encrypted home has nothing to do with this bug, right? Second: why not create unecrypted _swap_, enable it just before suspend (which is itself encrypted) and disable it after resume?
#7: yes, home has nothing to do with this bug directly. depending on the partition you hibernate to, it doesn't work if that partition is encrypted. Second, I don't understand that scenario? I'm supposed to hibernate to an unencrypted swap and enable/disable it? Could you please clarify? Thanks.
so.. your complaint is that you can't hibernate into encrypted swap. And my answer is "don't use encrypted swap, then".
You can only suspend to a swap partition without heavily tweaking the setup, which needs to be not encrypted (but s2disk can provide you with encryption for suspend). Suspension to a swap file is possible, but not supported on 11.0 due to some constraints. I do not think that an encrypted root partition will create any problems wrt. s2disk, but i have not tried it, since there is no option to set it up.
#9 First, am not complaining, at least I hope I don't sound like it. Second, no my remark is, that IF I encrypt root and home (as offered by the installer now, which is a great feature added, since before I could only encrypt home) I can't hibernate, since hibernation does not work on encrypted partition. So it's more like "option to encrypt root/home breaks hibernation functionality" (since I can only hibernate to root, correct?). That swap itself should be encrypted as well would probably be more an "additional feature request". But if hibernation would work on encrypted partitions, the hibernation file itself would already be encrypted and thus not be able to leak information. I'm not 100% sure but I think Fedora 9 somehow solved the problem of hibernating to an encrypted partition, at least the corresponding bug report has been closed: https://bugzilla.redhat.com/show_bug.cgi?id=247794
(In reply to comment #11 from Peter Keenig) > Second, no my remark is, that IF I encrypt root and home (as offered by the > installer now, Actually i was not able to install an encrypted root with YaST. I tried the installation from the Live-CD. > So it's more like "option to encrypt root/home breaks hibernation > functionality" (since I can only hibernate to root, correct?). No. It should work perfectly fine with encrypted root/home, as long as swap is not encrypted. > That swap itself should be encrypted as well would probably be more an > "additional feature request". > But if hibernation would work on encrypted partitions, the hibernation file > itself would already be encrypted and thus not be able to leak information. The normal setup does not use a "hibernation file". It uses the swap partition. > I'm not 100% sure but I think Fedora 9 somehow solved the problem of > hibernating to an encrypted partition, at least the corresponding bug report > has been closed: https://bugzilla.redhat.com/show_bug.cgi?id=247794 Yes, Fedora apparently handles encrypted swap partitions differently and activates them from initrd before mounting the rootfs. However, i am not sure if it is worth the effort, since we can do encrypted suspend just fine (i will think about implementing an additional "suspend partition" that is only used for suspend, so that the "normal" swap partition can still be encrypted.
but in #12 you said > The normal setup does not use a "hibernation file". It uses the swap partition. so the system per default hibernates to the swap partition, correct? you said I could do encrypted hibernation. How would one accomplish that? http://en.opensuse.org/S2disk doesn't mention anything about it. > Actually i was not able to install an encrypted root with YaST. I tried > the installation from the Live-CD. I think it is only implemented in the "normal" setup. BTW: Does this issue become any easier if one would use a LVM setup with an unencrypted /boot partition?
(In reply to comment #13 from Peter Keenig) > but in #12 you said > > The normal setup does not use a "hibernation file". It uses the swap partition. > so the system per default hibernates to the swap partition, correct? > you said I could do encrypted hibernation. How would one accomplish that? > http://en.opensuse.org/S2disk doesn't mention anything about it. Yes, the s2disk documentation on openSUSE.org is actually written by somebody else (and it is plain wrong), i need to revise it. > > Actually i was not able to install an encrypted root with YaST. I tried > > the installation from the Live-CD. > I think it is only implemented in the "normal" setup. I now installed from the RC3 BiArch DVD and it still does not let me encrypt the root partition. If that works, suspending and resuming from a swapfile inside the encrypted root partition might actually be quite easy, but i am not able to get it working. Do you have a pointer to documentation about that? (sorry, i don't know too much about encryption setup, as you obviously already might have guessed ;) > BTW: Does this issue become any easier if one would use a LVM setup with an > unencrypted /boot partition? It does not really matter. As long as the initrd asks for the credentials of the swap or root partition, this is all pretty easy. But i don't think that our initrd does this (i actually don't know).
(In reply to comment #14 from Stefan Seyfried) > I now installed from the RC3 BiArch DVD and it still does not let me encrypt > the root partition. > If that works, suspending and resuming from a swapfile inside the encrypted > root partition might actually be quite easy, but i am not able to get it > working. I just realized - encrypting root in the setup doesn't work. http://en.opensuse.org/Testing:Features_11.0#Support_root_on_encrypted_filesystem_.28Feature_No:_302191.29 lists it as a feature, but https://bugzilla.novell.com/show_bug.cgi?id=386426 lists it as an unresolved bug. So for now, root can only be encrypted as decribed here: http://en.opensuse.org/Encrypted_Root_File_System > It does not really matter. As long as the initrd asks for the credentials of > the swap or root partition, this is all pretty easy. But i don't think that our > initrd does this (i actually don't know). It's just that I had read http://kde.blogsite.org/?q=node/13 where the person explained that if you set up /boot unencrypted and then all other partitions encrypted in LVM, hibernate/resume would work without modifying the init script (although this decription is for Debian).
FYI: I created a feature request for openSUSE 11.1 related to encrypting swap partitions by default. See bug #399298
It worked at one point; with swap encrypted by passphrase (NOT using s2disk built-in encryption). All that is needed is right order of setup in initrd... ...but no, you don't want to use file on encrypted partition for this. But encrypting swap should be doable.
Following the steps in the article http://en.opensuse.org/Encrypted_Root_File_System allows you to create an encrypted swap, hibernate to it, and restore from it. I've done it. The trick is that you have to go through the LUKS/dm-crypt routine AT BOOT. Pay close attention to the section on the grub configuration. What happens is that the kernel loads from the unencrypted /boot, loads the kernel models required from the initrd to do LUKS, and then asks the password for each of the encrypted partitions on the kernel line of the grub file. At that point, it will see that the swap partition contains hibernation data and restore.
Thanks for the hint. I'm trying to put together some documentation on how to do that best and then incorporate those docs in the Wiki. The easy-to-setup "encrypted swap with random key" can not work with hibernate - as you don't know the key and thus can't resume. This also needs to be clearly documented. I'll keep this bug open until I have finished that documentation, so that I won't forget about it ;)
I have encrypted swap and I can hibernate and resume. I've done this from slightly different approach than presented in <http://en.opensuse.org/Encrypted_Root_File_System>. I wanted completely hide the file system structure besides /boot. i.e. I wanted to have only two primary partitions on disk: one for /boot and another encrypted containing the rest - as many filesystems I like controlled by LVM. I got it also working - with hibernate (suspend to disk) in openSUSE 11.1! Before getting hibernate to work, I got my laptop to hibernate to disk, without being able to resume. Then I figured out that I need to tweak just a bit initrd script run order. And suddenly it all works. I need to enter LUKS password only once for boot and once for resume from disk. While at this I also mention that updating kernel breaks /boot/grub/menu.lst, so it needs to be fixed manually before booting with new kernel. I wrote some quick notes how I did this, but I don't know a better place to share it. I hope it helps to solve this original issue for openSUSE 11.2. - - - - - - - - Install encrypted OpenSUSE 11.1 to a laptop with working suspend to ram and suspend to disk!! (hibernate) support ------------------------------------- //Jiivee 2009-03-18 This document is an extremely simple task list of how to install openSUSE 11.1 to a Lenovo X200s laptop with encrypted filesystems and have also suspend to ram and suspend to disk (hibernate) working with single disk open password. Idea is to have /boot in /dev/sda1 in a small unencrypted partition and rest of the disk LUKS encrypted. On top of LUKS runs LVM2 and its volumes - including swap. Unfortunately openSUSE still lacks support for encrypted disk with installer. Procedure: install openSUSE --------------------------- - Boot from openSUSE 11.1 DVD in rescue mode. - Fill entire disk with random content. I first looked fdisk /dev/sda to get nice block size value. Fill: dd if=/dev/urandom of=/dev/sda bs=8225280 - Reboot. - Boot from openSUSE 11.1 DVD in install mode. - Customize partition setup and do partition based partitioning. We don't touch LVM yet here and use only primary partitions: Partitions: Device Mount Size Label ----------------------------------- /dev/sda1 /boot 128 MB boot /dev/sda2 225 GB /dev/sda3 / 7.76 GB tmproot Last partition takes rest of the disk. No swap is created at this stage. - Select whatever stuff you like for installation, but add cryptconfig package to be installed. - Install openSUSE 11.1 - Reboot Encrypt filesystems ------------------- - Login as root from console. For example <https://help.ubuntu.com/community/EncryptedFilesystemLVMHowto> and <http://en.opensuse.org/Encrypted_Root_File_System> are useful reading to understand what will be done next. - Now it is time to encrypt the unused large /dev/sda2 partition: cryptsetup -y --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sda2 - Map encrypted partition: cryptsetup luksOpen /dev/sda2 crypt The name "crypt" can be changed to whatever liked, but it must be changed in all occurrences below, too. LUKS mapping appears as /dev/mapper/crypt. - I suppose there is pretty much no way getting along than using LVM. Initialize partition for LVM: pvcrypt /dev/mapper/crypt - Create LVM volume group: vgcreate rootg /dev/mapper/crypt Name "rootg" can be replaced with whatever name liked, for example rg. - Create LVM volumes. At least two volumes are needed, but there is now chance to create for example separate home partition. It is good idea to make last the partition, which will later gain space of /dev/sda3. I set up swap and root: Create volumes: lvcreate -n swap -L 4G rootg See what's donw: vgdisplay lvcreate -n root -l 56573 rootg vgdisplay See volumes: lvdisplay -C - Create swap to new volume witl label "swap": mkswap -L swap /dev/mapper/rootg-swap - Turn on swap swapon /dev/mapper/rootg-swap Now encrypted swap has been set up successfully. - Create filesystem(s) to new volume(s). I have only root and I use reiserfs. Ext3 can be used equally well. Create filesystem with label "root": mkreiserfs --format 3.6 -l root /dev/mapper/rootg-root - Mount new filesystem: mount /dev/mapper/rootg-root /mnt Copy root --------- - To be sure there is no extra software running, switch to single user mode: init S - Copy root and make needed mount point directories: cd / ls -la find bin etc home lib opt root sbin srv tmp usr var -depth -print0 | cpio -pmd --null /mnt cd /mnt mkdir boot dev media mnt proc sys To make it boot --------------- - edit /mnt/etc/fstab to look like this: /dev/sda1 /boot reiserfs noatime,acl,user_xattr 1 2 #/dev/sda3 / reiserfs noatime,acl,user_xattr 1 1 /dev/mapper/rootg-root / reiserfs noatime,acl,user_xattr 1 1 /dev/mapper/rootg-swap none swap sw 0 0 proc /proc proc defaults 0 0 sysfs /sys sysfs noauto 0 0 debugfs /sys/kernel/debug debugfs noauto 0 0 usbfs /proc/bus/usb usbfs noauto 0 0 devpts /dev/pts devpts mode=0620,gid=5 0 0 - Edit /boot/grub/menu.lst. There is also resume= statement pointing to LVM volume - don't leave it out. Add there the following entry: ---- ###Don't change this comment - YaST2 identifier: Original name: linux### title openSUSE 11.1 - 2.6.27.7-9 - encrypted root (hd0,0) kernel /vmlinuz-2.6.27.7-9-pae root=/dev/mapper/rootg-root luks_crypt=/dev/sda2 luks="crypt" resume=/dev/mapper/rootg-swap splash=silent showopts vga=0x367 idle=halt initrd /initrd-2.6.27.7-9-pae ---- Failsafe entry: ---- ###Don't change this comment - YaST2 identifier: Original name: failsafe### title Failsafe -- openSUSE 11.1 - 2.6.27.7-9 - encrypted root (hd0,0) kernel /vmlinuz-2.6.27.7-9-pae root=/dev/mapper/rootg-root luks_crypt=/dev/sda2 luks="crypt" showopts ide=nodma apm=off noresume nosmp maxcpus=0 edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 x11failsafe vga=0x367 idle=halt initrd /initrd-2.6.27.7-9-pae ---- - Make a backup of menu.lst: cp -p /boot/grub/menu.lst /boot/grub/menu.lst.save This is needed later. - Some additional kernel modules are needed to make kernel to initially be able to open LUKS. LUKS and LVM2 startup order needs to be changed in initrd to make suspend to disk work. Mkinitrd script run order is defined in /lib/mkinitrd/boot/. To start LUKS bit earlier, we need to rename only one link: mv /lib/mkinitrd/boot/71-luks.sh /lib/mkinitrd/boot/60-luks.sh - Edit /mnt/etc/sysconfig/kernel: ---- # This variable contains the list of modules to be added to the initial # ramdisk by calling the script "mkinitrd" # (like drivers for scsi-controllers, for lvm or reiserfs) # #INITRD_MODULES="ata_generic processor thermal ahci ide_pci_generic fan reiserfs edd" # Encrypted root modules added INITRD_MODULES="ata_generic processor thermal ahci ide_pci_generic fan reiserfs edd aes_generic aes_i586 sha256_generic cbc" ---- - Create a new initrd: mkinitrd -d /dev/mapper/rootg-root -f "dm luks" -m "`grep ^INITRD_MODULES /mnt/etc/sysconfig/kernel | sed -e 's,^.*=,,' -e 's,\",,g'`" Alternatively: cp -p /mnt/etc/sysconfig/kernel /etc/sysconfig/kernel mkinitrd -d /dev/mapper/rootg-root -f "dm luks" - Reboot After reboot suspend to ram and suspend to disk can be tested. If suspend to disk does not work without patching, don't worry yet (I figured out how to get hibernate to work only after patching OS). Gain /dev/sda3 -------------- - Fill /dev/sda3 with random content: dd if=/dev/urandom of=/dev/sda bs=1024k - Alter partition table. It is always somewhat exciting to do this for live disk. fdisk /dev/sda - Observe partition start and end cylinders - Delete /dev/sda3 - Delete /dev/sda2 - Create /dev/sda2 as primary linux partition with same start cylinder as before and ending where /dev/sda3 used to end. - Save changes. - Reboot. Other utilities don't recognize partition size change until rebooted. - Resize LUKS to take all space in /dev/sda2: cryptsetup resize crypt - Resize LVM volume to take whole LUKS offered space: pvresize /dev/mapper/crypt - Resize last created LVM volume on volumegroup: For me this is root volume: vgs Observe number of available extents: vgdisplay Resize volume: lvresize -l +1987 /dev/mapper/rootg-root vgdisplay lvdisplay -C - Finally resize / filesystem: df -k resize_reiserfs /dev/mapper/rootg-root df -k Done. (So far. so good.) Initial patching ---------------- - In YaST Control Center > Software Repositories I added the following repositories: - KDE:Backports - KDE:Community - OpenOffice.org - Drivers for webcams - Mozilla - VideoLan - Packman - In YaST Control Center > Software Management I selected Packages > All packages > Update if newer version is availebla. Some conflicts needed to be solved. I installed patches. These updates include also new kernel, and just rebooting without some manual work renders system unbootable. Don't reboot yet. - Fix /boot/grub/menu.lst. The backup copy is good to have at hands. Make it look like this: ---- # Modified by YaST2. Last modification on Wed Mar 18 18:06:58 EET 2009 default 0 timeout 8 ##YaST - generic_mbr gfxmenu (hd0,0)/message ##YaST - activate ###Don't change this comment - YaST2 identifier: Original name: linux### title openSUSE 11.1 - 2.6.27.19-3.2 - encrypted root (hd0,0) kernel /vmlinuz-2.6.27.19-3.2-pae root=/dev/mapper/rootg-root luks_crypt=/dev/sda2 luks="crypt" resume=/dev/mapper/rootg-swap splash=silent showopts vga=0x367 idle=halt initrd /initrd-2.6.27.19-3.2-pae ###Don't change this comment - YaST2 identifier: Original name: failsafe### title Failsafe -- openSUSE 11.1 - 2.6.27.19-3.2 - encrypted root (hd0,0) kernel /vmlinuz-2.6.27.19-3.2-pae root=/dev/mapper/rootg-root luks_crypt=/dev/sda2 luks="crypt" showopts ide=nodma apm=off noresume nosmp maxcpus=0 edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 x11failsafe vga=0x367 idle=halt initrd /initrd-2.6.27.19-3.2-pae ---- - Verify that luks is started before lvm in /lib/mkinitd/boot, i.e. previous change has not been overwritten - Recreate initrd mkinitd -d /dev/mapper/rootg-root -f "dm luks" - Reboot - At latest at this stage hibernation works. /usr/src/linux/Documentation/power/swsusp.txt states that hibernate won't work if swap is in LVM volume. Well, it does! Now installation is complete and new system is also patched up-to-date. Enjoy! Changing password ----------------- LUKS actually allows to have as many as 8 different passphrases for the same crypted device. To see, whether a device is LUKS device, do cryptsetup isLuks <device>; echo $? For example cryptsetup isLuks /dev/system/root; echo $? Exit status 0 means a LUKS device, To dump LUKS header. This also shows, which key slots are in use. cryptsetup luksDump /dev/system/root To add new key: cryptsetup luksAddKey /dev/system/root This requires knowing at least one of the existing keys. To delete - or release - a key slot: cryptsetup luksKillSlot /dev/system/root 0 This can be done only by knowing a passphrase of some other slot that that being killed.
thanks, Juha!!! Nice howto. Hope the entire encryption will work in 11.2 w/o that lots of handmade work. Already voted for that here: https://features.opensuse.org/305633 , as anyone interested should. :)
The lifecycle of openSUSE 11.2 ended on May 12th 2011. I'm closing this bug to make it easier to focus on upcoming releases. Thank you for reporting this issue and we are sorry that we have not be able to fix it before this version reached its end of life. If you would still like to see this bug fixed and are able to reproduce it against a maintained version, please reopen this bug and change the 'version' of this bug to the applicable version.