lkml.org 
[lkml]   [2009]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [TuxOnIce-devel] RFC: Suspend-to-ram cold boot protection by encrypting page cache
Hi.

Rafael J. Wysocki wrote:
> On Wednesday 01 July 2009, Jeremy Maitin-Shepard wrote:
>> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>>
>>> [snip]
>>>> As far as the possibility of using uswsusp goes, I'd like to get
>>>> Rafael's input there - he knows it much better than I do (explicitly
>>>> adding him to the ccs).
>>> No, the current mainline hibernation code can't be modified easily
>>> to encrypt the page cache before suspending.
>>> Also, I don't see much value in doing that before suspend to RAM, because
>>> (1) passwords and encryption keys should be stored in mlocked memory
>> I do not have a complete understanding of linux memory management, but
>> couldn't such memory also be included in the encryption? The page cache
>> is presumably the bulk of memory, but I realize there are likely several
>> other places in memory that may contain sensitive data. However, it
>> would seem that encrypting these in place should, for the most part,
>> also be quite feasible.
>
> What is the particular attach scenario you'd like to prevent
>
>>> and (2)
>>> the encryption overhead (including measures to protect the encrypted page cache
>>> from being corrupted) would hurt the speed of suspend to RAM and resume, which
>>> is a very important thing.
>> I am not suggesting that it be done unconditionally. I am simply
>> suggesting that it be made available as an option, just as hibernating
>> to encrypted swap is an option, and using dm-crypt in general is an
>> option. Surely encrypting and decrypting would take additional time,
>> but it would also surely take far less time than hibernating and
>> resuming. On machines with hardware encryption support (such as the
>> future Intel Westmere processor), encrypting several gigabytes of memory
>> may not take very much time at all.
>>
>>> Moreover, I don't really see how we can feed the decryption key to the
>>> kernel during resume before the page cache can be accessed.
>> My understanding is that this is something that is already done in
>> tuxonice. After the contents of the page cache are written to disk,
>> some of the page cache is overwritten with a copy of the rest of memory,
>> and the kernel continues to interact with the userspace UI program. I
>> would assume that this state is effectively equivalent to the state the
>> system would be in after encrypting the page cache. (Obviously the
>> memory needed by the userspace helper would have to be treated
>> specially.)
>
> There's one problem with this approach, which is that we're not sure if the
> encrypted pages won't be written to by someone else. TuxOnIce makes the
> assumption that it won't, but that has yet to be demonstrated.

I can think of a couple of things that can be done here:

- Checksum the pages and verify the data hasn't changed.
- Unmap pages as they're compressed, so that any unexpected usage is caught.

Do you have any other ideas?

Regards,

Nigel


\
 
 \ /
  Last update: 2009-07-02 01:01    [W:0.078 / U:0.672 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site