Message-ID: <4A4BEA25.3000605@crca.org.au>
Date:	Thu, 02 Jul 2009 08:58:45 +1000
From:	Nigel Cunningham <ncunningham@...a.org.au>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
CC:	Jeremy Maitin-Shepard <jeremy@...emyms.com>,
	tuxonice-devel@...ts.tuxonice.net, linux-kernel@...r.kernel.org
Subject: Re: [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@...k.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists