linux-kernel - Problem with hibernate partitions and encrypted volumes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <530C0DBD.6060502@gmail.com>
Date:	Mon, 24 Feb 2014 21:27:57 -0600
From:	Robert Hancock <hancockrwd@...il.com>
To:	linux-kernel <linux-kernel@...r.kernel.org>,
	pm list <linux-pm@...r.kernel.org>
Subject: Problem with hibernate partitions and encrypted volumes

A while ago I reported this Fedora bug:

https://bugzilla.redhat.com/show_bug.cgi?id=981841

and thought I would check on the kernel side about what the best way to 
handle the problem was.

Essentially the problem relates to the way in which the kernel stores 
the device that it uses to resume and hibernate to/from. During boot, 
dracut writes the device major/minor number of the swap partition to 
/sys/power/resume, which triggers the kernel to resume from disk if a 
valid resume image is present. If not, bootup continues normally, and 
the kernel has stashed away that major/minor pair as 
swsusp_resume_device. Later on, when you choose to hibernate the system 
and "disk" gets written to /sys/power/state, the kernel uses that device 
as the swap partition it will try to save the hibernate image to.

The problem comes in when the swap partition is on a LUKS encrypted 
volume - specifically, when there is more than one encrypted volume on 
the system. (In my case, the machine has separate encrypted /home and 
swap partitions.) Since the kernel stores the resume partition as a 
major/minor pair, it's sensitive to any change in the device ordering. 
It appears that at some point in the Fedora boot process, the device 
nodes for the encrypted volumes get torn down and re-created, and there 
is apparently no guarantee of the order in which this will occur. If the 
devices get recreated in the opposite order (for example if the swap 
partition was originally minor 1 and is now minor 2), the stored device 
ID will no longer refer to a swap partition, and the hibernate process 
discovers this and aborts.

It seems like all of this could be avoided if there was a way for 
userspace to set the device used to store the hibernate image before 
triggering hibernation. As far as I can see there is no way to change 
the device stored in swsusp_resume_device without writing to 
/sys/power/resume, which immediately tries to resume from it. That seems 
like quite a hack when one is trying to hibernate. It seems like the 
"set image device" and "resume" requests should be separated.

Any thoughts?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/