Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Subject: RE: [RFC][PATCH 0a/3] TXT: Intel(R) Trusted Execution Technologysupport for Linux - Overview
Date: Thu, 9 Oct 2008 11:35:56 -0700
Message-ID: <D936D925018D154694D8A362EEB0892005B12CC8@orsmsx416.amr.corp.intel.com>
In-Reply-To: <20081009182149.GE12507@elf.ucw.cz>
Thread-Topic: [RFC][PATCH 0a/3] TXT: Intel(R) Trusted Execution Technologysupport for Linux - Overview
Thread-Index: AckqO8YE+59hmHS0Ryat8bJqMU0JuQAAIdRw
References: <D936D925018D154694D8A362EEB0892005AC105B@orsmsx416.amr.corp.intel.com> <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>
From: "Cihula, Joseph" <joseph.cihula@intel.com>
To: "Pavel Machek" <pavel@suse.cz>, "Chris Wright" <chrisw@sous-sol.org>
Cc: <linux-kernel@vger.kernel.org>, "Wang, Shane" <shane.wang@intel.com>,
       "Wei, Gang" <gang.wei@intel.com>,
       "Van De Ven, Arjan" <arjan.van.de.ven@intel.com>,
       "Mallick, Asit K" <asit.k.mallick@intel.com>,
       "Nakajima, Jun" <jun.nakajima@intel.com>,
       "Chris Wright" <chrisw@redhat.com>, "Jan Beulich" <jbeulich@novell.com>,
       <mingo@elte.hu>, <tytso@mit.edu>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2349
Lines: 56

> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> owner@vger.kernel.org] On Behalf Of Pavel Machek
> Sent: Thursday, October 09, 2008 11:22 AM
> 
> On Thu 2008-10-09 11:14:51, Chris Wright wrote:
> > * Pavel Machek (pavel@suse.cz) wrote:
> > > I have never used trusted boot and I'm not sure I want to. Why
> would I
> > > want to do that?
> >
> > So that you can reason that you've booted kernel/initrd that you
wanted
> > to (and have established a root of trust for follow-on, like Joe's
IMA
> > example), and in the case that you didn't (say bluepill), you have a
> > policy in place to handle it.
> 
> So like... instead of booting into rootkit it now will not boot at
> all?

The action taken when a policy fails to verify is configurable.  Some
users may prefer to hang the boot rather than boot a rootkit'ed kernel.
Those who don't can still get value from the fact that the PCRs will
indicate that this was not the previous (or known-good) kernel, if they
have sealed some data to the good values or if they are using
attestation (e.g. via a Trusted Network Connect (TNC)/NAC
infrastructure).

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

Joe
--
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/