User: Password:
|
|
Subscribe / Log in / New account

enable CONFIG_INTEL_TXT

From:  Eric Paris <eparis-H+wXaHxf7aLQT0dZR+AlfA-AT-public.gmane.org>
To:  kernel-TuqUDEhatI4ANWPb/1PvSmm0pvjS0E/A-AT-public.gmane.org
Subject:  enable CONFIG_INTEL_TXT
Date:  Wed, 31 Mar 2010 16:40:01 -0400
Cc:  gcwilson-r/Jw6+rmf7HQT0dZR+AlfA-AT-public.gmane.org, sds-+05T5uksL2qpZYMLLGbcSA-AT-public.gmane.org
Archive-link:  Article, Thread

Long ago we were ask to enable CONFIG_INTEL_TXT in the fedora kernels by
a large user, the US National Security Agency:

http://lists.fedoraproject.org/pipermail/kernel/2009-Octo...

At the time the objection to this configuration option was that the
technology was all predicated on a closed source binary blob signed by
Intel.  In private discussions it was learned that there was no chance
that the module would ever be open sourced and we learned that hardware
is not capable of recognizing signatures of a module from other vendors
(aka Fedora can't sign our own version.)  However, in light of a recent
public statement from IBM:

http://lists.fedoraproject.org/pipermail/devel/2010-March...

We see that at least one hardware vendor has been listening to our
objections to closed source software and has agreed to re-architect how
they implement their systems so that our users will not need to download
and install any closed source proprietary software.  They agreed to make
any changes necessary to their BIOS (UEFI) to support this technology
without the need for the separate closed source proprietary Intel signed
blob.  Red Hat has ask other hardware vendors to follow the admirable
lead set by IBM if they have any interest in being supported by the open
source community.

At this point we know that we have hardware vendors, software vendors,
and users all asking for the enablement of this technology.  So the
question become why should we enable CONFIG_INTEL_TXT and what do we
get?  What do we lose?

By itself enabling TXT gets us nothing except a small chuck of dead code
in the kernel.  But it allows us and our customers to build new
solutions with new security goals in mind which are not possible today.
This config option allows a user to download new (open source) software
(tboot) along with other third party software to verify the correctness
of the BOOTED system.  This allows us to build future solutions such as
utilizing the TPM chip in many laptops to harden the disk encryption
key.  It can be used as root of trust for the verification of the
software originally loaded on a machine before it is allowed network
access (aka machines with a rootkit couldn't get on the network.)  The
technology can also be extended to provide usefulness to system
integrity checkers like aide or IMA for tamper proof software integrity
logging.  These are all things which are impossible to do with today's
kernels.

We don't really lose anything except a bit of code in the kernel.
Unless the user specifically installs tboot the kernel code will sit
dormant.  It has no implications on AMD processors.  If the user does
install tboot and their hardware supports this technology (like this
future generation of IBM system X products mentioned above) they will
get a root of trust which can be used to build other solutions.  Some of
those potential solutions will hopefully be available someday in Fedora
if a user wishes to activate them (and we can overcome the management
burden they will seemingly place upon the user), but we cannot get there
without starting here.

This is the beginning.  It is the first step to allow users to use other
open source software which will give them a root of trust.  But remember
the config options does nothing unless a user takes those very clear
active steps.

Are there any objections to enabling CONFIG_INTEL_TXT on x86_64?

-Eric


(Log in to post comments)


Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds