Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760241AbYJISoY (ORCPT ); Thu, 9 Oct 2008 14:44:24 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750878AbYJISoP (ORCPT ); Thu, 9 Oct 2008 14:44:15 -0400 Received: from gprs189-60.eurotel.cz ([160.218.189.60]:36069 "EHLO gprs189-60.eurotel.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754026AbYJISoP (ORCPT ); Thu, 9 Oct 2008 14:44:15 -0400 Date: Thu, 9 Oct 2008 20:45:52 +0200 From: Pavel Machek To: "Cihula, Joseph" Cc: Chris Wright , linux-kernel@vger.kernel.org, "Wang, Shane" , "Wei, Gang" , "Van De Ven, Arjan" , "Mallick, Asit K" , "Nakajima, Jun" , Chris Wright , Jan Beulich , mingo@elte.hu, tytso@mit.edu Subject: Re: [RFC][PATCH 0a/3] TXT: Intel(R) Trusted Execution Technologysupport for Linux - Overview Message-ID: <20081009184552.GF12507@elf.ucw.cz> References: <20081009125311.GD1623@ucw.cz> <20081009174427.GB6912@sequoia.sous-sol.org> <20081009175938.GA12507@elf.ucw.cz> <20081009181451.GD6912@sequoia.sous-sol.org> <20081009182149.GE12507@elf.ucw.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Warning: Reading this can be dangerous to your mental health. User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1680 Lines: 38 > > > > You exit/reenter the trusted mode accross sleep... so any > guarantees > > > > "trusted" mode does are void, right? > > > > > > You exit from kernel to tboot on any shutdown, which handles the > proper > > > teardown of the measured env (meaning you also come back on via > tboot). > > > So things like saving tpm state, scrubbing secrets from memory, etc. > > > > Aha, so instead sleep mode is useless because I'll have to remount all > > the crypto filesystems and restart all the apps... > > Sleep mode works the same as it does today (caveat S4 issue which we > will fix), it just goes through the tboot code before putting the > platform HW into the appropriate state. What this process is adding is > that on resume, tboot will get control from BIOS instead of the kernel. > Then tboot will re-launch the TXT environment before going back to the > kernel at the kernel's expected S3 resume vector. The re-establishing > of the protected environment won't disrupt the subsequent kernel resume > process. No, I don't get it. So presumably useful thing to do is to seal my crypto partition so that only known-good kernel can access it? But then, the crypto keys will be in ram during suspend/resume (because I have the filesystem mounted) => I loose any guarantees? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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/