User: Password:
Subscribe / Log in / New account

It is about the keys, not the blob

It is about the keys, not the blob

Posted Apr 8, 2010 5:20 UTC (Thu) by jmorris42 (guest, #2203)
Parent article: Enabling Intel TXT in Fedora

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.

(Log in to post comments)

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 (subscriber, #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.
1. Verifying that the chipset is configured in such a way so that the system can actually deliver the on the security promises that it makes to the hypervisor it is about to launch.
2. Securely launching a hypervisor and measuring it.

"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."

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 find the arguments presented by the fedora folks flawed. This little blob is very much like a firmware blob. I also don't buy the idea that it will result in bug reports that can't be fixed. The SINIT module is so small and simple that if it used to work and stops working on a system it is because someone has not tickled the proper bits in some chipset registers. Its the code that launches SINIT modules job to make sure those are tickled. So the problem would either be in some open source component that is doing the launching or in the BIOS which is not Fedoras responsibility. The chances that the fault would actually be in the AC module is like 0.00000001%.

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 (subscriber, #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.

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