Encrypted swap & hibernation ?

torimus · 07-02-2013, 12:00 PM

Hi,

I'd like to change the current swap partition to encrypted one and still be able to use standard Linux's hibernation (invoked with pm-utils). No other encrypted volumes are required, just swap.

Followed official guide at http://slackware.osuosl.org/slackwar...ADME_CRYPT.TXT I did

created cryptswap device to default /dev/sda2 swap with
Code:
```
cryptsetup luksOpen /dev/sda2 cryptswap
```
added following entry in /etc/crypttab
Code:
```
cryptswap   /dev/sda2   none   swap
```

changed swap mount entry in /etc/fstab to

Code:

/dev/mapper/cryptswap   swap   swap   defaults   0   0

created new swap filesystem with
Code:
```
mkswap /dev/mapper/cryptswap
```
updated /etc/lilo.conf entry for kernel parameters
Code:
```
append="resume=/dev/mapper/cryptswap"
```

rebuild initrd with

Code:

 mkinitrd -c -k 3.9.7 -m ext4 -f ext4 -h /dev/mapper/cryptswap -C /dev/mapper/cryptswap -r /dev/sda1

rerun lilo - no errors

Now if I boot system after hiberation, I can see error messages about /dev/mapper/cryptswap does not exist whereas later a can see this device mounted and working.
Also did remarked LUKS tries to open `/dev/mapper/lukssda2' which I did nowhere defined.

Any idea ?

TracyTiger · 07-02-2013, 12:37 PM

Doesn't using hibernate on an encrypted system defeat one of the primary purposes of having the computer encrypted?

If only a data partition is encrypted perhaps it makes sense, as you can lock and unlock it as needed. But when you are encrypting swap typically you are encrypting the operating system partitions also.

Just asking.

torimus · 07-02-2013, 02:28 PM

LUKS asks for a password to decrypt(unlock) the swap partition at boot, so the whole system snapshot is relatively safe. The primary initialization is handled with init ramdisk stored on an unenrypted partition including unlocking of encrypted ones, so I don't see a contradiction here.

TracyTiger · 07-02-2013, 03:28 PM

When your system is powered back on from hibernate aren't the disks available without encryption (unlocked)?

When your laptop is stolen from your car in a hibernate state won't the disk data be available unencrypted when it is powered back on?

I don't use hibernate on a partially encrypted system so I don't know. I'm just asking.

torimus · 07-02-2013, 03:48 PM

The data stored from memory to an encrypted swap partition at hibernation are inaccessible until proper password is entered at boot. Of course other unencrypted partitions can be read by anyone with physical access to the notebook.

/dev/sda1 unencrypted ext4 system contains linux image and initrd
/dev/sda2 swap partition to be converted to encrypted one

TracyTiger · 07-02-2013, 04:09 PM

I guess I'm not familiar with what happens when a system starts up from hibernate. I didn't think that a boot was involved, but merely the restoring of RAM and continuing where it left off, which I thought would have meant unlocked disk partitions if they were unlocked when hibernate was initiated (RAM moved to disk).

I'll have to experiment some with hibernate and encrypted partitions.

EDIT: Don't let my side issue disrupt the OP request for assistance. Others please respond to torimus request.

EDIT: A link that may be useful to your problem.
https://www.linuxquestions.org/quest...6/#post4801795

Z038 · 07-02-2013, 05:14 PM

Quote:

Originally Posted by Tracy Tiger

When your system is powered back on from hibernate aren't the disks available without encryption (unlocked)?

When your laptop is stolen from your car in a hibernate state won't the disk data be available unencrypted when it is powered back on?

I'm sure several people on this forum (e.g., Alien Bob, Gazl) can explain the process better than I, but what I have observed is that the LUKS encryption password(s) have to be entered before the hibernated image is restored.

Hibernate completely powers off your system after saving everything to your (hopefully encrypted) swap file. When you turn the system back on, it starts with the normal boot process, loads the initrd, attempts to mount and open your root and and swap files. Because they are encrypted, you are prompted for your encryption password(s) to unlock them. It is only then that the hibernation is detected and the system begins to restore the image from swap.

TracyTiger · 07-02-2013, 05:47 PM

So a normal boot process takes place then later the hibernate state is handled.

Thanks for the explanation Z038 and making me a little less ignorant regarding hibernate.

I didn't mean to hijack this thread. My apology. I hope torimus solves the original problem.

Z038 · 07-02-2013, 06:03 PM

Quote:

Originally Posted by torimus

Now if I boot system after hiberation, I can see error messages about /dev/mapper/cryptswap does not exist whereas later a can see this device mounted and working.
Also did remarked LUKS tries to open `/dev/mapper/lukssda2' which I did nowhere defined.

I don't know about the /dev/mapper/cryptswap error messages you are getting, but the explanation of the -C parameter in the man pages for mkinitrd explains the /dev/mapper/luks<device> name you are seeing.

Code:

 -C device list
              A colon (:) delimited list of luks encrypted block devices to be unlocked by the  initrd  using  crypt-
              setup.   All  devices  that  must be unlocked in order to access the root filesystem must be specified.
              e.g.

                -C /dev/sda2:/dev/sda3

              Each unlocked device will be  assigned  an  automatically  generated  luks  device  name  of  the  form
              luks<device> where '<device>' will be the basename of the encrypted device.  e.g.

                /dev/mapper/lukssda2

              As  a  convenience to users, where -r specifies one of the device names listed on the -C option it will
              be automatically adjusted to use the correct luks device name. i.e.

                "-C /dev/sda2 -r /dev/sda2" and
                "-C /dev/sda2 -r /dev/mapper/lukssda2"

              are equivalent.
              (Use with '-r' option).

I don't think you need to use /etc/crypttab if you are unlocking devices via the -C parameter of mkinitrd. I am using LUKS and LVM both and encrypting all partitions except for /boot, so perhaps my situation is different, but I get a double prompt for the LUKS password for each device if I specify it on the -C parm of mkinitrd and also add it to /etc/crypttab.