[RFC][PATCH 0a/3] TXT: Intel(R) Trusted Execution Technology support for Linux - Overview

[RFC][PATCH 0a/3] TXT: Intel(R) Trusted Execution Technology support for Linux - Overview

[Cihula, Joseph]

Linux community,

The following patches are to add support for Intel(R) Trusted Execution
Technology (Intel(R) TXT) and the Trusted Boot open source project
(tboot).

We request your feedback and suggestions.



Intel(R) TXT Overview:
=====================

Intel's technology for safer computing, Intel(R) Trusted Execution
Technology
(Intel(R) TXT), defines platform-level enhancements that provide the
building
blocks for creating trusted platforms.

Intel TXT was formerly known by the code name LaGrande Technology (LT).

Intel TXT in Brief:
o  Provides dynamic root of trust for measurement (DRTM)
o  Data protection in case of improper shutdown
o  Measurement and verification of launched environment

Intel TXT is part of the vPro(TM) brand and is also available some
non-vPro
systems.  It is available on systems based on the Q35 or X38 Express
chipsets
(e.g. Dell Optiplex 755, HP dc7800, etc.).  However, TXT will be on all
vPro(TM) client platforms starting this year (Montevina and McCreary
-based),
with plans for server support in the near future.

For more information, see http://www.intel.com/technology/security/.
This
site also has a link to the Intel TXT MLE Developers Manual, which has
been updated for the new released platforms.

Intel TXT has been presented at various events over the past few years,
some
of which are:
      LinuxTAG 2008:
http://www.linuxtag.org/2008/en/conf/events/vp-donnerstag/details.html?t
alkid=110
      TRUST2008:
http://www.trust2008.eu/downloads/Keynote-Speakers/3_David-Grawrock_The-
Front-Door-of-Trusted-Computing.pdf
      IDF 2008, Shanghai:
http://inteldeveloperforum.com.edgesuite.net/shanghai_2008/aep/PROS003/i
ndex.html
      IDFs 2006, 2007 (I'm not sure if/where they are online)

Trusted Boot Project Overview:
=============================

Trusted Boot (tboot) is an open source, pre- kernel/VMM module that uses
Intel TXT to perform a measured and verified launch of an OS kernel/VMM.

It is hosted on SourceForge at http://sourceforge.net/projects/tboot.

Tboot currently supports launching Xen (open source VMM/hypervisor w/
TXT
support since v3.2), and now Linux kernels.  Linux support is provided
in the
latest (tboot-20081007) release.


Value Proposition for Linux or "Why should you care?"
=====================================================

While there are many products and technologies that attempt to measure
or
protect the integrity of a running kernel, they all assume the kernel is
"good" to begin with.  The Integrity Measurement Architecture (IMA) and
Linux
Integrity Module interface are examples of such solutions.

To get trust in the initial kernel without using Intel TXT, a static
root of
trust must be used.  This bases trust in BIOS starting at system reset
and
requires measurement of all code executed between system reset through
the
completion of the kernel boot as well as data objects used by that code.
In
the case of a Linux kernel, this means all of BIOS, any option ROMs, the
bootloader and the boot config.  In practice, this is a lot of
code/data, much
of which is subject to change from boot to boot (e.g. changing NICs may
change
option ROMs).  Without reference hashes, these measurement changes are
difficult to assess or confirm as benign.  This process also does not
provide DMA protection, memory configuration/alias checks and locks,
crash
protection, or policy support.

By using the hardware-based root of trust that Intel TXT provides, many
of
these issues can be mitigated.  Specifically: many pre-launch components
can
be removed from the trust chain, DMA protection is provided to all
launched
components, a large number of platform configuration checks are
performed and
values locked, protection is provided for any data in the event of an
improper
shutdown, and there is support for policy-based execution/verification.
This
provides a more stable measurement and a higher assurance of system
configuration and initial state than would be otherwise possible.  Since
the
tboot project is open source, source code for almost all parts of the
trust
chain is available (excepting SMM and Intel-provided firmware).

Patchset:
========

These patches were tested on the 2.6.27-rc6 kernel and apply cleanly to
2.6.27-rc9.

Patch 0a/3:  Overview and motivation (this email)
Patch 0b/3:  Details and how it works
Patch 1/3:   Support for AddressRangeUnusuable ACPI memory type (already
             accepted but not in 2.6.27-rc9)
Patch 2/3:   Disable VT-d (Intel IOMMU) Protected Memory Regions (PMRs)
             (submitted to maintainer)
Patch 3/3:   Intel TXT and tboot support


Joseph Cihula
Shane Wang
Gang Wei
Intel Corp.

Re: [RFC][PATCH 0a/3] TXT: Intel(R) Trusted Execution Technology support for Linux - Overview

[Pavel Machek]

Hi!

> Value Proposition for Linux or "Why should you care?"
> =====================================================
> 
> While there are many products and technologies that attempt to measure
> or
> protect the integrity of a running kernel, they all assume the kernel is
> "good" to begin with.  The Integrity Measurement Architecture (IMA) and
> Linux
> Integrity Module interface are examples of such solutions.
> 
> To get trust in the initial kernel without using Intel TXT, a static
> root of
> trust must be used.  This bases trust in BIOS starting at system reset
> and
> requires measurement of all code executed between system reset through
> the
> completion of the kernel boot as well as data objects used by that code.
> In
> the case of a Linux kernel, this means all of BIOS, any option ROMs, the
> bootloader and the boot config.  In practice, this is a lot of
> code/data, much
> of which is subject to change from boot to boot (e.g. changing NICs may
> change
> option ROMs).  Without reference hashes, these measurement changes are
> difficult to assess or confirm as benign.  This process also does not
> provide DMA protection, memory configuration/alias checks and locks,
> crash
> protection, or policy support.

Ok, I don't get it, why would I want to measure my kernel?

I see why Disney would want to do that, but I don't see why we would
want to help them.

Plus, the fact that trusted mode is pretty much incompatible with
s3/s4 makes it useless, right?

So what is this good for?

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC][PATCH 0a/3] TXT: Intel(R) Trusted Execution Technology support for Linux - Overview

[Chris Wright]

* Pavel Machek (pavel@suse.cz) wrote:
> Ok, I don't get it, why would I want to measure my kernel?

Trusted boot.  There's always the double-edge sword w/ this.  Clearly,
a requirement is that you don't just brick your own box, and have some
policy/mechanism for defining how you'd use trusted boot.  I believe
that's all there w/ TXT patch (since it's mostly handled before kernel
boots, TXT kernel bit is just to help w/ handoff).

> I see why Disney would want to do that, but I don't see why we would
> want to help them.
> 
> Plus, the fact that trusted mode is pretty much incompatible with
> s3/s4 makes it useless, right?

Why do you say that?  Did you look at patch 3/3, see tboot_sleep().

thanks,
-chris

Re: [RFC][PATCH 0a/3] TXT: Intel(R) Trusted Execution Technology support for Linux - Overview

[Pavel Machek]

On Thu 2008-10-09 10:44:27, Chris Wright wrote:
> * Pavel Machek (pavel@suse.cz) wrote:
> > Ok, I don't get it, why would I want to measure my kernel?
> 
> Trusted boot.  There's always the double-edge sword w/ this.  Clearly,
> a requirement is that you don't just brick your own box, and have some
> policy/mechanism for defining how you'd use trusted boot.  I believe
> that's all there w/ TXT patch (since it's mostly handled before kernel
> boots, TXT kernel bit is just to help w/ handoff).

I have never used trusted boot and I'm not sure I want to. Why would I
want to do that?

> > I see why Disney would want to do that, but I don't see why we would
> > want to help them.
> > 
> > Plus, the fact that trusted mode is pretty much incompatible with
> > s3/s4 makes it useless, right?
> 
> Why do you say that?  Did you look at patch 3/3, see tboot_sleep().

You exit/reenter the trusted mode accross sleep... so any guarantees
"trusted" mode does are void, right?
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC][PATCH 0a/3] TXT: Intel(R) Trusted Execution Technology support for Linux - Overview

[Chris Wright]

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

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

thanks,
-chris

Re: [RFC][PATCH 0a/3] TXT: Intel(R) Trusted Execution Technology support for Linux - Overview

[Pavel Machek]

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?

> > 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...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

RE: [RFC][PATCH 0a/3] TXT: Intel(R) Trusted Execution Technologysupport for Linux - Overview

[Cihula, Joseph]

> 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

Re: [RFC][PATCH 0a/3] TXT: Intel(R) Trusted Execution Technology support for Linux - Overview

[Chris Wright]

* Pavel Machek (pavel@suse.cz) wrote:
> So like... instead of booting into rootkit it now will not boot at
> all?

Policy dependent, you can control the policy, pick your poison.

> Aha, so instead sleep mode is useless because I'll have to remount all
> the crypto filesystems and restart all the apps...

Heh, no.  I don't think I did a good job describing it.  Maybe Joe can
do better.

Re: [RFC][PATCH 0a/3] TXT: Intel(R) Trusted Execution Technologysupport for Linux - Overview

[Pavel Machek]

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

RE: [RFC][PATCH 0a/3] TXT: Intel(R) Trusted ExecutionTechnologysupport for Linux - Overview

[Cihula, Joseph]

> From: Pavel Machek [mailto:pavel@suse.cz]
> Sent: Thursday, October 09, 2008 11:46 AM
> 
> > > > > 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?

This goes to the threat model for S3.  The current code assumes that the
S3 resume process is trusted.  That is, the memory image will not be
compromised between the time tboot turns off TXT in order to put the
platform into S3 and the time TXT is re-launched.  For this model, the
purpose of re-launching is to re-establish the original PCR values and
the reset protection.

If stronger protection is desired, the apps that manage keys would need
to seal the keys to the current DRTM PCRs and then clear the plaintext
copies, before the system enters S3.  The tboot and Linux code would
also need to put a (U)MAC over all of the image (the kernel could UMAC
userspace and tboot would UMAC the kernel).  The UMAC that tboot
calculates would get sealed before entry into S3 and then unsealed and
validated upon resume.  OF course this adds time to both entry and
resume.

Joe

Re: [RFC][PATCH 0a/3] TXT: Intel(R) Trusted Execution Technology support for Linux - Overview

[Joseph Cihula]

Peter Zijlstra wrote:
> On Tue, 2008-10-07 at 15:46 -0700, Joseph Cihula wrote:
> 
>> Intel TXT was formerly known by the code name LaGrande Technology (LT).
> 
> Am I the only one who despairs at this? I mean, Intel text, come on
> guys, slap the marketing department already ;-)

It's better than the original acronym, "TET" ;-)

Joe

Re: [RFC][PATCH 0a/3] TXT: Intel(R) Trusted Execution Technology support for Linux - Overview

[Peter Zijlstra]

On Tue, 2008-10-07 at 15:46 -0700, Joseph Cihula wrote:

> Intel TXT was formerly known by the code name LaGrande Technology (LT).

Am I the only one who despairs at this? I mean, Intel text, come on
guys, slap the marketing department already ;-)

[RFC][PATCH 0a/3] TXT: Intel(R) Trusted Execution Technology support for Linux - Overview

[Joseph Cihula]

(re-posted with apologies for formatting and email addresses)

Linux community,

The following patches are to add support for Intel(R) Trusted Execution 
Technology (Intel(R) TXT) and the Trusted Boot open source project (tboot).

We request your feedback and suggestions.



Intel(R) TXT Overview:
=====================

Intel's technology for safer computing, Intel(R) Trusted Execution 
Technology
(Intel(R) TXT), defines platform-level enhancements that provide the 
building blocks for creating trusted platforms.

Intel TXT was formerly known by the code name LaGrande Technology (LT).

Intel TXT in Brief:
o  Provides dynamic root of trust for measurement (DRTM)
o  Data protection in case of improper shutdown o  Measurement and 
verification of launched environment

Intel TXT is part of the vPro(TM) brand and is also available some 
non-vPro systems.  It is available on systems based on the Q35 or X38 
Express chipsets (e.g. Dell Optiplex 755, HP dc7800, etc.).  However, 
TXT will be on all vPro(TM) client platforms starting this year 
(Montevina and McCreary -based), with plans for server support in the 
near future.

For more information, see http://www.intel.com/technology/security/.  
This site also has a link to the Intel TXT MLE Developers Manual, which 
has been updated for the new released platforms.

Intel TXT has been presented at various events over the past few years, 
some of which are:
      LinuxTAG 2008:  
http://www.linuxtag.org/2008/en/conf/events/vp-donnerstag/details.html?talkid=110
      TRUST2008:  
http://www.trust2008.eu/downloads/Keynote-Speakers/3_David-Grawrock_The-Front-Door-of-Trusted-Computing.pdf
      IDF 2008, Shanghai:  
http://inteldeveloperforum.com.edgesuite.net/shanghai_2008/aep/PROS003/index.html
      IDFs 2006, 2007 (I'm not sure if/where they are online)

Trusted Boot Project Overview:
=============================

Trusted Boot (tboot) is an open source, pre- kernel/VMM module that uses 
Intel TXT to perform a measured and verified launch of an OS kernel/VMM.

It is hosted on SourceForge at http://sourceforge.net/projects/tboot.

Tboot currently supports launching Xen (open source VMM/hypervisor w/ 
TXT support since v3.2), and now Linux kernels.  Linux support is 
provided in the latest (tboot-20081007) release.


Value Proposition for Linux or "Why should you care?"
=====================================================

While there are many products and technologies that attempt to measure 
or protect the integrity of a running kernel, they all assume the kernel 
is "good" to begin with.  The Integrity Measurement Architecture (IMA) 
and Linux Integrity Module interface are examples of such solutions.

To get trust in the initial kernel without using Intel TXT, a static 
root of trust must be used.  This bases trust in BIOS starting at system 
reset and requires measurement of all code executed between system reset 
through the completion of the kernel boot as well as data objects used 
by that code.  In the case of a Linux kernel, this means all of BIOS, 
any option ROMs, the bootloader and the boot config.  In practice, this 
is a lot of code/data, much of which is subject to change from boot to 
boot (e.g. changing NICs may change option ROMs).  Without reference 
hashes, these measurement changes are difficult to assess or confirm as 
benign.  This process also does not provide DMA protection, memory 
configuration/alias checks and locks, crash protection, or policy support.

By using the hardware-based root of trust that Intel TXT provides, many 
of these issues can be mitigated.  Specifically: many pre-launch 
components can be removed from the trust chain, DMA protection is 
provided to all launched components, a large number of platform 
configuration checks are performed and values locked, protection is 
provided for any data in the event of an improper shutdown, and there is 
support for policy-based execution/verification.  This provides a more 
stable measurement and a higher assurance of system configuration and 
initial state than would be otherwise possible.  Since the tboot project 
is open source, source code for almost all parts of the trust chain is 
available (excepting SMM and Intel-provided firmware).

Patchset:
========

These patches were tested on the 2.6.27-rc6 kernel and apply cleanly to 
2.6.27-rc9.

Patch 0a/3:  Overview and motivation (this email) Patch 0b/3:  Details 
and how it works
Patch 1/3:   Support for AddressRangeUnusuable ACPI memory type (already
             accepted but not in 2.6.27-rc9)
Patch 2/3:   Disable VT-d (Intel IOMMU) Protected Memory Regions (PMRs)
             (submitted to maintainer)
Patch 3/3:   Intel TXT and tboot support


Joseph Cihula
Shane Wang
Gang Wei
Intel Corp.