LUKS Swap partition question

Kvetch · Posted: Sat Mar 05, 2011 3:44 pm Post subject: LUKS Swap partition question

I am interested in encrypting my root partition using luks/dm-crypt. I would like to be able to use the hibernate feature (reading it makes it look like a but of a pain and possibly risky). I am a little confused on how to properly use this feature. The luks guide (http://en.gentoo-wiki.com/wiki/DM-Crypt_with_LUKS#Encrypting_swap_for_installation) states to fill the swap part with random data using urandom but states it is not for suspend2 users and then later states it is not for hibernation users. I just use the in kernel hibernation (swsusp) for hibernate-ram on my other laptops so I would like to still use this if possible. If I understand correctly I should not fill the swap with urandom data is this correct?
Following the "Create the Mappings" Section I don't really see anywhere that the swap partition is encrypted. Am I not following it correctly or missing something. Where do I encrypt my swap?
Thanks

Hu · Moderator Joined: 06 Mar 2007 Posts: 21635

There are two major ways to get the key material for a swap device. One way is to get it from /dev/urandom, which is a good choice if you intend not to persist swap across reboots, since the key would be lost at every shutdown, rendering the contents of the swap volume irrecoverable. The other way is to treat it more like a regular filesystem, and use a key (either via LUKS or the older create mechanism) that you can know and reenter at will. This allows you to recover the contents of the volume on subsequent reboots. Since hibernation writes system state to the swap volume and then halts the machine, you must be able to recover the contents of the swap volume if you want to resume from hibernation. Thus, the note about "not for suspend2 users" is a warning that users who intend to hibernate (through uswsusp, TuxOnIce, or any of the other suspend-to-disk mechanisms) must not use the command that generates a random non-recoverable key for the swap device.

You mention hibernate-ram, which is a suspend-to-ram wrapper. If you only ever suspend to RAM, you do not need the contents of your swap volume to survive reboots, since entering S3 and resuming from it do not involve removing power from RAM.

If you want to use hibernation, prepare your swap volume just like you would for a filesystem. You will need an initramfs to unlock the swap volume before activating resume.

Kvetch · Posted: Sat Mar 05, 2011 8:10 pm Post subject:

Thank you Hu, I appreciate the explanation. For some reason I was thinking that if the battery died on a hibernate to ram, it writes to swap but I assume it just dies on a hard power off. So if I suspend to ram only then I can just get the key using the standard urandom material and have no need to make swap survive on reboot. Awesome

Thanks again.

Hu · Moderator Joined: 06 Mar 2007 Posts: 21635

Correct: s2ram saves only to RAM, so a power-off is just as fatal as it would be if you were actively using the system when power failed. However, the sys-power/suspend package, which is one of the backends that can be used by sys-power/hibernate-script, has a program s2both. It writes the hibernation image to swap, then transitions to S3 instead of halting power. If power is maintained, you can resume from S3, discard the hibernation image, and enjoy the quick resume you get coming out of suspend-to-RAM. If power is lost, then you can resume from the hibernation image. The downside to this approach is that you must write the hibernation image before you transition to S3, so you will wait for that to complete even if you do not deplete the battery while in S3.

Kvetch · Posted: Sat Mar 05, 2011 9:41 pm Post subject:

Perfect. Once again, I appreciate the help and information.

boerKrelis · Posted: Sun Mar 06, 2011 4:47 pm Post subject:

When using a swap partition I got nasty FS corruption every time after thawing (ext4), I think I saw a few bug reports that made it seem I was not the only one.
Haven't had that problem since I started to hibernate to a swap file, inside my LUKS root partition. And since I don't use swap anyway (I 'swapoff' after thawing from hibernation) there's no performance penalty*, but greater simplicity and flexibility.

*) the performance of partition-backed vs file-backed swap is negligable these days anyways last time I heard

Hu · Moderator Joined: 06 Mar 2007 Posts: 21635

boerKrelis · Posted: Mon Mar 07, 2011 8:50 am Post subject:

Ha, bugzilla is up (now version 4, soothing calming icy blue!).
Bug 296472.

I think I followed the documentation well enough to not make the mistake you mentioned (premature access of frozen volumes), so it may have been a problem with ACPI which is completely wonky on this crappy Medion laptop. As it says in the bug, 'board-specific ACPI quirks can affect hibernate results.'
But I'm not looking to solve this, the file-backed swap works fine and this crappy hardware is not worth the trouble.

But I wanted Kvetch to know this alternative solution, swap on file, inside a LUKS partition.

lyallp · Posted: Wed Mar 09, 2011 10:36 am Post subject:

I created 2 partitions on my disk, 1 for /boot, the other for LVM.
I then made the LVM partition encrypted using LUKS.
I then created all my partitions, including SWAP, in LVM.
This neatly sidestepped the whole swap key recovery problem, because the swap partition is encrypted also.

_________________
...Lyall