zero disk pages used by swsusp on resume
Subsystems (2)
PATCH 1/1 zero disk pages used by swsusp on resume
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.
Signature · 1 line
Andreas Steinmetz SPAMmers use [email protected]
kernel/power/swsusp.c renamed from kernel/power/swsusp.c.ast +29 -0
@@ -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; }
Am Sonntag, 10. April 2005 15:13 schrieb Andreas Steinmetz:
Quoted 6 lines
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
Quoted 1 line · Oliver Neukum
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.
Signature · 1 line
Andreas Steinmetz SPAMmers use [email protected]
Am Sonntag, 10. April 2005 21:29 schrieb Andreas Steinmetz:
Quoted 5 lines
Quoted 1 line · Oliver Neukum
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
Hi!
Quoted 10 lines
Quoted 5 lines
Quoted 1 line · Oliver Neukum
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
Signature · 1 line
Boycott Kodak -- for their patent abuse against Java.
Quoted 18 lines · Pavel Machek
Hi!
Quoted 10 lines
Quoted 5 lines
Quoted 1 line · Oliver Neukum
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.
Quoted 6 lines
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
Quoted 2 lines · Pavel Machek
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... ;-)
Quoted 1 line
Pavel
Stefan
Hi!
Quoted 9 lines
Quoted 2 lines
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
Signature · 1 line
Boycott Kodak -- for their patent abuse against Java.
Am Sonntag, 10. April 2005 22:14 schrieb Pavel Machek:
Quoted 18 lines
Hi!
Quoted 10 lines
Quoted 5 lines
Quoted 1 line · Oliver Neukum
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.
Quoted 6 lines
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
Quoted 4 lines
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
Hi,
Quoted 23 lines · Oliver Neukum
Am Sonntag, 10. April 2005 22:14 schrieb Pavel Machek:
Quoted 22 lines
Hi!
Quoted 10 lines
Quoted 5 lines
Quoted 1 line · Oliver Neukum
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.]
Quoted 6 lines
Quoted 2 lines
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
Signature · 3 lines
- 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"
Quoted 33 lines · Rafael J. Wysocki
Hi,
Quoted 29 lines · Oliver Neukum
Am Sonntag, 10. April 2005 22:14 schrieb Pavel Machek:
Quoted 26 lines
Hi!
Quoted 11 lines
Quoted 6 lines
Quoted 1 line · Oliver Neukum
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 ;-).
Quoted 6 lines
Quoted 3 lines
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).
Signature · 1 line
Andreas Steinmetz SPAMmers use [email protected]
Hi,
Quoted 62 lines · Andreas Steinmetz
Quoted 33 lines · Rafael J. Wysocki
Hi,
Quoted 29 lines · Oliver Neukum
Am Sonntag, 10. April 2005 22:14 schrieb Pavel Machek:
Quoted 26 lines
Hi!
Quoted 11 lines
Quoted 6 lines
Quoted 1 line · Oliver Neukum
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 ;-).
Quoted 6 lines
Quoted 3 lines
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.
Quoted 2 lines
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
Signature · 3 lines
- 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"
Quoted 71 lines · Rafael J. Wysocki
Hi,
Quoted 67 lines · Andreas Steinmetz
Quoted 37 lines · Rafael J. Wysocki
Hi,
Quoted 32 lines · Oliver Neukum
Am Sonntag, 10. April 2005 22:14 schrieb Pavel Machek:
Quoted 28 lines
Hi!
Quoted 5 lines
Quoted 5 lines
Quoted 1 line · Oliver Neukum
What is the point in doing so after they've rested on the disk for ages?
Quoted 7 lines
Quoted 2 lines
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 ;-).
Quoted 6 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 2 lines
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 :-)
Signature · 1 line
Andreas Steinmetz SPAMmers use [email protected]