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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87hbxl587g.fsf@jeremyms.com>
Date:	Fri, 10 Jul 2009 00:05:23 -0700
From:	Jeremy Maitin-Shepard <jeremy@...emyms.com>
To:	Pavel Machek <pavel@....cz>
Cc:	Nigel Cunningham <ncunningham@...a.org.au>,
	tuxonice-devel@...ts.tuxonice.net, linux-kernel@...r.kernel.org,
	Rafael Wysocki <rjw@...k.pl>
Subject: Re: [TuxOnIce-devel] RFC: Suspend-to-ram cold boot protection by encrypting page cache

Pavel Machek <pavel@....cz> writes:

> On Wed 2009-07-08 04:09:41, Jeremy Maitin-Shepard wrote:
>> Pavel Machek <pavel@....cz> writes:
>> 
>> > On Wed 2009-07-08 03:47:53, Jeremy Maitin-Shepard wrote:
>> >> Pavel Machek <pavel@....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
--
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/