Re: [TuxOnIce-devel] RFC: Suspend-to-ram cold boot protection by encrypting page cache

[Jeremy Maitin-Shepard <jeremy@jeremyms.com>]

Pavel Machek <pavel@ucw.cz> writes:

> On Wed 2009-07-08 04:09:41, Jeremy Maitin-Shepard wrote:
>> Pavel Machek <pavel@ucw.cz> writes:
>> 
>> > On Wed 2009-07-08 03:47:53, Jeremy Maitin-Shepard wrote:
>> >> Pavel Machek <pavel@ucw.cz> writes:
>> >> 
>> >> [snip]
>> >> 
>> >> > I believe uswsusp could be used rather easily. Just modify s2disk to
>> >> > encrypt image in ram without writing it out, then decrypt it from ram
>> >> > and resume... it should be interesting hack.
>> >> 
>> >> As far as I understand, that would be completely useless since the image
>> >> that would be encrypted would just be a copy of what would still remain
>> >> in memory.
>> 
>> > Yes... so next step would be kernel call that would erase all the
>> > pagecache and anonymous pages. You would still leave some data in
>> > kernel structures, but that would be quite hard to fix. 
>> 
>> Okay.  (This does still require the same assumption as TuxOnIce
>> regarding the page cache, though.)

> (Not sure; clearing the page cache could be done atomically, from
> interrupts disabled. But I'm no mm expert.)

But surely it wouldn't work to leave interrupts disabled after that
until the page cache is restored.  After the page cache (and other
sensitive memory) is encrypted, after possibly entering and resuming
from S3, the page cache needs to be decrypted.  Userspace will be doing
the decryption if a uswsusp-like model is being used, and even if the
decryption is done in the kernel, userspace needs to provide the
encryption key to the kernel.  Even disregarding the issue of running
userspace with interrupts disabled, which I assume might have problems,
userspace would likely need to talk to some of the devices in order to
obtain the encryption key from the user.

-- 
Jeremy Maitin-Shepard