Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752837AbZGAWlw (ORCPT ); Wed, 1 Jul 2009 18:41:52 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752089AbZGAWlo (ORCPT ); Wed, 1 Jul 2009 18:41:44 -0400 Received: from ogre.sisk.pl ([217.79.144.158]:33819 "EHLO ogre.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751716AbZGAWlo (ORCPT ); Wed, 1 Jul 2009 18:41:44 -0400 From: "Rafael J. Wysocki" To: "Jeremy Maitin-Shepard" Subject: Re: [TuxOnIce-devel] RFC: Suspend-to-ram cold boot protection by encrypting page cache Date: Thu, 2 Jul 2009 00:41:51 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.31-rc1-rjw; KDE/4.2.4; x86_64; ; ) Cc: Nigel Cunningham , tuxonice-devel@lists.tuxonice.net, linux-kernel@vger.kernel.org References: <87hbxx0wcp.fsf@jeremyms.com> <200907011755.10386.rjw@sisk.pl> <874otw15r6.fsf@jeremyms.com> In-Reply-To: <874otw15r6.fsf@jeremyms.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907020041.52198.rjw@sisk.pl> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2899 Lines: 61 On Wednesday 01 July 2009, Jeremy Maitin-Shepard wrote: > "Rafael J. Wysocki" 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/