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.
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
* Pavel Machek ([email protected]) 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
On Thu 2008-10-09 10:44:27, Chris Wright wrote:
> * Pavel Machek ([email protected]) 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
* Pavel Machek ([email protected]) 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
On Thu 2008-10-09 11:14:51, Chris Wright wrote:
> * Pavel Machek ([email protected]) 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
> From: [email protected] [mailto:linux-kernel-
> [email protected]] 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 ([email protected]) 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
* Pavel Machek ([email protected]) 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.
> > > > 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
> From: Pavel Machek [mailto:[email protected]]
> 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