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-October/002228.html 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/133089.html 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 _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
