[PATCH] zero disk pages used by swsusp on resume

[PATCH] zero disk pages used by swsusp on resume

[Andreas Steinmetz]

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

It may not be desireable to leave swsusp saved pages on disk after
resume as they may contain sensitive data that was never intended to be
stored on disk in an way (e.g. in-kernel dm-crypt keys, mlocked pages).

The attached simple patch against 2.6.11.2 should fix this by zeroing
the swap pages after reading them.

The patch is by no means perfect. Especially it isn't invoked on error
conditions. However it seems to work during regular operation.

Note that it is not possible to do this from userspace in a performant
way, one has to zero the whole swap partition used for swsusp to achive
a similar effect which quite often means clearing 2GB instead of about a
few 100MB. The difference in speed and power consumption is important
especially for laptops when resuming on battery. The userspace method
also allows for a window in which at least some of the data may still be
read.
-- 
Andreas Steinmetz                       SPAMmers use robotrap@domdv.de

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

--- linux-2.6.11.2/kernel/power/swsusp.c.ast	2005-04-10 14:08:55.000000000 +0200
+++ linux-2.6.11.2/kernel/power/swsusp.c	2005-04-10 14:24:10.000000000 +0200
@@ -112,6 +112,10 @@
 
 static struct swsusp_info swsusp_info;
 
+static struct swsusp_clear {
+	char zero[PAGE_SIZE];
+} __attribute__((packed, aligned(PAGE_SIZE))) swsusp_clear __initdata;
+
 /*
  * XXX: We try to keep some more pages free so that I/O operations succeed
  * without paging. Might this be more?
@@ -1169,6 +1173,29 @@
 
 }
 
+static int __init data_clear(void)
+{
+	struct pbe * p;
+	int error = 0;
+	int i;
+	int mod = nr_copy_pages / 100;
+
+	if (!mod)
+		mod = 1;
+
+	memset(&swsusp_clear, 0, sizeof(swsusp_clear));
+
+	printk( "Clearing disk data (%d pages):     ", nr_copy_pages );
+	for(i = 0, p = pagedir_nosave; i < nr_copy_pages && !error; i++, p++) {
+		if (!(i%mod))
+			printk( "\b\b\b\b%3d%%", i / mod );
+		error = bio_write_page(swp_offset(p->swap_address),
+				  (void *)&swsusp_clear);
+	}
+	printk(" %d done.\n",i);
+	return error;
+}
+
 extern dev_t __init name_to_dev_t(const char *line);
 
 static int __init read_pagedir(void)
@@ -1208,6 +1235,8 @@
 		return error;
 	if ((error = data_read()))
 		free_pages((unsigned long)pagedir_nosave, pagedir_order);
+	else
+		data_clear();
 	return error;
 }
 

Re: [PATCH] zero disk pages used by swsusp on resume

[Oliver Neukum]

Am Sonntag, 10. April 2005 15:13 schrieb Andreas Steinmetz:
> It may not be desireable to leave swsusp saved pages on disk after
> resume as they may contain sensitive data that was never intended to be
> stored on disk in an way (e.g. in-kernel dm-crypt keys, mlocked pages).
> 
> The attached simple patch against 2.6.11.2 should fix this by zeroing
> the swap pages after reading them.

What is the point in doing so after they've rested on the disk for ages?
If you want secure swsusp you need to encrypt the image.

	Regards
		Oliver

Re: [PATCH] zero disk pages used by swsusp on resume

[Andreas Steinmetz]

Oliver Neukum wrote:
> What is the point in doing so after they've rested on the disk for ages?

The point is not physical access to the disk but data gathering after
resume or reboot.
-- 
Andreas Steinmetz                       SPAMmers use robotrap@domdv.de

Re: [PATCH] zero disk pages used by swsusp on resume

[Oliver Neukum]

Am Sonntag, 10. April 2005 21:29 schrieb Andreas Steinmetz:
> Oliver Neukum wrote:
> > What is the point in doing so after they've rested on the disk for ages?
> 
> The point is not physical access to the disk but data gathering after
> resume or reboot.

After resume or reboot normal access control mechanisms will work
again. Those who can read a swap partition under normal circumstances
can also read /dev/kmem. It seems to me like you are putting an extra
lock on a window on the third floor while leaving the front door open.

	Regards
		Oliver

Re: [PATCH] zero disk pages used by swsusp on resume

[Pavel Machek]

Hi!

> > Oliver Neukum wrote:
> > > What is the point in doing so after they've rested on the disk for ages?
> > 
> > The point is not physical access to the disk but data gathering after
> > resume or reboot.
> 
> After resume or reboot normal access control mechanisms will work
> again. Those who can read a swap partition under normal circumstances
> can also read /dev/kmem. It seems to me like you are putting an extra
> lock on a window on the third floor while leaving the front door open.

Andreas is right, his patches are needed.

Currently, if your laptop is stolen after resume, they can still data
in swsusp image.

Zeroing the swsusp pages helps a lot here, because at least they are
not getting swsusp image data without heavy tools. [Or think root
compromise month after you used swsusp.]

Encrypting swsusp image is of course even better, because you don't
have to write large ammounts of zeros to your disks during resume ;-).

								Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.

Re: [PATCH] zero disk pages used by swsusp on resume

[Elladan]

On Sun, Apr 10, 2005 at 10:14:55PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > Oliver Neukum wrote:
> > > > What is the point in doing so after they've rested on the disk for ages?
> > > 
> > > The point is not physical access to the disk but data gathering after
> > > resume or reboot.
> > 
> > After resume or reboot normal access control mechanisms will work
> > again. Those who can read a swap partition under normal circumstances
> > can also read /dev/kmem. It seems to me like you are putting an extra
> > lock on a window on the third floor while leaving the front door open.
> 
> Andreas is right, his patches are needed.
> 
> Currently, if your laptop is stolen after resume, they can still data
> in swsusp image.
> 
> Zeroing the swsusp pages helps a lot here, because at least they are
> not getting swsusp image data without heavy tools. [Or think root
> compromise month after you used swsusp.]
> 
> Encrypting swsusp image is of course even better, because you don't
> have to write large ammounts of zeros to your disks during resume ;-).

How does zeroing help if they steal the laptop?  The data is there, they
can just pull the hard disk out and mirror it before they boot.

The only way to improve security here is to encrypt it.  Zeroing will
help some if they compromise root later, but I doubt that's really worth
it considering you're screwed after a root compromise anyway.

-J

Re: [PATCH] zero disk pages used by swsusp on resume

[Pavel Machek]

Hi!

> > Encrypting swsusp image is of course even better, because you don't
> > have to write large ammounts of zeros to your disks during resume ;-).
> 
> How does zeroing help if they steal the laptop?  The data is there, they
> can just pull the hard disk out and mirror it before they boot.
> 
> The only way to improve security here is to encrypt it.  Zeroing will
> help some if they compromise root later, but I doubt that's really worth
> it considering you're screwed after a root compromise anyway.

Yes, it helps. It also helps if they steal your laptop later. And we
are switching to encryption, anyway, because it should be faster.
								Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.

Re: [PATCH] zero disk pages used by swsusp on resume

[Stefan Seyfried]

Pavel Machek wrote:

> Encrypting swsusp image is of course even better, because you don't
> have to write large ammounts of zeros to your disks during resume ;-).

and while we are at it: compressing before encryption will also reduce
the amount of data you have to write during suspend... ;-)

> 								Pavel

Stefan

Re: [PATCH] zero disk pages used by swsusp on resume

[Oliver Neukum]

Am Sonntag, 10. April 2005 22:14 schrieb Pavel Machek:
> Hi!
> 
> > > Oliver Neukum wrote:
> > > > What is the point in doing so after they've rested on the disk for ages?
> > > 
> > > The point is not physical access to the disk but data gathering after
> > > resume or reboot.
> > 
> > After resume or reboot normal access control mechanisms will work
> > again. Those who can read a swap partition under normal circumstances
> > can also read /dev/kmem. It seems to me like you are putting an extra
> > lock on a window on the third floor while leaving the front door open.
> 
> Andreas is right, his patches are needed.
> 
> Currently, if your laptop is stolen after resume, they can still data
> in swsusp image.
> 
> Zeroing the swsusp pages helps a lot here, because at least they are
> not getting swsusp image data without heavy tools. [Or think root
> compromise month after you used swsusp.]
> 
> Encrypting swsusp image is of course even better, because you don't
> have to write large ammounts of zeros to your disks during resume ;-).

Not only is it better, it completely supercedes wiping the image.
Your laptop being stolen after resume is very much a corner case.
You suspend your laptop while you are not around, don't you?

Additionally it helps only if you cannot trigger another swsusp, eg by
running dry the batteries.

	Regards
		Oliver

Re: [PATCH] zero disk pages used by swsusp on resume

[Rafael J. Wysocki]

Hi,

On Monday, 11 of April 2005 12:37, Oliver Neukum wrote:
> Am Sonntag, 10. April 2005 22:14 schrieb Pavel Machek:
> > Hi!
> > 
> > > > Oliver Neukum wrote:
> > > > > What is the point in doing so after they've rested on the disk for ages?
> > > > 
> > > > The point is not physical access to the disk but data gathering after
> > > > resume or reboot.
> > > 
> > > After resume or reboot normal access control mechanisms will work
> > > again. Those who can read a swap partition under normal circumstances
> > > can also read /dev/kmem. It seems to me like you are putting an extra
> > > lock on a window on the third floor while leaving the front door open.
> > 
> > Andreas is right, his patches are needed.
> > 
> > Currently, if your laptop is stolen after resume, they can still data
> > in swsusp image.
> > 
> > Zeroing the swsusp pages helps a lot here, because at least they are
> > not getting swsusp image data without heavy tools. [Or think root
> > compromise month after you used swsusp.]
> > 
> > Encrypting swsusp image is of course even better, because you don't
> > have to write large ammounts of zeros to your disks during resume ;-).
> 
> Not only is it better, it completely supercedes wiping the image.
> Your laptop being stolen after resume is very much a corner case.
> You suspend your laptop while you are not around, don't you?

Not necessarily.  Some people use suspend instead of shutdown. :-)

Greets,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: [PATCH] zero disk pages used by swsusp on resume

[Andreas Steinmetz]

Rafael J. Wysocki wrote:
> Hi,
> 
> On Monday, 11 of April 2005 12:37, Oliver Neukum wrote:
> 
>>Am Sonntag, 10. April 2005 22:14 schrieb Pavel Machek:
>>
>>>Hi!
>>>
>>>
>>>>>Oliver Neukum wrote:
>>>>>
>>>>>>What is the point in doing so after they've rested on the disk for ages?
>>>>>
>>>>>The point is not physical access to the disk but data gathering after
>>>>>resume or reboot.
>>>>
>>>>After resume or reboot normal access control mechanisms will work
>>>>again. Those who can read a swap partition under normal circumstances
>>>>can also read /dev/kmem. It seems to me like you are putting an extra
>>>>lock on a window on the third floor while leaving the front door open.
>>>
>>>Andreas is right, his patches are needed.
>>>
>>>Currently, if your laptop is stolen after resume, they can still data
>>>in swsusp image.
>>>
>>>Zeroing the swsusp pages helps a lot here, because at least they are
>>>not getting swsusp image data without heavy tools. [Or think root
>>>compromise month after you used swsusp.]
>>>
>>>Encrypting swsusp image is of course even better, because you don't
>>>have to write large ammounts of zeros to your disks during resume ;-).
>>
>>Not only is it better, it completely supercedes wiping the image.
>>Your laptop being stolen after resume is very much a corner case.
>>You suspend your laptop while you are not around, don't you?
> 
> 
> Not necessarily.  Some people use suspend instead of shutdown. :-)

Now here's what I'm currently doing:

I do usually suspend instead of shutdown. The suspend partition is the
only unencrypted swap partition and it is disabled during regular
operation so it is not used for regular swapping. Except for a small
boot partition without any valuable data all other partitions are encrypted.

The key for dm-crypt setup is stored on an ide flash disk which isn't
inserted during travelling and which is transported separately.

Now let's imagine the laptop gets stolen by an average thief which is
the most common case.Thief needs to know if the laptop is working
because thief wants to sell it so thief powers on the laptop.

swsusp resumes and with the encryption patch renders the suspend image
worthless. The suspend/resume script immediately checks for the presence
of the ide flash disk with the correct key (match is done against the
in-kernel dm-crypt key). If the ide flash disk is not present or if
there is a key mismatch the script shuts the system immediately down, so
the in-kernel key is lost.

The only way for the thief now to access any data on the disk is to come
back and steal the flash disk, too.

When the initrd feature pavel just notified me about comes from mm to
mainline one can additionally protect the swap partition used for
suspend with dm-crypt and collect the key at resume time via initrd.

In this case the disk is then not only protected against the average
thief but also against the professinal one as long as the flash disk is
secure.

And if the laptop is not stolen the encrypted suspend image prevents
against nasty surprises of sensitive data turning up on disk that should
never have been put there in the first place (oh well, but one needs to
suspend from time to time).
-- 
Andreas Steinmetz                       SPAMmers use robotrap@domdv.de

Re: [PATCH] zero disk pages used by swsusp on resume

[Rafael J. Wysocki]

Hi,

On Monday, 11 of April 2005 19:02, Andreas Steinmetz wrote:
> Rafael J. Wysocki wrote:
> > Hi,
> > 
> > On Monday, 11 of April 2005 12:37, Oliver Neukum wrote:
> > 
> >>Am Sonntag, 10. April 2005 22:14 schrieb Pavel Machek:
> >>
> >>>Hi!
> >>>
> >>>
> >>>>>Oliver Neukum wrote:
> >>>>>
> >>>>>>What is the point in doing so after they've rested on the disk for ages?
> >>>>>
> >>>>>The point is not physical access to the disk but data gathering after
> >>>>>resume or reboot.
> >>>>
> >>>>After resume or reboot normal access control mechanisms will work
> >>>>again. Those who can read a swap partition under normal circumstances
> >>>>can also read /dev/kmem. It seems to me like you are putting an extra
> >>>>lock on a window on the third floor while leaving the front door open.
> >>>
> >>>Andreas is right, his patches are needed.
> >>>
> >>>Currently, if your laptop is stolen after resume, they can still data
> >>>in swsusp image.
> >>>
> >>>Zeroing the swsusp pages helps a lot here, because at least they are
> >>>not getting swsusp image data without heavy tools. [Or think root
> >>>compromise month after you used swsusp.]
> >>>
> >>>Encrypting swsusp image is of course even better, because you don't
> >>>have to write large ammounts of zeros to your disks during resume ;-).
> >>
> >>Not only is it better, it completely supercedes wiping the image.
> >>Your laptop being stolen after resume is very much a corner case.
> >>You suspend your laptop while you are not around, don't you?
> > 
> > 
> > Not necessarily.  Some people use suspend instead of shutdown. :-)
> 
> Now here's what I'm currently doing:
> 
> I do usually suspend instead of shutdown. The suspend partition is the
> only unencrypted swap partition and it is disabled during regular
> operation so it is not used for regular swapping. Except for a small
> boot partition without any valuable data all other partitions are encrypted.
> 
> The key for dm-crypt setup is stored on an ide flash disk which isn't
> inserted during travelling and which is transported separately.
> 
> Now let's imagine the laptop gets stolen by an average thief which is
> the most common case.Thief needs to know if the laptop is working
> because thief wants to sell it so thief powers on the laptop.
> 
> swsusp resumes and with the encryption patch renders the suspend image
> worthless. The suspend/resume script immediately checks for the presence
> of the ide flash disk with the correct key (match is done against the
> in-kernel dm-crypt key). If the ide flash disk is not present or if
> there is a key mismatch the script shuts the system immediately down, so
> the in-kernel key is lost.
> 
> The only way for the thief now to access any data on the disk is to come
> back and steal the flash disk, too.

Yes.  And if you accidentally lose the flash disk, you are locked out of your
own data. ;-)  The same happens if the data on the flash disk is lost (which
occurs, from time to time).  You should be _really_ careful doing such things
and IMO it's not to be tried by Joe User.

OTOH, the encryption of the system image during suspend is generally
a very good idea.  IMO we should also check the integrity of the image
at that time, which would require computing some checksums on suspend.

Greets,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: [PATCH] zero disk pages used by swsusp on resume

[Andreas Steinmetz]

Rafael J. Wysocki wrote:
> Hi,
> 
> On Monday, 11 of April 2005 19:02, Andreas Steinmetz wrote:
> 
>>Rafael J. Wysocki wrote:
>>
>>>Hi,
>>>
>>>On Monday, 11 of April 2005 12:37, Oliver Neukum wrote:
>>>
>>>
>>>>Am Sonntag, 10. April 2005 22:14 schrieb Pavel Machek:
>>>>
>>>>
>>>>>Hi!
>>>>>
>>>>>
>>>>>
>>>>>>>Oliver Neukum wrote:
>>>>>>>
>>>>>>>
>>>>>>>>What is the point in doing so after they've rested on the disk for ages?
>>>>>>>
>>>>>>>The point is not physical access to the disk but data gathering after
>>>>>>>resume or reboot.
>>>>>>
>>>>>>After resume or reboot normal access control mechanisms will work
>>>>>>again. Those who can read a swap partition under normal circumstances
>>>>>>can also read /dev/kmem. It seems to me like you are putting an extra
>>>>>>lock on a window on the third floor while leaving the front door open.
>>>>>
>>>>>Andreas is right, his patches are needed.
>>>>>
>>>>>Currently, if your laptop is stolen after resume, they can still data
>>>>>in swsusp image.
>>>>>
>>>>>Zeroing the swsusp pages helps a lot here, because at least they are
>>>>>not getting swsusp image data without heavy tools. [Or think root
>>>>>compromise month after you used swsusp.]
>>>>>
>>>>>Encrypting swsusp image is of course even better, because you don't
>>>>>have to write large ammounts of zeros to your disks during resume ;-).
>>>>
>>>>Not only is it better, it completely supercedes wiping the image.
>>>>Your laptop being stolen after resume is very much a corner case.
>>>>You suspend your laptop while you are not around, don't you?
>>>
>>>
>>>Not necessarily.  Some people use suspend instead of shutdown. :-)
>>
>>Now here's what I'm currently doing:
>>
>>I do usually suspend instead of shutdown. The suspend partition is the
>>only unencrypted swap partition and it is disabled during regular
>>operation so it is not used for regular swapping. Except for a small
>>boot partition without any valuable data all other partitions are encrypted.
>>
>>The key for dm-crypt setup is stored on an ide flash disk which isn't
>>inserted during travelling and which is transported separately.
>>
>>Now let's imagine the laptop gets stolen by an average thief which is
>>the most common case.Thief needs to know if the laptop is working
>>because thief wants to sell it so thief powers on the laptop.
>>
>>swsusp resumes and with the encryption patch renders the suspend image
>>worthless. The suspend/resume script immediately checks for the presence
>>of the ide flash disk with the correct key (match is done against the
>>in-kernel dm-crypt key). If the ide flash disk is not present or if
>>there is a key mismatch the script shuts the system immediately down, so
>>the in-kernel key is lost.
>>
>>The only way for the thief now to access any data on the disk is to come
>>back and steal the flash disk, too.
> 
> 
> Yes.  And if you accidentally lose the flash disk, you are locked out of your
> own data. ;-)  The same happens if the data on the flash disk is lost (which
> occurs, from time to time).  You should be _really_ careful doing such things
> and IMO it's not to be tried by Joe User.

Right. But thats what this backup flash disk in some safe place is for.
No risk, no fun :-)

-- 
Andreas Steinmetz                       SPAMmers use robotrap@domdv.de

Re: [PATCH] zero disk pages used by swsusp on resume

[Jan Niehusmann]

> Andreas is right, his patches are needed.
> 
> Currently, if your laptop is stolen after resume, they can still data
> in swsusp image.

Which shows that swsusp is a security risk if you have sensitive data in
RAM. A thief stealing a running computer can get access to memory
contents much more easy if he can just suspend the system and then
recover all the memory contents from disk. Encrypted swsusp wouldn't
help here if the key is stored on the disk as well.

(This is probably not a real risk in most applications, but one should
keep it in mind and disable swsusp if necessary)

Jan

Re:[PATCH] zero disk pages used by swsusp on resume

[Pavel Machek]

Hi! What about doing it right? Encrypt it with symmetric cypher and store key in suspend header. That way key is removed automagically while fixing signatures. No need to clear anythink. OTOH we may want to dm-crypt whole swap partition. You could still store key in header... --p

-- pavel. Sent from  mobile phone. Sorry for poor formatting.

Re: [PATCH] zero disk pages used by swsusp on resume

[Andreas Steinmetz]

[reformatted]

Pavel Machek wrote:
> Hi! What about doing it right? Encrypt it with symmetric cypher
> and store key in suspend header. That way key is removed automagically
> while fixing signatures. No need to clear anythink.

Good idea. I'll have a look though it will take a while (busy with my job).

> OTOH we may want to dm-crypt whole swap partition.

This would leave the problem that the in-kernel data would be accessible
on the swap device after resume.

> You could still store key in header... --p

Which is the good idea from step one above.

> 
> -- pavel. Sent from  mobile phone. Sorry for poor formatting.

The only remark I do have here is that swsusp would then depend on
crypto so the swsusp encryption should be a config option.
-- 
Andreas Steinmetz                       SPAMmers use robotrap@domdv.de

Re: [PATCH] zero disk pages used by swsusp on resume

[Pavel Machek]

Hi!

> > Hi! What about doing it right? Encrypt it with symmetric cypher
> > and store key in suspend header. That way key is removed automagically
> > while fixing signatures. No need to clear anythink.
> 
> Good idea. I'll have a look though it will take a while (busy with my job).
> 
> > OTOH we may want to dm-crypt whole swap partition.
> 
> This would leave the problem that the in-kernel data would be accessible
> on the swap device after resume.

I meant "when dm-crypt is used, encrypting swsusp data with second key
is no longer _that_ nice"...

So perhaps we should encrypt swap by default with random key, and
reuse same code for swsusp...

> > -- pavel. Sent from  mobile phone. Sorry for poor formatting.
> 
> The only remark I do have here is that swsusp would then depend on
> crypto so the swsusp encryption should be a config option.

Yes. Not evereyone has so fast CPU that encryption is NOP.

								Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.

Re: [PATCH] zero disk pages used by swsusp on resume

[Oliver Neukum]

> > > Hi! What about doing it right? Encrypt it with symmetric cypher
> > > and store key in suspend header. That way key is removed automagically
> > > while fixing signatures. No need to clear anythink.

You might want to leave the key in the kernel image. You need to boot the
same image anyway. Leaving the key in the header will not increase
security while the os is down.

	Regards
		Oliver

Re: [PATCH] zero disk pages used by swsusp on resume

[Pavel Machek]

Hi!

> > > > Hi! What about doing it right? Encrypt it with symmetric cypher
> > > > and store key in suspend header. That way key is removed automagically
> > > > while fixing signatures. No need to clear anythink.
> 
> You might want to leave the key in the kernel image. You need to boot the
> same image anyway. Leaving the key in the header will not increase
> security while the os is down.

I believe leaving it in the header will be easier, and it is more
easily wiped, there, too.

If suspend fails, and user boots with noresume and mkswaps, key in
header will get rewritten, too. Good.
									Pavel

-- 
Boycott Kodak -- for their patent abuse against Java.

Re: [PATCH] zero disk pages used by swsusp on resume

[Andreas Steinmetz]

Pavel Machek wrote:
> Hi!
> 
> 
>>>Hi! What about doing it right? Encrypt it with symmetric cypher
>>>and store key in suspend header. That way key is removed automagically
>>>while fixing signatures. No need to clear anythink.
>>
>>Good idea. I'll have a look though it will take a while (busy with my job).
>>
>>
>>>OTOH we may want to dm-crypt whole swap partition.
>>
>>This would leave the problem that the in-kernel data would be accessible
>>on the swap device after resume.
> 
> 
> I meant "when dm-crypt is used, encrypting swsusp data with second key
> is no longer _that_ nice"...

Hmm, thinking of a future swsusp2 with initrd capabilites encrption of
the suspend image itself is still useful to prevent data gathering after
resume. Using dm-crypt for encryption of the swap partition in this case
is useful during resume so this fits nicely together.

BTW: I spent my day on implementing the encryption of the suspend image
and will send patches after a few more tests.
-- 
Andreas Steinmetz                       SPAMmers use robotrap@domdv.de