[swsusp] encrypt suspend data for easy wiping

[swsusp] encrypt suspend data for easy wiping

[Pavel Machek]

From: Andreas Steinmetz <ast@domdv.de>

To prevent data gathering from swap after resume you can encrypt the
suspend image with a temporary key that is deleted on resume. Note
that the temporary key is stored unencrypted on disk while the system
is suspended... still it means that saved data are wiped from disk
during resume by simply overwritting the key.

Signed-off-by: Pavel Machek <pavel@suse.cz>

---
commit b61ea835309d0fb87cf1c7a2d83d5832ae8eb116
tree 17bfb260d69819d29e84e481382aa090f0a15969
parent d676c816f71e27761f419d399ad6be728c97a4a9
author <pavel@amd.(none)> Sun, 03 Jul 2005 23:34:20 +0200
committer <pavel@amd.(none)> Sun, 03 Jul 2005 23:34:20 +0200

 Documentation/power/swsusp.txt |    7 ++
 kernel/power/Kconfig           |   12 +++
 kernel/power/main.c            |    5 +
 kernel/power/swsusp.c          |  148 +++++++++++++++++++++++++++++++++++++++-
 4 files changed, 168 insertions(+), 4 deletions(-)

diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt
--- a/Documentation/power/swsusp.txt
+++ b/Documentation/power/swsusp.txt
@@ -30,6 +30,13 @@ echo shutdown > /sys/power/disk; echo di
 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
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -76,3 +76,15 @@ config SUSPEND_SMP
 	bool
 	depends on HOTPLUG_CPU && X86 && PM
 	default y
+
+config SWSUSP_ENCRYPT
+	bool "Encrypt suspend image"
+	depends on SOFTWARE_SUSPEND && CRYPTO=y && (CRYPTO_AES=y || CRYPTO_AES_586=y)
+	default ""
+	---help---
+	  To prevent data gathering from swap after resume you can encrypt
+	  the suspend image with a temporary key that is deleted on
+	  resume.
+
+	  Note that the temporary key is stored unencrypted on disk while the
+	  system is suspended.
diff --git a/kernel/power/main.c b/kernel/power/main.c
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -129,11 +129,12 @@ static void suspend_finish(suspend_state
 
 
 
-static char * pm_states[] = {
+static char * pm_states[PM_SUSPEND_MAX] = {
 	[PM_SUSPEND_STANDBY]	= "standby",
 	[PM_SUSPEND_MEM]	= "mem",
+#ifdef CONFIG_SOFTWARE_SUSPEND
 	[PM_SUSPEND_DISK]	= "disk",
-	NULL,
+#endif
 };
 
 
diff --git a/kernel/power/swsusp.c b/kernel/power/swsusp.c
--- a/kernel/power/swsusp.c
+++ b/kernel/power/swsusp.c
@@ -31,6 +31,9 @@
  * Alex Badea <vampire@go.ro>:
  * Fixed runaway init
  *
+ * Andreas Steinmetz <ast@domdv.de>:
+ * Added encrypted suspend option
+ *
  * More state savers are welcome. Especially for the scsi layer...
  *
  * For TODOs,FIXMEs also look in Documentation/power/swsusp.txt
@@ -72,6 +75,16 @@
 
 #include "power.h"
 
+#ifdef CONFIG_SWSUSP_ENCRYPT
+#include <linux/random.h>
+#include <linux/crypto.h>
+#include <asm/scatterlist.h>
+#endif
+
+#define CIPHER "aes"
+#define MAXKEY 32
+#define MAXIV  32
+
 /* References to section boundaries */
 extern const void __nosave_begin, __nosave_end;
 
@@ -102,7 +115,9 @@ static suspend_pagedir_t *pagedir_save;
 #define SWSUSP_SIG	"S1SUSPEND"
 
 static struct swsusp_header {
-	char reserved[PAGE_SIZE - 20 - sizeof(swp_entry_t)];
+	char reserved[PAGE_SIZE - 20 - MAXKEY - MAXIV - sizeof(swp_entry_t)];
+	u8 key[MAXKEY];
+	u8 iv[MAXIV];
 	swp_entry_t swsusp_info;
 	char	orig_sig[10];
 	char	sig[10];
@@ -110,6 +125,11 @@ static struct swsusp_header {
 
 static struct swsusp_info swsusp_info;
 
+#ifdef CONFIG_SWSUSP_ENCRYPT
+static u8 key[MAXKEY];
+static u8 iv[MAXIV];
+#endif
+
 /*
  * XXX: We try to keep some more pages free so that I/O operations succeed
  * without paging. Might this be more?
@@ -128,6 +148,60 @@ static struct swsusp_info swsusp_info;
 static unsigned short swapfile_used[MAX_SWAPFILES];
 static unsigned short root_swap;
 
+#ifdef CONFIG_SWSUSP_ENCRYPT
+static int crypto_init(int mode, struct crypto_tfm **tfm)
+{
+	char *modemsg;
+	int len;
+	int error = 0;
+
+	modemsg = mode ? "suspend not possible" : "resume not possible";
+
+	*tfm = crypto_alloc_tfm(CIPHER, CRYPTO_TFM_MODE_CBC);
+	if(!*tfm) {
+		printk(KERN_ERR "swsusp: no tfm, %s\n", modemsg);
+		error = -EINVAL;
+		goto out;
+	}
+
+	if(sizeof(key) < crypto_tfm_alg_min_keysize(*tfm)) {
+		printk(KERN_ERR "swsusp: key buffer too small, %s\n", modemsg);
+		error = -ENOKEY;
+		goto fail;
+	}
+
+	if (mode) {
+		get_random_bytes(key, MAXKEY);
+		get_random_bytes(iv, MAXIV);
+	}
+
+	len = crypto_tfm_alg_max_keysize(*tfm);
+	if (len > sizeof(key))
+		len = sizeof(key);
+
+	if (crypto_cipher_setkey(*tfm, key, len)) {
+		printk(KERN_ERR "swsusp: key setup failure, %s\n", modemsg);
+		error = -EKEYREJECTED;
+		goto fail;
+	}
+
+	len = crypto_tfm_alg_ivsize(*tfm);
+
+	if (sizeof(iv) < len) {
+		printk(KERN_ERR "swsusp: iv buffer too small, %s\n", modemsg);
+		error = -EOVERFLOW;
+		goto fail;
+	}
+
+	crypto_cipher_set_iv(*tfm, iv, len);
+
+	goto out;
+
+fail:	crypto_free_tfm(*tfm);
+out:	return error;
+}
+#endif
+
 static int mark_swapfiles(swp_entry_t prev)
 {
 	int error;
@@ -139,6 +213,10 @@ static int mark_swapfiles(swp_entry_t pr
 	    !memcmp("SWAPSPACE2",swsusp_header.sig, 10)) {
 		memcpy(swsusp_header.orig_sig,swsusp_header.sig, 10);
 		memcpy(swsusp_header.sig,SWSUSP_SIG, 10);
+#ifdef CONFIG_SWSUSP_ENCRYPT
+		memcpy(swsusp_header.key, key, MAXKEY);
+		memcpy(swsusp_header.iv, iv, MAXIV);
+#endif
 		swsusp_header.swsusp_info = prev;
 		error = rw_swap_page_sync(WRITE,
 					  swp_entry(root_swap, 0),
@@ -285,6 +363,19 @@ static int data_write(void)
 	int error = 0, i = 0;
 	unsigned int mod = nr_copy_pages / 100;
 	struct pbe *p;
+#ifdef CONFIG_SWSUSP_ENCRYPT
+	struct crypto_tfm *tfm;
+	struct scatterlist src, dst;
+
+	if ((error = crypto_init(1, &tfm)))
+		return error;
+
+	src.offset = 0;
+	src.length = PAGE_SIZE;
+	dst.page   = virt_to_page((void *)&swsusp_header);
+	dst.offset = 0;
+	dst.length = PAGE_SIZE;
+#endif
 
 	if (!mod)
 		mod = 1;
@@ -293,11 +384,22 @@ static int data_write(void)
 	for_each_pbe (p, pagedir_nosave) {
 		if (!(i%mod))
 			printk( "\b\b\b\b%3d%%", i / mod );
+#ifdef CONFIG_SWSUSP_ENCRYPT
+		src.page = virt_to_page(p->address);
+		error = crypto_cipher_encrypt(tfm, &dst, &src, PAGE_SIZE);
+		if (!error)
+			error = write_page((unsigned long)&swsusp_header,
+					&(p->swap_address));
+#else
 		if ((error = write_page(p->address, &(p->swap_address))))
 			return error;
+#endif
 		i++;
 	}
 	printk("\b\b\b\bdone\n");
+#ifdef CONFIG_SWSUSP_ENCRYPT
+	crypto_free_tfm(tfm);
+#endif
 	return error;
 }
 
@@ -399,6 +501,10 @@ static int write_suspend_image(void)
 	if ((error = close_swap()))
 		goto FreePagedir;
  Done:
+#ifdef CONFIG_SWSUSP_ENCRYPT
+	memset(key, 0, MAXKEY);
+	memset(iv, 0, MAXIV);
+#endif
 	return error;
  FreePagedir:
 	free_pagedir_entries();
@@ -1213,12 +1319,18 @@ static int check_sig(void)
 	if (!memcmp(SWSUSP_SIG, swsusp_header.sig, 10)) {
 		memcpy(swsusp_header.sig, swsusp_header.orig_sig, 10);
 
+#ifdef CONFIG_SWSUSP_ENCRYPT
+		memcpy(key, swsusp_header.key, MAXKEY);
+		memcpy(iv, swsusp_header.iv, MAXIV);
+		memset(swsusp_header.key, 0, MAXKEY);
+		memset(swsusp_header.iv, 0, MAXIV);
+#endif
 		/*
 		 * Reset swap signature now.
 		 */
 		error = bio_write_page(0, &swsusp_header);
 	} else { 
-		printk(KERN_ERR "swsusp: Suspend partition has wrong signature?\n");
+		printk(KERN_INFO "swsusp: Suspend partition does not contain suspend image.\n");
 		return -EINVAL;
 	}
 	if (!error)
@@ -1239,6 +1351,18 @@ static int data_read(struct pbe *pblist)
 	int error = 0;
 	int i = 0;
 	int mod = swsusp_info.image_pages / 100;
+#ifdef CONFIG_SWSUSP_ENCRYPT
+	struct crypto_tfm *tfm;
+	struct scatterlist src, dst;
+
+	if ((error = crypto_init(0, &tfm)))
+		return error;
+
+	src.offset = 0;
+	src.length = PAGE_SIZE;
+	dst.offset = 0;
+	dst.length = PAGE_SIZE;
+#endif
 
 	if (!mod)
 		mod = 1;
@@ -1252,12 +1376,27 @@ static int data_read(struct pbe *pblist)
 
 		error = bio_read_page(swp_offset(p->swap_address),
 				  (void *)p->address);
+#ifdef CONFIG_SWSUSP_ENCRYPT
+		if (!error) {
+			src.page = dst.page = virt_to_page((void *)p->address);
+			error = crypto_cipher_decrypt(tfm, &dst, &src,
+							PAGE_SIZE);
+		}
+		if (error) {
+			crypto_free_tfm(tfm);
+			return error;
+		}
+#else
 		if (error)
 			return error;
+#endif
 
 		i++;
 	}
 	printk("\b\b\b\bdone\n");
+#ifdef CONFIG_SWSUSP_ENCRYPT
+	crypto_free_tfm(tfm);
+#endif
 	return error;
 }
 
@@ -1398,6 +1537,11 @@ int swsusp_read(void)
 	error = read_suspend_image();
 	blkdev_put(resume_bdev);
 
+#ifdef CONFIG_SWSUSP_ENCRYPT
+	memset(key, 0, MAXKEY);
+	memset(iv, 0, MAXIV);
+#endif
+
 	if (!error)
 		pr_debug("swsusp: Reading resume file was successful\n");
 	else

-- 
teflon -- maybe it is a trademark, but it should not be.

Re: [swsusp] encrypt suspend data for easy wiping

[Andrew Morton]

Pavel Machek <pavel@ucw.cz> wrote:
>
> To prevent data gathering from swap after resume you can encrypt the
> suspend image with a temporary key that is deleted on resume. Note
> that the temporary key is stored unencrypted on disk while the system
> is suspended... still it means that saved data are wiped from disk
> during resume by simply overwritting the key.

hm, how useful is that?  swap can still contain sensitive userspace stuff.

Are there any plans to allow the user to type the key in on resume?

> +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.

Why not just `select' the needed symbols in Kconfig?  It makes
configuration much easier for the user.

> +	if(!*tfm) {
> +	if(sizeof(key) < crypto_tfm_alg_min_keysize(*tfm)) {
> +	if (mode) {

Coding style nit: please use a single space after `if'.

> +fail:	crypto_free_tfm(*tfm);
> +out:	return error;

We conventionally insert a newline directly after labels.

> +#ifdef CONFIG_SWSUSP_ENCRYPT
> +#ifdef CONFIG_SWSUSP_ENCRYPT
> +#ifdef CONFIG_SWSUSP_ENCRYPT
> +#ifdef CONFIG_SWSUSP_ENCRYPT
> +#ifdef CONFIG_SWSUSP_ENCRYPT
> +#ifdef CONFIG_SWSUSP_ENCRYPT
> +#ifdef CONFIG_SWSUSP_ENCRYPT
> +#ifdef CONFIG_SWSUSP_ENCRYPT
> +#ifdef CONFIG_SWSUSP_ENCRYPT

err, no.  Please find a way to reduce the ifdeffery.

Re: [swsusp] encrypt suspend data for easy wiping

[Pavel Machek]

Hi!

> > To prevent data gathering from swap after resume you can encrypt the
> > suspend image with a temporary key that is deleted on resume. Note
> > that the temporary key is stored unencrypted on disk while the system
> > is suspended... still it means that saved data are wiped from disk
> > during resume by simply overwritting the key.
> 
> hm, how useful is that?  swap can still contain sensitive userspace
> stuff.

At least userspace has chance to mark *really* sensitive stuff as
unswappable. Unfortunately that does not work against swsusp :-(.

[BTW... I was thinking about just generating random key on swapon, and
using it, so that data in swap is garbage after reboot; no userspace
changes needed. What do you think?]

> Are there any plans to allow the user to type the key in on resume?

Plans... ;-).

> > +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.
> 
> Why not just `select' the needed symbols in Kconfig?  It makes
> configuration much easier for the user.
> 
> > +	if(!*tfm) {
> > +	if(sizeof(key) < crypto_tfm_alg_min_keysize(*tfm)) {
> > +	if (mode) {
> 
> Coding style nit: please use a single space after `if'.
> 
> > +fail:	crypto_free_tfm(*tfm);
> > +out:	return error;
> 
> We conventionally insert a newline directly after labels.
> 
> > +#ifdef CONFIG_SWSUSP_ENCRYPT
> > +#ifdef CONFIG_SWSUSP_ENCRYPT
> > +#ifdef CONFIG_SWSUSP_ENCRYPT
> > +#ifdef CONFIG_SWSUSP_ENCRYPT
> > +#ifdef CONFIG_SWSUSP_ENCRYPT
> > +#ifdef CONFIG_SWSUSP_ENCRYPT
> > +#ifdef CONFIG_SWSUSP_ENCRYPT
> > +#ifdef CONFIG_SWSUSP_ENCRYPT
> > +#ifdef CONFIG_SWSUSP_ENCRYPT
> 
> err, no.  Please find a way to reduce the ifdeffery.

Andreas, these are yours.
								Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.

Re: [swsusp] encrypt suspend data for easy wiping

[Grzegorz Kulewski]

On Wed, 6 Jul 2005, Pavel Machek wrote:

> Hi!
>
>>> To prevent data gathering from swap after resume you can encrypt the
>>> suspend image with a temporary key that is deleted on resume. Note
>>> that the temporary key is stored unencrypted on disk while the system
>>> is suspended... still it means that saved data are wiped from disk
>>> during resume by simply overwritting the key.
>>
>> hm, how useful is that?  swap can still contain sensitive userspace
>> stuff.
>
> At least userspace has chance to mark *really* sensitive stuff as
> unswappable. Unfortunately that does not work against swsusp :-(.
>
> [BTW... I was thinking about just generating random key on swapon, and
> using it, so that data in swap is garbage after reboot; no userspace
> changes needed. What do you think?]

I (and many others) are doing it already in userspace. Don't you know 
about dm-crypt? I think the idea is described in its docs or wiki...

I also think that doing this in swapon is risky. Because nobody will 
guarantee you that random seed was restored before swapon and basing this
random key only on boot time and (rather deterministic) irqs at boot 
is risky IMHO.

In userspace, init scripts should make sure that random seed is restored 
before using /dev/random for anything.


Grzegorz Kulewski

Re: [swsusp] encrypt suspend data for easy wiping

[Pavel Machek]

Hi!

> >>>To prevent data gathering from swap after resume you can encrypt the
> >>>suspend image with a temporary key that is deleted on resume. Note
> >>>that the temporary key is stored unencrypted on disk while the system
> >>>is suspended... still it means that saved data are wiped from disk
> >>>during resume by simply overwritting the key.
> >>
> >>hm, how useful is that?  swap can still contain sensitive userspace
> >>stuff.
> >
> >At least userspace has chance to mark *really* sensitive stuff as
> >unswappable. Unfortunately that does not work against swsusp :-(.
> >
> >[BTW... I was thinking about just generating random key on swapon, and
> >using it, so that data in swap is garbage after reboot; no userspace
> >changes needed. What do you think?]
> 
> I (and many others) are doing it already in userspace. Don't you know 
> about dm-crypt? I think the idea is described in its docs or wiki...

I could not find anything in device-mapper/*; do you have pointer to
docs or wiki?
								Pavel 

-- 
teflon -- maybe it is a trademark, but it should not be.

Re: [swsusp] encrypt suspend data for easy wiping

[Grzegorz Kulewski]

On Thu, 7 Jul 2005, Pavel Machek wrote:

> Hi!

Hi!

>>>>> To prevent data gathering from swap after resume you can encrypt the
>>>>> suspend image with a temporary key that is deleted on resume. Note
>>>>> that the temporary key is stored unencrypted on disk while the system
>>>>> is suspended... still it means that saved data are wiped from disk
>>>>> during resume by simply overwritting the key.
>>>>
>>>> hm, how useful is that?  swap can still contain sensitive userspace
>>>> stuff.
>>>
>>> At least userspace has chance to mark *really* sensitive stuff as
>>> unswappable. Unfortunately that does not work against swsusp :-(.
>>>
>>> [BTW... I was thinking about just generating random key on swapon, and
>>> using it, so that data in swap is garbage after reboot; no userspace
>>> changes needed. What do you think?]
>>
>> I (and many others) are doing it already in userspace. Don't you know
>> about dm-crypt? I think the idea is described in its docs or wiki...
>
> I could not find anything in device-mapper/*; do you have pointer to
> docs or wiki?

Just type dm-crypt in google and the first match is 
http://www.saout.de/misc/dm-crypt/ (the second is its wiki). Then grep 
that page for 'swap' and you are done. :-)


Grzegorz Kulewski

Re: [swsusp] encrypt suspend data for easy wiping

[Andreas Steinmetz]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

Andrew Morton wrote:
> Pavel Machek <pavel@ucw.cz> wrote:
> 
>>To prevent data gathering from swap after resume you can encrypt the
>>suspend image with a temporary key that is deleted on resume. Note
>>that the temporary key is stored unencrypted on disk while the system
>>is suspended... still it means that saved data are wiped from disk
>>during resume by simply overwritting the key.
> 
[snip]
> err, no.  Please find a way to reduce the ifdeffery.

Andrew,
the attached patches are acked by Pavel and signed off by me. They apply
against 2.6.13-rc3 as well as 2.6.13-rc3-mm1 (with offsets) and are
tested against both kernels. Please consider for inclusion (Pavel
suggested that I could ask).

Note:
For 64 bit systems to work you need the following crypto fix for both
kernels stated above:
http://marc.theaimsgroup.com/?l=linux-kernel&m=112160294820624&w=2
-- 
Andreas Steinmetz                       SPAMmers use robotrap@domdv.de

[-- Attachment #2: swsusp-encrypt-config.diff --]
[-- Type: text/plain, Size: 756 bytes --]

--- linux-2.6.13-rc3.orig/kernel/power/Kconfig	2005-07-17 16:03:26.000000000 +0200
+++ linux-2.6.13-rc3/kernel/power/Kconfig	2005-07-17 10:40:48.000000000 +0200
@@ -72,6 +72,18 @@
 	  suspended image to. It will simply pick the first available swap 
 	  device.
 
+config SWSUSP_ENCRYPT
+	bool "Encrypt suspend image"
+	depends on SOFTWARE_SUSPEND && CRYPTO=y && (CRYPTO_AES=y || CRYPTO_AES_586=y || CRYPTO_AES_X86_64=y)
+	default ""
+	---help---
+	  To prevent data gathering from swap after resume you can encrypt
+	  the suspend image with a temporary key that is deleted on
+	  resume.
+
+	  Note that the temporary key is stored unencrypted on disk while the
+	  system is suspended.
+
 config SUSPEND_SMP
 	bool
 	depends on HOTPLUG_CPU && X86 && PM

[-- Attachment #3: swsusp-encrypt-core.diff --]
[-- Type: text/plain, Size: 6123 bytes --]

--- linux-2.6.13-rc3.orig/kernel/power/swsusp.c	2005-07-17 16:03:26.000000000 +0200
+++ linux-2.6.13-rc3/kernel/power/swsusp.c	2005-07-17 16:09:09.000000000 +0200
@@ -31,6 +31,9 @@
  * Alex Badea <vampire@go.ro>:
  * Fixed runaway init
  *
+ * Andreas Steinmetz <ast@domdv.de>:
+ * Added encrypted suspend option
+ *
  * More state savers are welcome. Especially for the scsi layer...
  *
  * For TODOs,FIXMEs also look in Documentation/power/swsusp.txt
@@ -71,8 +74,16 @@
 #include <asm/tlbflush.h>
 #include <asm/io.h>
 
+#include <linux/random.h>
+#include <linux/crypto.h>
+#include <asm/scatterlist.h>
+
 #include "power.h"
 
+#define CIPHER "aes"
+#define MAXKEY 32
+#define MAXIV  32
+
 /* References to section boundaries */
 extern const void __nosave_begin, __nosave_end;
 
@@ -103,7 +114,8 @@
 #define SWSUSP_SIG	"S1SUSPEND"
 
 static struct swsusp_header {
-	char reserved[PAGE_SIZE - 20 - sizeof(swp_entry_t)];
+	char reserved[PAGE_SIZE - 20 - MAXKEY - MAXIV - sizeof(swp_entry_t)];
+	u8 key_iv[MAXKEY+MAXIV];
 	swp_entry_t swsusp_info;
 	char	orig_sig[10];
 	char	sig[10];
@@ -129,6 +141,131 @@
 static unsigned short swapfile_used[MAX_SWAPFILES];
 static unsigned short root_swap;
 
+static int write_page(unsigned long addr, swp_entry_t * loc);
+static int bio_read_page(pgoff_t page_off, void * page);
+
+static u8 key_iv[MAXKEY+MAXIV];
+
+#ifdef CONFIG_SWSUSP_ENCRYPT
+
+static int crypto_init(int mode, void **mem)
+{
+	int error = 0;
+	int len;
+	char *modemsg;
+	struct crypto_tfm *tfm;
+
+	modemsg = mode ? "suspend not possible" : "resume not possible";
+
+	tfm = crypto_alloc_tfm(CIPHER, CRYPTO_TFM_MODE_CBC);
+	if(!tfm) {
+		printk(KERN_ERR "swsusp: no tfm, %s\n", modemsg);
+		error = -EINVAL;
+		goto out;
+	}
+
+	if(MAXKEY < crypto_tfm_alg_min_keysize(tfm)) {
+		printk(KERN_ERR "swsusp: key buffer too small, %s\n", modemsg);
+		error = -ENOKEY;
+		goto fail;
+	}
+
+	if (mode)
+		get_random_bytes(key_iv, MAXKEY+MAXIV);
+
+	len = crypto_tfm_alg_max_keysize(tfm);
+	if (len > MAXKEY)
+		len = MAXKEY;
+
+	if (crypto_cipher_setkey(tfm, key_iv, len)) {
+		printk(KERN_ERR "swsusp: key setup failure, %s\n", modemsg);
+		error = -EKEYREJECTED;
+		goto fail;
+	}
+
+	len = crypto_tfm_alg_ivsize(tfm);
+
+	if (MAXIV < len) {
+		printk(KERN_ERR "swsusp: iv buffer too small, %s\n", modemsg);
+		error = -EOVERFLOW;
+		goto fail;
+	}
+
+	crypto_cipher_set_iv(tfm, key_iv+MAXKEY, len);
+
+	*mem=(void *)tfm;
+
+	goto out;
+
+fail:	crypto_free_tfm(tfm);
+out:	return error;
+}
+
+static __inline__ void crypto_exit(void *mem)
+{
+	crypto_free_tfm((struct crypto_tfm *)mem);
+}
+
+static __inline__ int crypto_write(struct pbe *p, void *mem)
+{
+	int error = 0;
+	struct scatterlist src, dst;
+
+	src.page   = virt_to_page(p->address);
+	src.offset = 0;
+	src.length = PAGE_SIZE;
+	dst.page   = virt_to_page((void *)&swsusp_header);
+	dst.offset = 0;
+	dst.length = PAGE_SIZE;
+
+	error = crypto_cipher_encrypt((struct crypto_tfm *)mem, &dst, &src,
+					PAGE_SIZE);
+
+	if (!error)
+		error = write_page((unsigned long)&swsusp_header,
+				&(p->swap_address));
+	return error;
+}
+
+static __inline__ int crypto_read(struct pbe *p, void *mem)
+{
+	int error = 0;
+	struct scatterlist src, dst;
+
+	error = bio_read_page(swp_offset(p->swap_address), (void *)p->address);
+	if (!error) {
+		src.offset = 0;
+		src.length = PAGE_SIZE;
+		dst.offset = 0;
+		dst.length = PAGE_SIZE;
+		src.page = dst.page = virt_to_page((void *)p->address);
+
+		error = crypto_cipher_decrypt((struct crypto_tfm *)mem, &dst,
+						&src, PAGE_SIZE);
+	}
+	return error;
+}
+#else
+static __inline__ int crypto_init(int mode, void *mem)
+{
+	return 0;
+}
+
+static __inline__ void crypto_exit(void *mem)
+{
+}
+
+static __inline__ int crypto_write(struct pbe *p, void *mem)
+{
+	return write_page(p->address, &(p->swap_address));
+}
+
+static __inline__ int crypto_read(struct pbe *p, void *mem)
+{
+	return bio_read_page(swp_offset(p->swap_address), (void *)p->address);
+}
+#endif
+
 static int mark_swapfiles(swp_entry_t prev)
 {
 	int error;
@@ -140,6 +277,7 @@
 	    !memcmp("SWAPSPACE2",swsusp_header.sig, 10)) {
 		memcpy(swsusp_header.orig_sig,swsusp_header.sig, 10);
 		memcpy(swsusp_header.sig,SWSUSP_SIG, 10);
+		memcpy(swsusp_header.key_iv, key_iv, MAXKEY+MAXIV);
 		swsusp_header.swsusp_info = prev;
 		error = rw_swap_page_sync(WRITE,
 					  swp_entry(root_swap, 0),
@@ -286,6 +424,10 @@
 	int error = 0, i = 0;
 	unsigned int mod = nr_copy_pages / 100;
 	struct pbe *p;
+	void *tfm;
+
+	if ((error = crypto_init(1, &tfm)))
+		return error;
 
 	if (!mod)
 		mod = 1;
@@ -294,11 +436,14 @@
 	for_each_pbe (p, pagedir_nosave) {
 		if (!(i%mod))
 			printk( "\b\b\b\b%3d%%", i / mod );
-		if ((error = write_page(p->address, &(p->swap_address))))
+		if ((error = crypto_write(p, tfm))) {
+			crypto_exit(tfm);
 			return error;
+		}
 		i++;
 	}
 	printk("\b\b\b\bdone\n");
+	crypto_exit(tfm);
 	return error;
 }
 
@@ -400,6 +545,7 @@
 	if ((error = close_swap()))
 		goto FreePagedir;
  Done:
+	memset(key_iv, 0, MAXKEY+MAXIV);
 	return error;
  FreePagedir:
 	free_pagedir_entries();
@@ -1212,6 +1358,8 @@
 		return error;
 	if (!memcmp(SWSUSP_SIG, swsusp_header.sig, 10)) {
 		memcpy(swsusp_header.sig, swsusp_header.orig_sig, 10);
+		memcpy(key_iv, swsusp_header.key_iv, MAXKEY+MAXIV);
+		memset(swsusp_header.key_iv, 0, MAXKEY+MAXIV);
 
 		/*
 		 * Reset swap signature now.
@@ -1239,6 +1387,10 @@
 	int error = 0;
 	int i = 0;
 	int mod = swsusp_info.image_pages / 100;
+	void *tfm;
+
+	if ((error = crypto_init(0, &tfm)))
+		return error;
 
 	if (!mod)
 		mod = 1;
@@ -1250,14 +1402,15 @@
 		if (!(i % mod))
 			printk("\b\b\b\b%3d%%", i / mod);
 
-		error = bio_read_page(swp_offset(p->swap_address),
-				  (void *)p->address);
-		if (error)
+		if ((error = crypto_read(p, tfm))) {
+			crypto_exit(tfm);
 			return error;
+		}
 
 		i++;
 	}
 	printk("\b\b\b\bdone\n");
+	crypto_exit(tfm);
 	return error;
 }
 
@@ -1385,6 +1538,7 @@
 
 	error = read_suspend_image();
 	blkdev_put(resume_bdev);
+	memset(key_iv, 0, MAXKEY+MAXIV);
 
 	if (!error)
 		pr_debug("swsusp: Reading resume file was successful\n");

Re: [swsusp] encrypt suspend data for easy wiping

[Andrew Morton]

Andreas Steinmetz <ast@domdv.de> wrote:
>
> the attached patches are acked by Pavel and signed off by me

OK, well I queued this up, without a changelog.  Because you didn't send
one.  Please do so.  As it adds a new feature, quite a bit of info is
relevant.

It should include a description of what the patch tries to do, and how it
does it.  It should include a description of any known shortcomings.  If
any user configuration is needed then that should be placed somewhere under
Documentation/

Take a look at how other people document their feature additions and you'll
get the idea.

Please don't send multiple patches per email.  In this case I did the
handwork and put both diffs into the same patch.

Personally, I don't like this:

+config SWSUSP_ENCRYPT
+	bool "Encrypt suspend image"
+	depends on SOFTWARE_SUSPEND && CRYPTO=y && (CRYPTO_AES=y || CRYPTO_AES_586=y || CRYPTO_AES_X86_64=y)

This requires the user to hunt around in config until all the right options
are enabled to permit SWSUSP_ENCRYPT to appear in config.  That can be
quite frustrating and is very poor UI.

For a top-level feature such as this it is much better to always offer the
feature to the user and to then use `select' to turn on all the
infrastructure bits which the user will need.  Make the computer do the
work rather than the user.

Yes, it might be a bit tricky in this case because you have a dependency on
one of the AES encryption types, but it would be good if you can come up
with something which doesn't force the user into a game of hide-and-seek.

Re: [swsusp] encrypt suspend data for easy wiping

[Matt Mackall]

On Mon, Jul 25, 2005 at 08:10:36PM -0700, Andrew Morton wrote:
> Andreas Steinmetz <ast@domdv.de> wrote:
> >
> > the attached patches are acked by Pavel and signed off by me
> 
> OK, well I queued this up, without a changelog.  Because you didn't send
> one.  Please do so.  As it adds a new feature, quite a bit of info is
> relevant.

I don't like this patch. It reinvents a fair amount of dm_crypt and
cryptoloop but badly. 

Further, the model of security it's using is silly. In case anyone
hasn't noticed, it stores the password on disk in the clear. This is
so it can erase it after resume and thereby make recovery of the
suspend image hard.

But laptops get stolen while they're suspended, not while they're up
and running. And if your box is up and running and an attacker gains
access, the contents of your suspend partition are the least of your
worries. It makes no sense to expend any effort defending against this
case, especially as it's liable to become a barrier to doing this
right, namely with real dm_crypt encrypted swap.
 
At the very least, this should be renamed SWSUSP_QUICK_WIPE and any
mention of encryption should be taken out of the description so users
don't mistakenly think it provides any sort of useful protection.

-- 
Mathematics is the supreme nostalgia of our time.

Re: [swsusp] encrypt suspend data for easy wiping

[Pavel Machek]

Hi!

> > > the attached patches are acked by Pavel and signed off by me
> > 
> > OK, well I queued this up, without a changelog.  Because you didn't send
> > one.  Please do so.  As it adds a new feature, quite a bit of info is
> > relevant.
> 
> I don't like this patch. It reinvents a fair amount of dm_crypt and
> cryptoloop but badly. 
> 
> Further, the model of security it's using is silly. In case anyone
> hasn't noticed, it stores the password on disk in the clear. This is
> so it can erase it after resume and thereby make recovery of the
> suspend image hard.
> 
> But laptops get stolen while they're suspended, not while they're up
> and running. And if your box is up and running and an attacker gains
> access, the contents of your suspend partition are the least of your
> worries. It makes no sense to expend any effort defending against this
> case, especially as it's liable to become a barrier to doing this
> right, namely with real dm_crypt encrypted swap.

Well, "how long are my keys going to stay in swap after
swsusp"... that's pretty scary.

To prevent "stolen while suspended" case... you'd either need to enter
password both during suspend and during resume, or you'd need
asymetric crypto... Rather heavy.

> At the very least, this should be renamed SWSUSP_QUICK_WIPE and any
> mention of encryption should be taken out of the description so users
> don't mistakenly think it provides any sort of useful protection.

SWSUSP_WIPE seems like a better name, right.

							Pavel

-- 
teflon -- maybe it is a trademark, but it should not be.

Re: [swsusp] encrypt suspend data for easy wiping

[Pavel Machek]

Hi!

> > > the attached patches are acked by Pavel and signed off by me
> > 
> > OK, well I queued this up, without a changelog.  Because you didn't send
> > one.  Please do so.  As it adds a new feature, quite a bit of info is
> > relevant.
> 
> I don't like this patch. It reinvents a fair amount of dm_crypt and
> cryptoloop but badly. 
> 
> Further, the model of security it's using is silly. In case anyone
> hasn't noticed, it stores the password on disk in the clear. This is
> so it can erase it after resume and thereby make recovery of the
> suspend image hard.
> 
> But laptops get stolen while they're suspended, not while they're up
> and running. And if your box is up and running and an attacker gains
> access, the contents of your suspend partition are the least of your
> worries. It makes no sense to expend any effort defending against this
> case, especially as it's liable to become a barrier to doing this
> right, namely with real dm_crypt encrypted swap.

I do not see why it should be liability. Even if you "properly"
encrypt the swap, you'll want to wipe old data after resume.

If you take the random key (currently used), and encrypt with public
key; then ask for private key on reboot; it should do the trick.
								Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.

Re: [swsusp] encrypt suspend data for easy wiping

[Matt Mackall]

On Wed, Jul 27, 2005 at 12:14:46AM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > the attached patches are acked by Pavel and signed off by me
> > > 
> > > OK, well I queued this up, without a changelog.  Because you didn't send
> > > one.  Please do so.  As it adds a new feature, quite a bit of info is
> > > relevant.
> > 
> > I don't like this patch. It reinvents a fair amount of dm_crypt and
> > cryptoloop but badly. 
> > 
> > Further, the model of security it's using is silly. In case anyone
> > hasn't noticed, it stores the password on disk in the clear. This is
> > so it can erase it after resume and thereby make recovery of the
> > suspend image hard.
> > 
> > But laptops get stolen while they're suspended, not while they're up
> > and running. And if your box is up and running and an attacker gains
> > access, the contents of your suspend partition are the least of your
> > worries. It makes no sense to expend any effort defending against this
> > case, especially as it's liable to become a barrier to doing this
> > right, namely with real dm_crypt encrypted swap.
> 
> Well, "how long are my keys going to stay in swap after
> swsusp"... that's pretty scary.

Either they're likely in RAM _anyway_ and are thus already trivially
accessible to the attacker (for things like dm_crypt or IPSEC or
ssh-agent), or the application took care to zero them out, or the
application has a security bug.

There are about 4 attack cases, in order of likelihood:

1) An attacker steals your suspended laptop. He has access to all your
suspended data. This patch gets us exactly nothing.

2) An attacker breaks into your machine remotely while you're using
it. He has access to all your RAM, which if you're actually using it,
very likely including the same IPSEC, dm_crypt, and ssh-agent keys as
are saved on suspend. Further, he can trivially capture your
keystrokes and thus capture any keys you use from that point forward.
This patch gets us very close to nothing.

3) An attacker steals your unsuspended laptop. He has access to all
your RAM, which in all likelihood includes your IPSEC, dm_crypt, and
ssh-agent keys. Odds are good that he invokes swsusp by closing the
laptop. This patch gets us very close to nothing.

4) You suspend your laptop between typing your GPG key password and
hitting enter, thus leaving your password in memory when it would
otherwise be cleared. Then you resume your laptop and hit enter, thus
clearing the password from RAM but leaving it on the suspend
partition. Then an attacker steals your machine (without re-suspending
it!) and manages to recover the swsusp image which contains the
password. But with this patch, he's foiled because the password is
encrypted and the key's been erased! He's got all your other data
though, including all the aforementioned long-lived keys.

The right fix for case 1 is dm_crypt with a password prompt. The right
fix for 2 is beyond the scope of this email, but probably begins with
the letters s and e. The fix for 1 goes a long way towards fixing 3 as
well, provided the attacker suspends your machine. And I claim that
anyone who is paranoid enough to actually care about corner cases like
4 should damn well care about case 1 too, and should be more than
willing to type a password on resume, otherwise they're just fooling
themselves.

Together with the fact that this reimplements dm_crypt functionality
with an unreviewed and cryptographically naive replacement, I don't
think this patch makes any sense at all.

-- 
Mathematics is the supreme nostalgia of our time.

Re: [swsusp] encrypt suspend data for easy wiping

[Pavel Machek]

Hi!

> > Well, "how long are my keys going to stay in swap after
> > swsusp"... that's pretty scary.
> 
> Either they're likely in RAM _anyway_ and are thus already trivially
> accessible to the attacker (for things like dm_crypt or IPSEC or
> ssh-agent), or the application took care to zero them out, or the
> application has a security bug.
> 
> There are about 4 attack cases, in order of likelihood:
> 
> 1) An attacker steals your suspended laptop. He has access to all your
> suspended data. This patch gets us exactly nothing.

Wrong. Without this Andreas' patch, he'll get access to your
half-a-year-old GPG passphrases, too.

> 2) An attacker breaks into your machine remotely while you're using
> it. He has access to all your RAM, which if you're actually using it,
> very likely including the same IPSEC, dm_crypt, and ssh-agent keys as
> are saved on suspend. Further, he can trivially capture your
> keystrokes and thus capture any keys you use from that point forward.
> This patch gets us very close to nothing.
> 
> 3) An attacker steals your unsuspended laptop. He has access to all
> your RAM, which in all likelihood includes your IPSEC, dm_crypt, and
> ssh-agent keys. Odds are good that he invokes swsusp by closing the
> laptop. This patch gets us very close to nothing.
> 
> 4) You suspend your laptop between typing your GPG key password and
> hitting enter, thus leaving your password in memory when it would
> otherwise be cleared. Then you resume your laptop and hit enter, thus
> clearing the password from RAM but leaving it on the suspend
> partition. Then an attacker steals your machine (without re-suspending
> it!) and manages to recover the swsusp image which contains the

Why without resuspending it? Position of critical data in swap is
pretty much random. 

What I'm worried is: attacker steals your laptop after you were using
swsusp for half a year. Now your swap partition contains random pieces
of GPG keys you were using for last half a year. That's bad.

Current GPG keys can be found in RAM; unfortunately your swap
partition can contain current and old GPG keys that were never
supposed to be on disk. That's bad and I think we can agree on
that. Andreas's patch solves it; if it was not supposed to go on disk,
it will be erased after you resume. You can not do much better.

It is equivalent of clearing swsusp data from swap after resume, just
implemented somewhat clever... 
								Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.

Re: [swsusp] encrypt suspend data for easy wiping

[Matt Mackall]

On Wed, Jul 27, 2005 at 01:12:49AM +0200, Pavel Machek wrote:
> Hi!
> 
> > > Well, "how long are my keys going to stay in swap after
> > > swsusp"... that's pretty scary.
> > 
> > Either they're likely in RAM _anyway_ and are thus already trivially
> > accessible to the attacker (for things like dm_crypt or IPSEC or
> > ssh-agent), or the application took care to zero them out, or the
> > application has a security bug.
> > 
> > There are about 4 attack cases, in order of likelihood:
> > 
> > 1) An attacker steals your suspended laptop. He has access to all your
> > suspended data. This patch gets us exactly nothing.
> 
> Wrong. Without this Andreas' patch, he'll get access to your
> half-a-year-old GPG passphrases, too.

Ok, I'll revise that to "very close to nothing". See below.
 
> > 2) An attacker breaks into your machine remotely while you're using
> > it. He has access to all your RAM, which if you're actually using it,
> > very likely including the same IPSEC, dm_crypt, and ssh-agent keys as
> > are saved on suspend. Further, he can trivially capture your
> > keystrokes and thus capture any keys you use from that point forward.
> > This patch gets us very close to nothing.
> > 
> > 3) An attacker steals your unsuspended laptop. He has access to all
> > your RAM, which in all likelihood includes your IPSEC, dm_crypt, and
> > ssh-agent keys. Odds are good that he invokes swsusp by closing the
> > laptop. This patch gets us very close to nothing.
> > 
> > 4) You suspend your laptop between typing your GPG key password and
> > hitting enter, thus leaving your password in memory when it would
> > otherwise be cleared. Then you resume your laptop and hit enter, thus
> > clearing the password from RAM but leaving it on the suspend
> > partition. Then an attacker steals your machine (without re-suspending
> > it!) and manages to recover the swsusp image which contains the
> 
> Why without resuspending it? Position of critical data in swap is
> pretty much random. 

Typical swap partition sizes are about the same as RAM sizes. So the
odds of any given thing in a previous suspend getting overwritten by
the next one are high.

> What I'm worried is: attacker steals your laptop after you were using
> swsusp for half a year. Now your swap partition contains random pieces
> of GPG keys you were using for last half a year. That's bad.

And it's incredibly unlikely. Suspending while a supposedly
short-lived key is in RAM should be rare. Surviving on disk after half
a year of swapping and suspending should be negligible probability.

It's not worth even thinking about when we have real suspended laptops
getting stolen every day in REAL LIFE. Anyone who cares about your
highly contrived case also cares about 1000 times more about the real
life case of the stolen laptop. Otherwise they're fooling themselves.

This code is bad. It attacks a very rare problem, gives its users (and
apparently its authors) a false sense of security, reimplements
dm_crypt functionality apparently without much attention to the
subtleties of block device encryption and without serious review, and
it stands in the way of doing things right.

If we're going to encrypt the suspend image, let's do it right. Let's
cover the real life cases and reuse code that's intended for this
purpose.

-- 
Mathematics is the supreme nostalgia of our time.

Re: [swsusp] encrypt suspend data for easy wiping

[Pavel Machek]

Hi!

> > > 2) An attacker breaks into your machine remotely while you're using
> > > it. He has access to all your RAM, which if you're actually using it,
> > > very likely including the same IPSEC, dm_crypt, and ssh-agent keys as
> > > are saved on suspend. Further, he can trivially capture your
> > > keystrokes and thus capture any keys you use from that point forward.
> > > This patch gets us very close to nothing.
> > > 
> > > 3) An attacker steals your unsuspended laptop. He has access to all
> > > your RAM, which in all likelihood includes your IPSEC, dm_crypt, and
> > > ssh-agent keys. Odds are good that he invokes swsusp by closing the
> > > laptop. This patch gets us very close to nothing.
> > > 
> > > 4) You suspend your laptop between typing your GPG key password and
> > > hitting enter, thus leaving your password in memory when it would
> > > otherwise be cleared. Then you resume your laptop and hit enter, thus
> > > clearing the password from RAM but leaving it on the suspend
> > > partition. Then an attacker steals your machine (without re-suspending
> > > it!) and manages to recover the swsusp image which contains the
> > 
> > Why without resuspending it? Position of critical data in swap is
> > pretty much random. 
> 
> Typical swap partition sizes are about the same as RAM sizes. So the
> odds of any given thing in a previous suspend getting overwritten by
> the next one are high.

Well, if you suspend with 100MB of RAM used, then keep suspending half
a year with only 50MB of RAM used, you'll have that half-year-old data
in there.

> > What I'm worried is: attacker steals your laptop after you were using
> > swsusp for half a year. Now your swap partition contains random pieces
> > of GPG keys you were using for last half a year. That's bad.
> 
> And it's incredibly unlikely. Suspending while a supposedly
> short-lived key is in RAM should be rare. Surviving on disk after half
> a year of swapping and suspending should be negligible probability.

Disagreed.

> It's not worth even thinking about when we have real suspended laptops
> getting stolen every day in REAL LIFE. Anyone who cares about your
> highly contrived case also cares about 1000 times more about the real
> life case of the stolen laptop. Otherwise they're fooling themselves.
> 
> This code is bad. It attacks a very rare problem, gives its users (and
> apparently its authors) a false sense of security, reimplements
> dm_crypt functionality apparently without much attention to the
> subtleties of block device encryption and without serious review, and
> it stands in the way of doing things right.

Think about current code as really quick disk wiping method. Now, if
you feel that we are giving false sense of security... we should
not. Perhaps option should be renamed to CONFIG_SWSUSP_WIPE. Patches
would certainly be accepted and I believe Andreas is going to cook
some when he gets back online :-). I'd like to keep it there, because
it enables us to do it properly in future. Contrary to what you think,
I believe this is going to be part of a solution.
								Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.

Re: [swsusp] encrypt suspend data for easy wiping

[Andreas Steinmetz]

Pavel Machek wrote:
> Hi!
> 
> 
>>>>2) An attacker breaks into your machine remotely while you're using
>>>>it. He has access to all your RAM, which if you're actually using it,
>>>>very likely including the same IPSEC, dm_crypt, and ssh-agent keys as
>>>>are saved on suspend. Further, he can trivially capture your
>>>>keystrokes and thus capture any keys you use from that point forward.
>>>>This patch gets us very close to nothing.
>>>>
>>>>3) An attacker steals your unsuspended laptop. He has access to all
>>>>your RAM, which in all likelihood includes your IPSEC, dm_crypt, and
>>>>ssh-agent keys. Odds are good that he invokes swsusp by closing the
>>>>laptop. This patch gets us very close to nothing.
>>>>
>>>>4) You suspend your laptop between typing your GPG key password and
>>>>hitting enter, thus leaving your password in memory when it would
>>>>otherwise be cleared. Then you resume your laptop and hit enter, thus
>>>>clearing the password from RAM but leaving it on the suspend
>>>>partition. Then an attacker steals your machine (without re-suspending
>>>>it!) and manages to recover the swsusp image which contains the
>>>
>>>Why without resuspending it? Position of critical data in swap is
>>>pretty much random. 
>>
>>Typical swap partition sizes are about the same as RAM sizes. So the
>>odds of any given thing in a previous suspend getting overwritten by
>>the next one are high.
> 
> 
> Well, if you suspend with 100MB of RAM used, then keep suspending half
> a year with only 50MB of RAM used, you'll have that half-year-old data
> in there.
> 
> 
>>>What I'm worried is: attacker steals your laptop after you were using
>>>swsusp for half a year. Now your swap partition contains random pieces
>>>of GPG keys you were using for last half a year. That's bad.
>>
>>And it's incredibly unlikely. Suspending while a supposedly
>>short-lived key is in RAM should be rare. Surviving on disk after half
>>a year of swapping and suspending should be negligible probability.
> 
> 
> Disagreed.
> 
> 
>>It's not worth even thinking about when we have real suspended laptops
>>getting stolen every day in REAL LIFE. Anyone who cares about your
>>highly contrived case also cares about 1000 times more about the real
>>life case of the stolen laptop. Otherwise they're fooling themselves.
>>
>>This code is bad. It attacks a very rare problem, gives its users (and
>>apparently its authors) a false sense of security, reimplements
>>dm_crypt functionality apparently without much attention to the
>>subtleties of block device encryption and without serious review, and
>>it stands in the way of doing things right.
> 
> 
> Think about current code as really quick disk wiping method. Now, if
> you feel that we are giving false sense of security... we should
> not. Perhaps option should be renamed to CONFIG_SWSUSP_WIPE. Patches
> would certainly be accepted and I believe Andreas is going to cook
> some when he gets back online :-). I'd like to keep it there, because
> it enables us to do it properly in future. Contrary to what you think,
> I believe this is going to be part of a solution.

Matt,
this is really supposed to do wiping, nothing else. Maybe the reference
to crypto may confuse a bit, but then crypto is the best way to wipe.
The documentation I did send to Pavel some time ago for swsusp.txt does
contain a big fat warning about that and starts with:

----------
Q: What is this 'Encrypt suspend image' for?

A: First of all: it is not a replacement for dm-crypt encrypted swap.
It cannot protect your computer while it is suspended. Instead it does
protect from leaking sensitive data after resume from suspend.
----------

I'm still dreaming of using dm-crypt for encrypted swap on the one hand
and wiping on resume from suspend on the other working together which
would mean:

You have an initrd that either prompts for a key or retrieves a key from
an attached hardware device (pcmcia, usb, ...). The key is used for
dmsetup to enable the encrypted swap partition. swsusp then resumes from
the encrypted swap partition and wipes the suspend image.

Unfortunately, as of 2.6.13rc3 I don't see any chance for this to work
(excerpt from init/main.c):

        do_basic_setup();

        if (sys_access((const char __user *) "/init", 0) == 0)
                execute_command = "/init";
        else
                prepare_namespace();

do_basic_setup calls do_initcalls and swsusp is using late_initcall().
prepare_namespace calls initrd_load and friends. So there is currently
no chance to use an initrd to setup any crypto key.

This is really the missing link here.
-- 
Andreas Steinmetz                       SPAMmers use robotrap@domdv.de