Re: [PATCH] zero disk pages used by swsusp on resume
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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zero disk pages used by swsusp on resume
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" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zero disk pages used by swsusp on resume
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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zero disk pages used by swsusp on resume
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" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zero disk pages used by swsusp on resume
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zero disk pages used by swsusp on resume
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zero disk pages used by swsusp on resume
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zero disk pages used by swsusp on resume
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zero disk pages used by swsusp on resume
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zero disk pages used by swsusp on resume
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zero disk pages used by swsusp on resume
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zero disk pages used by swsusp on resume
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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zero disk pages used by swsusp on resume
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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zero disk pages used by swsusp on resume
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zero disk pages used by swsusp on resume
> > > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zero disk pages used by swsusp on resume
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zero disk pages used by swsusp on resume
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zero disk pages used by swsusp on resume
[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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re:[PATCH] zero disk pages used by swsusp on resume
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 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.
--
Andreas Steinmetz SPAMmers use [EMAIL PROTECTED]
--- linux-2.6.11.2/kernel/power/swsusp.c.ast2005-04-10 14:08:55.0
+0200
+++ linux-2.6.11.2/kernel/power/swsusp.c2005-04-10 14:24:10.0
+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;
}
