linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: U Kuehn <ukuehn@acm.org>
To: Jeremy Maitin-Shepard <jeremy@jeremyms.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	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: Thu, 02 Jul 2009 07:14:14 +0200	[thread overview]
Message-ID: <4A4C4226.8000302@acm.org> (raw)
In-Reply-To: <87r5x0ypev.fsf@jeremyms.com>

Hi Jeremy,

Jeremy Maitin-Shepard wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> 
>> 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.
> 

This attack scenario essentially attacks the standard assumption that
memory contents is _immediately_ lost once power to the RAM is removed.

Essentially, the same problems arise whether the machine is suspended to
RAM or is just left on, with some screen saver or something similar in
place. So if the machine is snatched out of your hands it is still
running...

That's the reason why I personally prefer suspend-to-disk over
suspend-to-ram. Of course, if you have encryption in place, e.g. for you
home partition, it is necessary that the swap space is encrypted so that
the system state is protected during suspend-to-disk.

The approach to encrypt the memory contents during suspend-to-ram seems
to be a very fundamental change in the kernel, in order to protect
against a very specific attack. And unfortunately it helps only against
an cold-boot attack that happens during suspend-to-ram. It does not
protect against the attack taking place when the machine is just "on".

Just my 2c.

With best regards,
Ulrich


  reply	other threads:[~2009-07-02  5:26 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
2009-07-02  5:14               ` U Kuehn [this message]
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=4A4C4226.8000302@acm.org \
    --to=ukuehn@acm.org \
    --cc=jeremy@jeremyms.com \
    --cc=linux-kernel@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).