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: <200907021812.01147.rjw@sisk.pl>
Date:	Thu, 2 Jul 2009 18:12:00 +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 Thursday 02 July 2009, Jeremy Maitin-Shepard wrote:
> "Rafael J. Wysocki" <rjw@...k.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.

This hasn't been verified.

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

This hasn't even been discussed.

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

That depends on whether or not the TuxOnIce approach to hibernation is
implemented in the mainline kernel.  I'm still going to work on this, although
at the moment I'm working on some things that I regard as more urgent, but
since it's going to affect multiple subsystems, we'll need to discuss this.

The timing is not particularly good for that, though.

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/