diff options
Diffstat (limited to 'Documentation/power')
-rw-r--r-- | Documentation/power/swsusp-dmcrypt.txt | 138 | ||||
-rw-r--r-- | Documentation/power/swsusp.txt | 102 | ||||
-rw-r--r-- | Documentation/power/video.txt | 10 |
3 files changed, 207 insertions, 43 deletions
diff --git a/Documentation/power/swsusp-dmcrypt.txt b/Documentation/power/swsusp-dmcrypt.txt new file mode 100644 index 000000000000..59931b46ff7e --- /dev/null +++ b/Documentation/power/swsusp-dmcrypt.txt @@ -0,0 +1,138 @@ +Author: Andreas Steinmetz <ast@domdv.de> + + +How to use dm-crypt and swsusp together: +======================================== + +Some prerequisites: +You know how dm-crypt works. If not, visit the following web page: +http://www.saout.de/misc/dm-crypt/ +You have read Documentation/power/swsusp.txt and understand it. +You did read Documentation/initrd.txt and know how an initrd works. +You know how to create or how to modify an initrd. + +Now your system is properly set up, your disk is encrypted except for +the swap device(s) and the boot partition which may contain a mini +system for crypto setup and/or rescue purposes. You may even have +an initrd that does your current crypto setup already. + +At this point you want to encrypt your swap, too. Still you want to +be able to suspend using swsusp. This, however, means that you +have to be able to either enter a passphrase or that you read +the key(s) from an external device like a pcmcia flash disk +or an usb stick prior to resume. So you need an initrd, that sets +up dm-crypt and then asks swsusp to resume from the encrypted +swap device. + +The most important thing is that you set up dm-crypt in such +a way that the swap device you suspend to/resume from has +always the same major/minor within the initrd as well as +within your running system. The easiest way to achieve this is +to always set up this swap device first with dmsetup, so that +it will always look like the following: + +brw------- 1 root root 254, 0 Jul 28 13:37 /dev/mapper/swap0 + +Now set up your kernel to use /dev/mapper/swap0 as the default +resume partition, so your kernel .config contains: + +CONFIG_PM_STD_PARTITION="/dev/mapper/swap0" + +Prepare your boot loader to use the initrd you will create or +modify. For lilo the simplest setup looks like the following +lines: + +image=/boot/vmlinuz +initrd=/boot/initrd.gz +label=linux +append="root=/dev/ram0 init=/linuxrc rw" + +Finally you need to create or modify your initrd. Lets assume +you create an initrd that reads the required dm-crypt setup +from a pcmcia flash disk card. The card is formatted with an ext2 +fs which resides on /dev/hde1 when the card is inserted. The +card contains at least the encrypted swap setup in a file +named "swapkey". /etc/fstab of your initrd contains something +like the following: + +/dev/hda1 /mnt ext3 ro 0 0 +none /proc proc defaults,noatime,nodiratime 0 0 +none /sys sysfs defaults,noatime,nodiratime 0 0 + +/dev/hda1 contains an unencrypted mini system that sets up all +of your crypto devices, again by reading the setup from the +pcmcia flash disk. What follows now is a /linuxrc for your +initrd that allows you to resume from encrypted swap and that +continues boot with your mini system on /dev/hda1 if resume +does not happen: + +#!/bin/sh +PATH=/sbin:/bin:/usr/sbin:/usr/bin +mount /proc +mount /sys +mapped=0 +noresume=`grep -c noresume /proc/cmdline` +if [ "$*" != "" ] +then + noresume=1 +fi +dmesg -n 1 +/sbin/cardmgr -q +for i in 1 2 3 4 5 6 7 8 9 0 +do + if [ -f /proc/ide/hde/media ] + then + usleep 500000 + mount -t ext2 -o ro /dev/hde1 /mnt + if [ -f /mnt/swapkey ] + then + dmsetup create swap0 /mnt/swapkey > /dev/null 2>&1 && mapped=1 + fi + umount /mnt + break + fi + usleep 500000 +done +killproc /sbin/cardmgr +dmesg -n 6 +if [ $mapped = 1 ] +then + if [ $noresume != 0 ] + then + mkswap /dev/mapper/swap0 > /dev/null 2>&1 + fi + echo 254:0 > /sys/power/resume + dmsetup remove swap0 +fi +umount /sys +mount /mnt +umount /proc +cd /mnt +pivot_root . mnt +mount /proc +umount -l /mnt +umount /proc +exec chroot . /sbin/init $* < dev/console > dev/console 2>&1 + +Please don't mind the weird loop above, busybox's msh doesn't know +the let statement. Now, what is happening in the script? +First we have to decide if we want to try to resume, or not. +We will not resume if booting with "noresume" or any parameters +for init like "single" or "emergency" as boot parameters. + +Then we need to set up dmcrypt with the setup data from the +pcmcia flash disk. If this succeeds we need to reset the swap +device if we don't want to resume. The line "echo 254:0 > /sys/power/resume" +then attempts to resume from the first device mapper device. +Note that it is important to set the device in /sys/power/resume, +regardless if resuming or not, otherwise later suspend will fail. +If resume starts, script execution terminates here. + +Otherwise we just remove the encrypted swap device and leave it to the +mini system on /dev/hda1 to set the whole crypto up (it is up to +you to modify this to your taste). + +What then follows is the well known process to change the root +file system and continue booting from there. I prefer to unmount +the initrd prior to continue booting but it is up to you to modify +this. diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt index 7a6b78966459..b0d50840788e 100644 --- a/Documentation/power/swsusp.txt +++ b/Documentation/power/swsusp.txt @@ -1,22 +1,20 @@ -From kernel/suspend.c: +Some warnings, first. * BIG FAT WARNING ********************************************************* * - * If you have unsupported (*) devices using DMA... - * ...say goodbye to your data. - * * If you touch anything on disk between suspend and resume... * ...kiss your data goodbye. * - * If your disk driver does not support suspend... (IDE does) - * ...you'd better find out how to get along - * without your data. - * - * If you change kernel command line between suspend and resume... - * ...prepare for nasty fsck or worse. + * If you do resume from initrd after your filesystems are mounted... + * ...bye bye root partition. + * [this is actually same case as above] * - * If you change your hardware while system is suspended... - * ...well, it was not good idea. + * If you have unsupported (*) devices using DMA, you may have some + * problems. If your disk driver does not support suspend... (IDE does), + * it may cause some problems, too. If you change kernel command line + * between suspend and resume, it may do something wrong. If you change + * your hardware while system is suspended... well, it was not good idea; + * but it will probably only crash. * * (*) suspend/resume support is needed to make it safe. @@ -30,6 +28,13 @@ echo shutdown > /sys/power/disk; echo disk > /sys/power/state echo platform > /sys/power/disk; echo disk > /sys/power/state +Encrypted suspend image: +------------------------ +If you want to store your suspend image encrypted with a temporary +key to prevent data gathering after resume you must compile +crypto and the aes algorithm into the kernel - modules won't work +as they cannot be loaded at resume time. + Article about goals and implementation of Software Suspend for Linux ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -85,11 +90,6 @@ resume. You have your server on UPS. Power died, and UPS is indicating 30 seconds to failure. What do you do? Suspend to disk. -Ethernet card in your server died. You want to replace it. Your -server is not hotplug capable. What do you do? Suspend to disk, -replace ethernet card, resume. If you are fast your users will not -even see broken connections. - Q: Maybe I'm missing something, but why don't the regular I/O paths work? @@ -117,31 +117,6 @@ Q: Does linux support ACPI S4? A: Yes. That's what echo platform > /sys/power/disk does. -Q: My machine doesn't work with ACPI. How can I use swsusp than ? - -A: Do a reboot() syscall with right parameters. Warning: glibc gets in -its way, so check with strace: - -reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, 0xd000fce2) - -(Thanks to Peter Osterlund:) - -#include <unistd.h> -#include <syscall.h> - -#define LINUX_REBOOT_MAGIC1 0xfee1dead -#define LINUX_REBOOT_MAGIC2 672274793 -#define LINUX_REBOOT_CMD_SW_SUSPEND 0xD000FCE2 - -int main() -{ - syscall(SYS_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, - LINUX_REBOOT_CMD_SW_SUSPEND, 0); - return 0; -} - -Also /sys/ interface should be still present. - Q: What is 'suspend2'? A: suspend2 is 'Software Suspend 2', a forked implementation of @@ -311,3 +286,46 @@ As a rule of thumb use encrypted swap to protect your data while your system is shut down or suspended. Additionally use the encrypted suspend image to prevent sensitive data from being stolen after resume. + +Q: Why can't we suspend to a swap file? + +A: Because accessing swap file needs the filesystem mounted, and +filesystem might do something wrong (like replaying the journal) +during mount. + +There are few ways to get that fixed: + +1) Probably could be solved by modifying every filesystem to support +some kind of "really read-only!" option. Patches welcome. + +2) suspend2 gets around that by storing absolute positions in on-disk +image (and blocksize), with resume parameter pointing directly to +suspend header. + +Q: Is there a maximum system RAM size that is supported by swsusp? + +A: It should work okay with highmem. + +Q: Does swsusp (to disk) use only one swap partition or can it use +multiple swap partitions (aggregate them into one logical space)? + +A: Only one swap partition, sorry. + +Q: If my application(s) causes lots of memory & swap space to be used +(over half of the total system RAM), is it correct that it is likely +to be useless to try to suspend to disk while that app is running? + +A: No, it should work okay, as long as your app does not mlock() +it. Just prepare big enough swap partition. + +Q: What information is usefull for debugging suspend-to-disk problems? + +A: Well, last messages on the screen are always useful. If something +is broken, it is usually some kernel driver, therefore trying with as +little as possible modules loaded helps a lot. I also prefer people to +suspend from console, preferably without X running. Booting with +init=/bin/bash, then swapon and starting suspend sequence manually +usually does the trick. Then it is good idea to try with latest +vanilla kernel. + + diff --git a/Documentation/power/video.txt b/Documentation/power/video.txt index 7a4a5036d123..526d6dd267ea 100644 --- a/Documentation/power/video.txt +++ b/Documentation/power/video.txt @@ -46,6 +46,12 @@ There are a few types of systems where video works after S3 resume: POSTing bios works. Ole Rohne has patch to do just that at http://dev.gentoo.org/~marineam/patch-radeonfb-2.6.11-rc2-mm2. +(8) on some systems, you can use the video_post utility mentioned here: + http://bugzilla.kernel.org/show_bug.cgi?id=3670. Do echo 3 > /sys/power/state + && /usr/sbin/video_post - which will initialize the display in console mode. + If you are in X, you can switch to a virtual terminal and back to X using + CTRL+ALT+F1 - CTRL+ALT+F7 to get the display working in graphical mode again. + Now, if you pass acpi_sleep=something, and it does not work with your bios, you'll get a hard crash during resume. Be careful. Also it is safest to do your experiments with plain old VGA console. The vesafb @@ -64,7 +70,8 @@ Model hack (or "how to do it") ------------------------------------------------------------------------------ Acer Aspire 1406LC ole's late BIOS init (7), turn off DRI Acer TM 242FX vbetool (6) -Acer TM C300 vga=normal (only suspend on console, not in X), vbetool (6) +Acer TM C110 video_post (8) +Acer TM C300 vga=normal (only suspend on console, not in X), vbetool (6) or video_post (8) Acer TM 4052LCi s3_bios (2) Acer TM 636Lci s3_bios vga=normal (2) Acer TM 650 (Radeon M7) vga=normal plus boot-radeon (5) gets text console back @@ -113,6 +120,7 @@ IBM ThinkPad T42p (2373-GTG) s3_bios (2) IBM TP X20 ??? (*) IBM TP X30 s3_bios (2) IBM TP X31 / Type 2672-XXH none (1), use radeontool (http://fdd.com/software/radeon/) to turn off backlight. +IBM TP X32 none (1), but backlight is on and video is trashed after long suspend IBM Thinkpad X40 Type 2371-7JG s3_bios,s3_mode (4) Medion MD4220 ??? (*) Samsung P35 vbetool needed (6) |