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]
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ