All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Maitin-Shepard <jeremy@jeremyms.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Nigel Cunningham <ncunningham@crca.org.au>,
	tuxonice-devel@lists.tuxonice.net, linux-kernel@vger.kernel.org
Subject: Re: [TuxOnIce-devel] RFC: Suspend-to-ram cold boot protection by encrypting page cache
Date: Wed, 01 Jul 2009 13:57:01 -0700	[thread overview]
Message-ID: <874otw15r6.fsf@jeremyms.com> (raw)
In-Reply-To: <200907011755.10386.rjw@sisk.pl> (Rafael J. Wysocki's message of "Wed, 01 Jul 2009 17:55:09 +0200")

"Rafael J. Wysocki" <rjw@sisk.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

  reply	other threads:[~2009-07-01 20:57 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-01  6:07 RFC: Suspend-to-ram cold boot protection by encrypting page cache Jeremy Maitin-Shepard
2009-07-01  6:24 ` [TuxOnIce-devel] " Nigel Cunningham
2009-07-01  6:43   ` Jeremy Maitin-Shepard
2009-07-01  9:09     ` Nigel Cunningham
2009-07-01 15:55       ` Rafael J. Wysocki
2009-07-01 20:57         ` Jeremy Maitin-Shepard [this message]
2009-07-01 22:41           ` Rafael J. Wysocki
2009-07-01 22:58             ` Nigel Cunningham
2009-07-01 23:06             ` Jeremy Maitin-Shepard
2009-07-02  5:14               ` U Kuehn
2009-07-02  5:47                 ` Jeremy Maitin-Shepard
2009-07-02 16:12               ` Rafael J. Wysocki
2009-07-04  2:44       ` Pavel Machek
2009-07-08 10:47         ` Jeremy Maitin-Shepard
2009-07-04  2:57           ` Pavel Machek
2009-07-08 11:09             ` Jeremy Maitin-Shepard
2009-07-09 10:14               ` Pavel Machek
2009-07-10  7:05                 ` Jeremy Maitin-Shepard
2009-07-11 22:10                   ` Pavel Machek
2009-07-01 12:21 ` Jens Gustedt
2009-07-01 20:40   ` Jeremy Maitin-Shepard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874otw15r6.fsf@jeremyms.com \
    --to=jeremy@jeremyms.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ncunningham@crca.org.au \
    --cc=rjw@sisk.pl \
    --cc=tuxonice-devel@lists.tuxonice.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.