Intel's Trusted Execution Technology (TXT) has always been somewhat
controversial because it enables the complete lockdown of a computer system.
For the DRM-loving crowd, that is seen as a feature, of course, but others,
who might want to make their own choices about what code runs on their
hardware, do not see it quite the same way. TXT was added to Linux in
2.6.32, without much in the way of complaints—though there were some concerns about protests—now Fedora is discussing whether to enable it for
its kernels. The sticking point is not the DRM-lockdown that TXT allows,
but is, instead, the fact that it requires an opaque binary "blob" in order
TXT is a means for ensuring that the code running on a system is what is
intended to be run there. By looking at all of the code that the
including things like BIOS, option ROMs, the bootloader, the kernel, and
the initrd image,
TXT can determine whether any of that code or data has been altered. The
idea is to protect the integrity of the system as a whole, and to thwart
offline attacks, such as swapping in a new hard disk or BIOS for systems
like voting machines, medical devices, or ATMs.
As mentioned, though, it can also be used to ensure that only code signed
by some authority is allowed to run on the device. For ATMs, that's
probably a good thing, but if it becomes widespread, it could become a
serious impediment to freedom.
As described in an article from a year ago, there
are two separate components that collaborate to provide the TXT integrity
checking: the tboot
"trusted boot" hypervisor and an Authenticated Code Module. The latter,
often referred to as the "SINIT AC", is distributed as a binary-only
object, which is signed by Intel.
Because there is no source available for SINIT AC—even if there were,
without Intel's keys users couldn't build and use their own—some
Fedora developers are leery of enabling TXT in Fedora kernels. Stephen
Smalley's request to enable TXT, which he
sent to the fedora-kernel list
in October 2009 shortly after TXT was added to the kernel, was quickly
shot down. Eric Paris explained:
After some discussion with a couple of people on the Fedora kernel team
on IRC they decided that we should not enable CONFIG_INTEL_TXT until it
is useful for something other than a closed source binary blob which
Fedora is unable to distribute. We have messaged that Fedora was unable
to include the binary blob from Intel and it has been suggested that
they create an open module rather than forcing Linux users to trust some
part of their system security to an unknown binary blob. Hopefully you
can add your weight to that discussion and help intel see the need for
an open source blob.
More recently, IBM has agreed to move the blob into the BIOS of its xSeries
servers. That would alleviate the problem of needing to ship a binary blob
to make TXT work—though it does nothing to open up the code, of
course. But, that announcement led Paris
to reopen the discussion on enabling TXT. In a fairly long message, he lays out the case for enabling the
feature. Because xSeries users will be able to use TXT without installing
the Intel blob, he sees it as a desirable feature for Fedora:
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
But Fedora engineering manager Tom "spot" Callaway is less enthusiastic.
He notes that IBM is just taking the same
binary blob and stuffing it into the BIOS. He is also concerned about
supporting Fedora users:
For the rest of the x86/x86_64 computing universe, this means binary
blobs, and I think you're fooling yourself if you think that all the
other hardware vendors will be so willing to shove prebuilt code from a
third party into their BIOS (or even have room to do so).
In the non-IBM Xseries case (which is by far, the more common one for
Fedora), we would be enabling this option solely to enable proprietary
binary blobs during the boot process. In my opinion, given that it is
not possible at all for us to troubleshoot or bug fix systems in such a
scenario, we should not imply to our userbase that it is supportable by
enabling this kernel option.
Smalley thinks that getting TXT into Fedora
would allow more testing, but
Callaway isn't convinced that's necessarily
a good thing:
We enable this in Fedora. This sends a message to Fedora's users that
altering their bootup configuration to support SINIT (whether loaded
from BIOS or from a binary-only blob that Intel will be so happy to
provide) is _Supported_.
And then, it breaks. And we get bugs filed. Which we have absolutely 0
chance of being able to fix.
Others see the SINIT AC blob as no different than the firmware blobs that are required to
make various hardware function—and are shipped by Fedora. Callaway
counters that the firmware "is the only way to enable that
hardware to work." But, as Chris Wright points out, that leads to an inconsistency: "And TXT needs SINIT AC to work.
It's just inconsistent reasoning."
If the proposal were to distribute SINIT AC with Fedora, the situation
would be more "analogous", Callaway said, "but Intel already tried that, and it
doesn't meet the strict guidelines we have defined in Fedora for what is
considered acceptable firmware". Red Hat has apparently tried to
convince Intel to open up the SINIT AC code, but without success.
The core difference, at least in Callaway's mind, seems to be that users will be
depending on this code, which they cannot inspect, for the security of
their systems. Faulty firmware for other hardware may make the system
unstable or fail entirely, but that firmware isn't vouching for the
security of the whole system as the SINIT AC does. TXT "requires that we explicitly trust a third party
vendor for security. [...] This makes me extremely uncomfortable, and also makes me wonder why the
NSA seems comfortable with such a scenario in practice."
Callaway is referring to the US National Security
Agency (NSA), which is where Smalley works. But, as Smalley points out, adding TXT doesn't really change
anything: "And you were already dependent on Intel for correct
operation of their hardware. Nothing new to see here, move along..."
Red Hat's James Morris, who seems a bit surprised that the TXT code made it
into the kernel without any ACKs from the security subsystem folks, is also
a bit concerned about the secrecy
surrounding the code: "I really hope the secrecy of the AC module is not part of its security
design." He also noted that bugs in the SINIT AC were recently used
to break TXT, but he doesn't see any technical barriers to enabling it in
the Fedora kernel. The security of TXT is not reliant on "keeping the
SINIT module closed source", according to Smalley, but Intel
"adamantly" refuses to open source it, Callaway said.
It's not clear why Intel is being so secretive, nor why there isn't support
for other signing keys on AC modules. That, at least, would allow others to
potentially create alternative AC modules. Intel may believe that
"security through obscurity" will help prevent exploits, though there is
good reason to believe that it won't—and hasn't.
No conclusion was reached in the thread, though one would guess that
Callaway's opinions would carry a fair amount of weight. Had Intel
originally placed SINIT AC in the BIOS, rather than providing it as a
separate—and separately upgradable—component, it seems likely
that this issue would not have reared its head. Certainly users who really
want TXT support can build their own kernels, as was suggested, but then
they will be on their own for support. That may not be much of an issue
for Fedora users, who don't have much of a support plan beyond what the
distribution provides, but it will affect RHEL users—and that may be
the real target of this effort.
Depending on hardware vendors for security solutions is not without
pitfalls, but we are already dependent on them for the correct functioning
of our systems, which includes security. It's a question of how far one
wants to follow the rabbit hole. Until there are fully free hardware
solutions, there will always be hardware dependencies. Its hard to imagine
that RHEL, at least, doesn't get TXT support at some point; Fedora would
make a good testbed for that support.
to post comments)