Weekly Edition
Return to the Security page
| |||||||||||||
Enabling Intel TXT in FedoraIntel'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 to operate. 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 system runs, 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 rootkits or 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
kernels.
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. (Log in to post comments)
It is about the keys, not the blob Posted Apr 8, 2010 5:20 UTC (Thu) by jmorris42 (subscriber, #2203) [Link]
Sorry, I wouldn't want this enabled unless I had the ability to put my own darned keys into the thing. At that point it would be less important if a closed blob were being used until an open one could be developed. But if we are being asked to depend on a closed blob AND will never be able to replace it then it is a useless feature.
It is about the keys, not the blob Posted Apr 8, 2010 5:30 UTC (Thu) by drag (subscriber, #31333) [Link]
I can see that. Makes sense.
I want the keys to my own locks, thank you very much.
Would it be possible to have support for similar technology in something like 'Coreboot'?
This sort of thing would still be a boon for people using Linux in hardened devices. Also it can potentially be a effective combat against rootkits; which is currently a very unsolved problem.
It is about the keys, not the blob Posted Apr 19, 2010 13:44 UTC (Mon) by robbe (guest, #16131) [Link]
Vendors of appliances containing Linux would love this technology. Think not only video recorders, also home network routers, firewalls, any set-top box, etc. As usual this will not only protect the device owner against evil attackers, but also the vendor against "attacks" from the device owner.
This is done currently for some devices, but because it is quite a technical feat, only happens for the things sold in big numbers. For these jailbreaking is worth the effort. A fear that this becoming Linux mainstream means that every mom&pop appliance based on Linux will use the technology. Jailbreaking every one of them is a big hassle -- c.f. the efforts spent on patching DVD readers to be region-free.
I think the only acceptable use of this is if buying a device means you get the device key shipped as well.
It is about the keys, not the blob Posted Apr 8, 2010 9:40 UTC (Thu) by Darkmere (subscriber, #53695) [Link]
I see it as a two part thing.
I wouldn't want it for the "deny executability" part. However "boot not messed with" is really interesting for the case of encrypted drives.
Having a big red flag pop up and wave a lot when the hardware/Bootloader has been messed with, _before_ I enter passphrase /plug in USB-key, would be a very nice thing.
It is about the keys, not the blob Posted Apr 15, 2010 13:59 UTC (Thu) by jarrett.miller (guest, #60765) [Link]
First, sorry jmorris42 this is not actually in comment to your post. I just could not figure out how to make a new top level comment.
--------- Now that that is out of the way I want to note that in my opinion this article is filled with errors. Does the author or the Fedora folks even understand how TXT works?
"By looking at all of the code that the system runs, 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"
For example this is flat out wrong. This statement is describing "classical" trusted computing. You know the thing that has been around since the late 90's. TXT is an attempt to correct the problems with that approach. Anyway what makes this statement incorrect is that TXT is not concerned with validating all that stuff. It is only concerned with doing two things.
"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'tand hasn't."
I also have issue with this. It is actually fairly clear why things are the way they are. Let me explain. To understand this you must understand what the SINIT AC module is and what it does. The entire job of the SINIT module is to verify proper chipset configuration as I listed as step 1 above. Thats it. Thats all it does. Nothing more nothing less. This is not some evil thing that locks you out of your system. It is just a check to make sure that the chipset is configured in such a way that the system can honor the promises that it makes to the hypervisor that is about to be launched. That is why there is one SINIT module per chipset. By its very definition it has to be chipset specific.
About "security through obscurity": I think that is an unfair accusation. If you go look at a SINIT module it is just a blob of normal binary code. It is not obfuscated or encrypted. You can dump it in any dissembler and look at it. If you have done this you will notice that the thing is probably written in assembler anyway (does not look like compiled C code). Its super simple. It just runs through a bunch of checks on chipset registers.
Now its time to talk about why you can't have an open source one. The first problem is that much of Intels chipsets are sadly undocumented. They only share the full docs with "special partners" aka BIOS source code vendors (Phoenix, AMI, insyde, etc..). Personally I hate this fact but until they change it your not going to be able to write your own SINIT module. Secondly the entire TXT system is based on the CPU being able to verify the authenticity of the SINIT module. To understand this you need to understand how the system works.
How it works: Again the entire point of TXT is to launch a hypervisor and give that hypervisor some garuntees about the state of the system when control is transferred to the hypervisor. So some software (ex a booted Linux system) loads the SINIT module and a TXT enabled hypervisor in to memory. Then the loading software executes the GETSEC[SENTER] instruction passing these two addresses as arguments. Then some hardware voodoo happens (sort of like a power reset but not quite) and all CPUs but one are halted in a safe way. Then the SINIT module is copied in to some special memory in the CPU (where no one can mess with it externally) and it is measured via TPM. Its digital signature is checked. The public key is burned in to the chipset so the CPU grabs that public key to verify the authenticity of the module. Then the AC module is executed to check all those chipset registers to make sure its safe to call the hypervisor. Then the hypervisor is measured via TPM and control is transferred to it. Thats all TXT is. end of story.
So you can't have your own keys for the SINIT module. I hope its obvious why that is the case.
So the idea behind TXT is that from a security perspective the only thing you need to "trust" (and here I use that in the human sense as in I trust intel not to get this wrong) is the SINIT module. It is the "root of trust". This is actually a big step forward from how trusted computing used to be where you had to trust the BIOS. I don't know if you have ever worked on BIOS code but it is a real mess. I have personally worked with Phoenix, AMI, and and an old EFI (original Itanium). They are a mess and no one should "trust" them in this way. They are just to hard to verify as they do all sorts of crazy stuff and are just to big to be a good "root of trust". But with TXT you just have to trust that little SINIT module.
This is a big step forward. You no longer need to trust and verify thousands of different customized BIOS images. You just have to trust and verify one SINIT module per chipset in existence.
-------
I hope this clears up some of the misunderstandings about TXT.
It is about the keys, not the blob Posted Apr 15, 2010 17:17 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
the thing is that without the source for the SINIT blob (and the ability to verify that the binary matches the source), it is very hard to validat that it is as simple as you claim it is.
it may very well be that simple, but if all you have to go by is the decompiled binary, that's not an easy thing to verify.
It is about the keys, not the blob Posted Apr 15, 2010 22:53 UTC (Thu) by jarrett.miller (guest, #60765) [Link]
I don't understand. What is it you want to verify about the SINIT module? You either trust it or you do not. I don't know about you but I find it easier to trust the SINIT module than the BIOS image.
Do you demand the source code for the cpu microcode update file? A microcode update is the most similar thing to the SINIT module. It is also distributed in binary only format and its also signed with an Intel owned key. Its purpose is also the same. To provide the required semantics of the ISA. I think its best to think of the SINIT module as a special microcode file required to support the semantics of the GETSEC instruction.
I guess I just don't understand all the hate and fear of TXT and the SINIT module. I mean there are far worse things in the Linux ecosystem. Its not a binary blob deamon like the one required by the 3945 Wifi chipset. Its not a binary only driver that hangs around the entire time the kernel is up. Its important to remember that the SINIT module is designed to terminate. Its not some background thing that spies on people or something. It just executes and it either terminates with an error code related to how the chipset is currently configured or it transfers control to your own code after having made sure the chipset is properly configured.
Imagine if you had to load binary blob microcode file to spawn virtual machine using VT-x. If that was required would Fedora refuse to ship KVM? As far as I am concerned this hypothetical scenario is the same thing as TXT and the SINIT module.
It is about the keys, not the blob Posted Apr 15, 2010 22:59 UTC (Thu) by nix (subscriber, #2304) [Link] Do you demand the source code for the cpu microcode update file?Well, where microcode update files are concerned, I just want a changelog, but Intel don't even give us that.
Enabling Intel TXT in Fedora Posted Apr 8, 2010 7:30 UTC (Thu) by michaeljt (subscriber, #39183) [Link] > 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.Since most CPU features are well documented, it is possible to test them quite extensively to see if they work as they should, although if the manufacturer is sneaky enough they could probably still hide something nasty. Hopefully someone would still notice at some point. Is it possible to test the blob in the same way? And I wonder how long it will take until someone (Redhat sponsored?) reverse engineers the blob à la Nouveau.
Enabling Intel TXT in Fedora Posted Apr 8, 2010 9:02 UTC (Thu) by Trou.fr (subscriber, #26289) [Link]
As you point out, _most_ of the CPU features are documented. Many others are not, and nothing prevents Intel from adding a backdoor in the CPU, which of course you would not detect by "testing" the documented features. Hardware trust is a very complicated problem.
Enabling Intel TXT in Fedora Posted Apr 8, 2010 15:52 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]
While I really don't want to rely on yet more non-free code, I'm not sure how this is qualitatively different from the way Linux normally relies on a non-free BIOS (or other platform firmware). With ACPI methods the kernel does at least get to interpret and limit what the code does, but SMM is a black box that the kernel has no control over at all (not even to disable it altogether).
Enabling Intel TXT in Fedora Posted Apr 8, 2010 20:54 UTC (Thu) by gmaxwell (subscriber, #30048) [Link]
One non-trivial qualitative difference is that this is _new_ and that Linux vendors have gained (/are gaining) the market power to push back against these blobbish approaches. That other things are bad isn't really a rational reason to reject adding a new thing which is just as bad: It's a lot easier to avoid incorporating a new thing than it is to go and replace the existing stuff.
Perhaps more fundamentally this kind of functionality, if widely deployed, risks fundamentally changing how things work for users and distributors alike.
For example, if a network service you use begins requiring systems to attest that they are running one of a finite set of 'approved' kernels then you lose the freedom to load customized kernels without giving up those services, developers lose some of their testing freedom since users won't run test builds, and your distributor loses the ability to rapidly push updates without worrying about breaking users.
Of course you could counter that market forces will temper that kind of lock-down. But I think thats far from clear. While the cost of lock-down is that every user, every developer, and every distributor loses freedom only fairly few of the users will _notice_ the lost of freedom, and half the time they'll attribute problems to the developers/distribution changing things. Developers/distributors are just along for the ride, they can't tell their users "well don't use service XX" and expect many of the users to listen.
So it doesn't seem clear to me that the market demand will be strongly connected to the actual harm that could result from the widespread use of TXT.
And, of course, it's sensible to talk about preserving freedom in this context: Freedom is one of fedora's core values.
I think it's most interesting to note that keeping attestation _out_ of the default install is probably completely effective against building a widespread expectation that attestation is available, yet keeping it out of the default install would do little to harm advanced users whom want to take advantage of some of the few user friendly uses for this technology.
Perhaps you think that the concerns about remote attestation ultimately removing the freedom from our free software are a bit far out but the fact that I can seriously raise them is an important qualitative difference between TXT and things like SMM.
Enabling Intel TXT in Fedora Posted Apr 19, 2010 14:36 UTC (Mon) by robbe (guest, #16131) [Link]
> Of course— you could counter that market forces will temper that kind
> of lock-down.
Sure. There's also nobody buying closed cellphones...
If the legitimate security concern is really all there is to it (I doubt it), I think this scheme could work:
Connecting to the internet is only allowed if you buy mandatory insurance (as is done for cars). The insurance has to pay out if your device harms the network (DoS, Spam, Worm, whatever). Rational insurers can ask lower premiums for operating systems and/or configurations that they found to be less risky. That you really run this configuration could be enforced contractually, or even via this fancy remote attestation. Other models are lower/increasing premiums according to a user's incidence record.
|
|||||||||||||