linux-kernel - Suspend-to-disk issue with identifying swap partition

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]

Date:	Tue, 09 Jul 2013 22:08:12 -0600
From:	Robert Hancock <hancockrwd@...il.com>
To:	linux-kernel <linux-kernel@...r.kernel.org>,
	pm list <linux-pm@...ts.linux-foundation.org>
Subject: Suspend-to-disk issue with identifying swap partition

I recently ran into a problem with suspend to disk on Fedora 19, which I 
reported here:

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

In this case swap and /home are encrypted volumes. Essentially (from 
what I understand, correct me if I'm wrong) what happens is that when 
dracut boots up, unlocks the encrypted swap and writes the major/minor 
number of the swap partition to /sys/power/resume to try to resume from 
it, and fails as there's no hibernate image present, the kernel still 
stashes away the major/minor number of the device into 
swsusp_resume_device (see resume_store in kernel/power/hibernate.c). For 
whatever reason those dm-crypt mappings get torn down after dracut 
finishes and recreated afterwards. As it turned out, because of the 
order of the LUKS entries on the kernel command line versus the order of 
the lines in /etc/fstab, the mappings were being recreated in the 
opposite order during the main boot sequence. This resulted in that 
stored major/minor device in swsusp_resume_device now pointing at the 
/home partition instead of the swap partition. When you go to hibernate, 
it fails as obviously that device isn't a swap partition.

It seems to me that it's not a great idea to stash away major/minor 
numbers at attempted resume and try to use them later on. There's no 
guarantee that they will still point at the same device or even exist at 
all. It appears that if the resume device was never explicitly set at 
hibernate time, then the kernel will just pick a usable swap partition 
to hibernate to, but once userspace has set a resume device, there's no 
way to get the kernel to forget about that device and just auto-detect 
at hibernate time again. And if that device no longer exists or isn't a 
swap device anymore, it seems like you're pretty much screwed.

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/