Messages in this thread | ![/](/images/icornerl.gif) | | Date | Thu, 14 Apr 2005 15:27:40 -0700 | From | Matt Mackall <> | Subject | Re: [PATCH encrypted swsusp 1/3] core functionality |
| |
On Thu, Apr 14, 2005 at 10:18:12PM +0200, Pavel Machek wrote: > Hi! > > > > So we would need to zero out the suspend image in swap to prevent the > > > retrieval of this data from the running machine (imagine a > > > remote-root-hole). > > > > > > Zeroing out the suspend image means "write lots of megabytes to the > > > disk" which takes a lot of time. > > > > Zero only the mlocked regions. This should take essentially no time at > > all. Swsusp knows which these are because they have to be mlocked > > I believe this is tricky to implement. You are free to produce patch, > and if that patch is nicer/simpler than Anreas's code, I may consider > it.
If I understand swsusp correctly, we can simply set a bit in the pbe struct to indicate that it's a locked page.
This can be done by walking the vma list attached to the page's address space with vma_prio_tree_foreach() and checking the vma->vm_flags with VM_LOCKED. Analogous to what the swapout code does.
We can either do this in data_write() or preferably higher (copy_data?) when we have the pfn handy. The lock bit can be stashed in bit 0 of pbe->address, among other places. Then in data_read, we check the bit and zero the source.
As I'm not about to actually use swsusp any time soon, someone else is invited to implement the above. Should take about 10-20 lines.
-- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |