Suspend-to-RAM and Suspend-to-Disk may seem useful when you don’t want to use your computer but you want to speed up start-up. While especially Suspend-to-RAM can get you to a running system quickly, with all the stuff open as you left it when you suspended your computer, there are certain problems with suspension, especially on mobile devices like notebooks and netbooks.

The big problem both types of suspension share is that they can effectively bypass encryption, which should be standard on a mobile device. My notebook has an encrypted root partition, and after a couple of tests I have now also encrypted my swap partition. Yes, until about 1 hour ago I have been working with an unencrypted swap partition, setup 1 (see below), and have now switched to setup 2 (again, see below).

As mentioned above I have run a series of tests, as usual I have used virtualization for this, as I didn’t really want to re-install my notebook all the time to test the different setups. The basic setup was a VM (using KVM as hypervisor) running CentOS 6.1 64Bit. Each VM had a 8GB hard drive and 512MB of RAM. Packages were exactly the same on all systems.

The differences were in the partition setup.

  1. No LVM, unencrypted swap, encrypted root
  2. No LVM, encrypted swap, encrypted root
  3. Unencrypted LVM, unencrypted swap, encrypted root
  4. Unencrypted LVM, encrypted swap, encrypted root
  5. Encrypted LVM, unencrypted swap, unencrypted root

As I had expected the setups 1 and 3 did not ask for a password upon resuming from Suspend-to-Disk. Thus they would enable anybody who gains access to the notebook to start it into a fully running system, thus bypassing the encryption of the root partition.
Setups 2 and 5 did ask, thus these can be regarded secure, as it’s necessary to supply the password on resumption.
Setup 4 didn’t want to resume at all. It always just booted the system normally. I’ll just mark this as being a problem with running in KVM, as I cannot install any physical machine right now to test this further. I may look into this once I upgrade my system to Fedora 16 or 17.

Another problem I see with Suspend-to-Disk is that you need to reserve additional disk space for the swap partition. While the overall growth of RAM has made swap space nearly obsolete, my swap partition is hardly ever in use, Suspend-to-Disk requires that swap space is at least as big as your RAM in order to be able to store the content of your RAM. In addition you may want to consider that some swap space may be legitimately in use when suspending, thus I suggest using the old rule of having twice as much swap space as you have RAM. This of course “wastes” a lot of space considering that you probably don’t actually suspend that often.

While Suspend-to-RAM does not suffer the problem of having to “waste” disk space in case you want to send your computer to sleep you still have the problem that it does bypass the encryption. Upon resumption no password needs to be supplied in order to get the system running again. This of course cannot be considered secure. And from what I can tell at the moment there is no cure for this, other than maybe using a BIOS password.

In conclusion I think the general suggestion for those who want to be able to securely suspend their computer the only option is to avoid Suspend-to-RAM and use proper encryption of all partitions (except /boot of course). For those who do not want to encrypt their swap partition a BIOS or bootloader password may be an option, but currently I cannot see any reason against encrypted swap space other than that a bootloader password is easier to set up on an existing system.

Thank you!
Dennis Wronka