Arno Wagner wrote: > On Thu, Jan 06, 2011 at 08:08:55PM -0800, Bryan Kadzban wrote: >> The issue would be whether the device-mapper setup would have to be >> the same post-resume as it was pre-hibernate. I expect it would >> have to be, but this is no different from real filesystems; >> hibernate writes out all of RAM, so the kernel recovers all of its >> pre-hibernate state exactly. (Well, except things like the current >> time.) > > And it woyld need to exclude the swap-setup as well or atomically > change it after reading the image. Bith would be fine for encrypted > swap. True. >>> It seems to me that there is actually no software hook or script >>> thet gets executed during resume, >> From hibernate, there is. It's a normal bootup, including >> initramfs, until some string gets written into /sys/power/resume. >> There might be restrictions on when this write can happen, but I'm >> sure they at least allow some initramfs code to run. > > Seems I misunderstood the respective kernel parameter then. Or it is > an alternative to the mechanism you describe. So writing to > /sys/power/resume replaces the current system with the suspended one? If you mean the "resume=" kernel command-line parameter, then I am fairly sure it will be used by the kernel only in the absence of an initramfs. If an initramfs is present, the kernel will do nothing, and the initramfs will need to support all options like resume= on its own. (Writing to /sys/power/resume is how the initramfs would support the resume= option, of course.) > If it is a normal boot, then hibernate (= suspend to disk) to > encrypted swap and ask for the swap key before the replacement and > set it up via dm-crypt. Yeah, this is what the initramfs needs to do. I don't think there's much chance of the kernel doing it itself, especially in the presence of multiple keyboard layouts. :-) >> From suspend, there is no hook I know of. But suspend doesn't >> normally write anything to disk either, so that's fine. > > I guess you mean "suspend to RAM" here. Yes, to RAM. Should have been more explicit. > Anyways, experimenting on this would nto be that difficult. One thing > you would need to verify is that the image in swap is actually > encrypted with your swap key. The last time I tried this (at least 3 years ago, but I don't remember when exactly), I had a dm-crypted partition with an LVM PV in it, and that PV had one LV for the rootfs and a second for swap. Hibernate and resume (to and from the swap LV) worked fine with the proper initramfs support. I didn't verify that the data was encrypted, but I think it'd be hard to have LVM in between swap and dm-crypt, and have the data go through LVM but not dm-crypt. (I believe that it went through LVM because it worked after resume, and who knows where the blocks got stuck by the LVM layer.) _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
