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: <874otw15r6.fsf@jeremyms.com>
Date:	Wed, 01 Jul 2009 13:57:01 -0700
From:	Jeremy Maitin-Shepard <jeremy@...emyms.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Nigel Cunningham <ncunningham@...a.org.au>,
	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

"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.

> 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.)

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