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: <200907020041.52198.rjw@sisk.pl>
Date:	Thu, 2 Jul 2009 00:41:51 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	"Jeremy Maitin-Shepard" <jeremy@...emyms.com>
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

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.

Best,
Rafael
--
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/