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 16:06:00 -0700 [thread overview]
Message-ID: <87r5x0ypev.fsf@jeremyms.com> (raw)
In-Reply-To: <200907020041.52198.rjw@sisk.pl> (Rafael J. Wysocki's message of "Thu, 02 Jul 2009 00:41:51 +0200")
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> [snip]
> What is the particular attach scenario you'd like to prevent
The standard cold boot attack, which basically allows the attacker to
obtain a copy of the data in RAM. System is powered on. RAM is
optionally cooled. RAM is then quickly removed from the original
machine, placed in another machine, and copied. See
http://en.wikipedia.org/wiki/Cold_boot_attack
The wikipedia page links to this Youtube video that nicely demonstrates
the attack:
http://www.youtube.com/watch?v=JDaicPIgn9U
The cooling helps to preserve the data for longer, but is not always
even necessary. Special hardware is not even needed. Depending on
whether the BIOS clears the memory during the POST, it might also be
possible to do the attack on the same machine (i.e. without having to
move the RAM into another machine) by rebooting it and booting from
e.g. a CD-ROM or USB drive.
> [snip]
> 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.
Yes, it certainly depends on that assumptions, but it is not necessarily
a problem that it does.
There are really two parts to that assumption:
1. Whether the current Linux kernel in a particular (or perhaps any)
configuration _does_ satisfy that assumption.
2. Whether Linux _should_ satisfy that assumption. This is important
because if something comes along later that violates the assumption,
it would be nice to be able to consider that something a bug and fix
it.
It is really the second part that is most important, though evaluating
the extent to which the first part holds would help in determining the
feasibility of the second part.
--
Jeremy Maitin-Shepard
next prev parent reply other threads:[~2009-07-01 23:06 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
2009-07-01 22:41 ` Rafael J. Wysocki
2009-07-01 22:58 ` Nigel Cunningham
2009-07-01 23:06 ` Jeremy Maitin-Shepard [this message]
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=87r5x0ypev.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.