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
On 03/31/2010 04:40 PM, Eric Paris wrote:
Are there any objections to enabling CONFIG_INTEL_TXT on x86_64?
We don't traditionally enable kernel config options for functionality that we have no intention (or capacity) to natively support in Fedora.
Seeing as how Fedora has no plans to utilize TPM, I don't think we should take this action, as it would merely imply a level of support for this functionality that we will not be able to provide.
Given that users who wish to use INTEL_TXT will need to make other customizations to their system environment in order to use it, I don't see why they can't make a custom kernel to go with it.
I'm of the opinion that we shouldn't be enabling "dead code" chunks at random, especially not in situations like this where the primary use is to encourage vendor utilization of closed source binary blobs or trusting a hardware vendor in matters of encryption.
~spot
On Wed, 2010-03-31 at 16:43 -0400, Tom "spot" Callaway wrote:
On 03/31/2010 04:40 PM, Eric Paris wrote:
Are there any objections to enabling CONFIG_INTEL_TXT on x86_64?
We don't traditionally enable kernel config options for functionality that we have no intention (or capacity) to natively support in Fedora.
But we have both the intention and hopefully the capacity to make this easily used by some people if they so chose. But this is step one. I'm willing to bet that we will see tboot submitted as a Fedora package after this first step is overcome. A TPM hardened disk encryption key is something which is interesting and which I hope to be able to work on.
Seeing as how Fedora has no plans to utilize TPM, I don't think we should take this action, as it would merely imply a level of support for this functionality that we will not be able to provide.
Fedora ALREADY utilizes the TPM. Maybe you missed that. Take a look at the TPM drivers and IMA in kernel along with trousers and tpmdd in userspace.
Given that users who wish to use INTEL_TXT will need to make other customizations to their system environment in order to use it, I don't see why they can't make a custom kernel to go with it.
There is a huge difference between installing a userspace RPM and rebuilding a kernel. Although not insurmountable it is silly to provide tools to make use of TXT (trousers which we ALREADY HAVE in fedora) but not allow our users to turn it on.
I'm of the opinion that we shouldn't be enabling "dead code" chunks at random, especially not in situations like this where the primary use is to encourage vendor utilization of closed source binary blobs
what are these binary blobs of which you speak? I thought this was well covered. No binary blobs.
or trusting a hardware vendor in matters of encryption.
So I should assume that Fedora has a policy against the new Intel AES instructions? That's going to be interesting.
On 03/31/2010 05:06 PM, Eric Paris wrote:
what are these binary blobs of which you speak? I thought this was well covered. No binary blobs.
As long as you buy certain brand new IBM X-series servers.
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.
If a user is so motivated to do so, then they're free to build a custom kernel to enable CONFIG_INTEL_TXT, and it will be even more clear to them that it is not something they should expect Fedora to support.
~spot
On Thu, 2010-04-01 at 09:25 -0400, Tom "spot" Callaway wrote:
On 03/31/2010 05:06 PM, Eric Paris wrote:
what are these binary blobs of which you speak? I thought this was well covered. No binary blobs.
As long as you buy certain brand new IBM X-series servers.
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).
[citation needed]
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.
Can you troubleshoot issues when the DMAR ACPI tables are wrong? Can you troubleshoot anything in BIOS? In much the same way when problems present themselves users have to talk to their hardware vendors to get the fixes for hardware problems. If those users contact us with problems we (ok, I who already supports numerous other subsystems in the Fedora and upstream kernel) may be able to help get them connected with the right groups committed to fixing the problems. It's no different than how we have members of the Fedora community who support DMAR and when BIOS/hardware problems come up he is able to help get the right people connected to fix the problems. This is how we support hardware features and this is a hardware feature. The logical conclusion of your supportability argument is clearly silly where we must disable everything that relies on any kind of firmware.
Intel made a mistake (in my mind) by releasing this technology with the SINIT AC module only in a userspace package loaded by the boot loader. They thought a userspace design would make the distribution of updates easier for their customers (and it probably will). They should have done what they are suggesting now: put enough in the BIOS to make the system work, but let users make later changes if they so choose.
-Eric
On Wed, 2010-03-31 at 17:06 -0400, Eric Paris wrote:
On Wed, 2010-03-31 at 16:43 -0400, Tom "spot" Callaway wrote:
On 03/31/2010 04:40 PM, Eric Paris wrote:
Are there any objections to enabling CONFIG_INTEL_TXT on x86_64?
We don't traditionally enable kernel config options for functionality that we have no intention (or capacity) to natively support in Fedora.
But we have both the intention and hopefully the capacity to make this easily used by some people if they so chose. But this is step one. I'm willing to bet that we will see tboot submitted as a Fedora package after this first step is overcome. A TPM hardened disk encryption key is something which is interesting and which I hope to be able to work on.
Seeing as how Fedora has no plans to utilize TPM, I don't think we should take this action, as it would merely imply a level of support for this functionality that we will not be able to provide.
Fedora ALREADY utilizes the TPM. Maybe you missed that. Take a look at the TPM drivers and IMA in kernel along with trousers and tpmdd in userspace.
Given that users who wish to use INTEL_TXT will need to make other customizations to their system environment in order to use it, I don't see why they can't make a custom kernel to go with it.
There is a huge difference between installing a userspace RPM and rebuilding a kernel. Although not insurmountable it is silly to provide tools to make use of TXT (trousers which we ALREADY HAVE in fedora) but not allow our users to turn it on.
Just to reinforce this point: Building a custom kernel is simply not an option for many users, whether due to evaluation and accreditation requirements, getting support, or whatever. Whereas installing additional userspace and performing configuration of system is much more feasible. Disabling the kernel option precludes use of this functionality for many users who could otherwise make use of it.
I'm of the opinion that we shouldn't be enabling "dead code" chunks at random, especially not in situations like this where the primary use is to encourage vendor utilization of closed source binary blobs
what are these binary blobs of which you speak? I thought this was well covered. No binary blobs.
or trusting a hardware vendor in matters of encryption.
So I should assume that Fedora has a policy against the new Intel AES instructions? That's going to be interesting.
On 04/01/2010 09:31 AM, Stephen Smalley wrote:
Just to reinforce this point: Building a custom kernel is simply not an option for many users, whether due to evaluation and accreditation requirements, getting support, or whatever. Whereas installing additional userspace and performing configuration of system is much more feasible. Disabling the kernel option precludes use of this functionality for many users who could otherwise make use of it.
Yes, but people who have those restrictions are far more likely to be doing those operations on RHEL, as opposed to Fedora.
~spot
On Thu, 2010-04-01 at 09:52 -0400, Tom "spot" Callaway wrote:
On 04/01/2010 09:31 AM, Stephen Smalley wrote:
Just to reinforce this point: Building a custom kernel is simply not an option for many users, whether due to evaluation and accreditation requirements, getting support, or whatever. Whereas installing additional userspace and performing configuration of system is much more feasible. Disabling the kernel option precludes use of this functionality for many users who could otherwise make use of it.
Yes, but people who have those restrictions are far more likely to be doing those operations on RHEL, as opposed to Fedora.
I suspect you'll find that even many Fedora users are loathe to build a custom kernel. I doubt the participants in this discussion (or even subscribers to this list) constitute the typical Fedora user.
In any event, while I'd prefer that the config option be enabled in both Fedora and RHEL, I'd take the latter if that were the only option. But is it really likely that RHEL will enable a kernel config option if it isn't enabled first in Fedora?
On 04/01/2010 10:04 AM, Stephen Smalley wrote:
In any event, while I'd prefer that the config option be enabled in both Fedora and RHEL, I'd take the latter if that were the only option. But is it really likely that RHEL will enable a kernel config option if it isn't enabled first in Fedora?
In a situation where Fedora is unlikely to provide any useful testing, it has been known to happen.
~spot
On Thu, 2010-04-01 at 10:06 -0400, Tom "spot" Callaway wrote:
On 04/01/2010 10:04 AM, Stephen Smalley wrote:
In any event, while I'd prefer that the config option be enabled in both Fedora and RHEL, I'd take the latter if that were the only option. But is it really likely that RHEL will enable a kernel config option if it isn't enabled first in Fedora?
In a situation where Fedora is unlikely to provide any useful testing, it has been known to happen.
Hmmm...well, there would be testing of it in Fedora if it were enabled there.
On 04/01/2010 10:14 AM, Stephen Smalley wrote:
On Thu, 2010-04-01 at 10:06 -0400, Tom "spot" Callaway wrote:
On 04/01/2010 10:04 AM, Stephen Smalley wrote:
In any event, while I'd prefer that the config option be enabled in both Fedora and RHEL, I'd take the latter if that were the only option. But is it really likely that RHEL will enable a kernel config option if it isn't enabled first in Fedora?
In a situation where Fedora is unlikely to provide any useful testing, it has been known to happen.
Hmmm...well, there would be testing of it in Fedora if it were enabled there.
By whom exactly? I don't doubt that the NSA could test it, but surely, they are both capable and qualified to build a custom kernel and equally unlikely to push Fedora for certification (nor could they purchase support for it from Red Hat).
Here is my core concern:
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.
Then we get to say "what you've done is unsupported, even though we enabled a config option in the kernel that does nothing but enable the way you've setup your system."
Or, far more likely, no one in Fedora, outside of a few people at the NSA testing behind closed doors, ever uses this. The enablement of this config option in Fedora is used to justify the stability of the technology, and subsequent enablement in RHEL. And then Red Hat is on the hook for truly supporting something that they have no realistic chance of being able to support, when it breaks. Then the powers-that-be ask me why we enabled this in Fedora, and what testing we did?
*****
At its core, we're being asked to enable functionality for the sole purpose of supporting a chunk of proprietary software, in a configuration that 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.
~spot
On Thu, Apr 01, 2010 at 10:22:51AM -0400, Tom spot Callaway wrote:
At its core, we're being asked to enable functionality for the sole purpose of supporting a chunk of proprietary software, in a configuration that requires that we explicitly trust a third party vendor for security.
Isn't that what we do with kernel-firmware? :-)
Cheers, Don
* Tom spot Callaway (tcallawa@redhat.com) wrote:
On 04/01/2010 11:34 AM, Don Zickus wrote:
Isn't that what we do with kernel-firmware? :-)
And microcode updates and BIOS calls...
Yes, but we only do that because it is the only way to enable that hardware to work.
Some of which is obscure hardware. And TXT needs SINIT AC to work. It's just inconsistent reasoning.
thanks, -chris
On 04/01/2010 11:58 AM, Chris Wright wrote:
- Tom spot Callaway (tcallawa@redhat.com) wrote:
On 04/01/2010 11:34 AM, Don Zickus wrote:
Isn't that what we do with kernel-firmware? :-)
And microcode updates and BIOS calls...
Yes, but we only do that because it is the only way to enable that hardware to work.
Some of which is obscure hardware. And TXT needs SINIT AC to work. It's just inconsistent reasoning.
I don't agree that enabling a specific chunk of proprietary software in an unsupportable configuration is the same thing as including firmware which enables hardware functionality.
Now, if you were arguing for us to include the SINIT blob, maybe that would be closer to analogous, but Intel already tried that, and it doesn't meet the strict guidelines we have defined in Fedora for what is considered acceptable firmware.
~spot
* Tom spot Callaway (tcallawa@redhat.com) wrote:
On 04/01/2010 11:58 AM, Chris Wright wrote:
- Tom spot Callaway (tcallawa@redhat.com) wrote:
On 04/01/2010 11:34 AM, Don Zickus wrote:
Isn't that what we do with kernel-firmware? :-)
And microcode updates and BIOS calls...
Yes, but we only do that because it is the only way to enable that hardware to work.
Some of which is obscure hardware. And TXT needs SINIT AC to work. It's just inconsistent reasoning.
I don't agree that enabling a specific chunk of proprietary software in an unsupportable configuration is the same thing as including firmware which enables hardware functionality.
How is device firmware or BIOS problem supportable? To me, this reasoning would lead straight to e.g. "# CONFIG_EFI is not set"
thanks, -chris
On Thu, 2010-04-01 at 10:22 -0400, Tom "spot" Callaway wrote:
On 04/01/2010 10:14 AM, Stephen Smalley wrote:
On Thu, 2010-04-01 at 10:06 -0400, Tom "spot" Callaway wrote:
On 04/01/2010 10:04 AM, Stephen Smalley wrote:
In any event, while I'd prefer that the config option be enabled in both Fedora and RHEL, I'd take the latter if that were the only option. But is it really likely that RHEL will enable a kernel config option if it isn't enabled first in Fedora?
In a situation where Fedora is unlikely to provide any useful testing, it has been known to happen.
Hmmm...well, there would be testing of it in Fedora if it were enabled there.
By whom exactly? I don't doubt that the NSA could test it, but surely, they are both capable and qualified to build a custom kernel and equally unlikely to push Fedora for certification (nor could they purchase support for it from Red Hat).
By the same crazy crowd that is already interested in using the TPM, IMA, trousers etc which are already part of Fedora. Not all of whom care to build a custom kernel and some of whom are willing to use Fedora in production. Unless you're willing to state that the Fedora user community is limited to kernel hackers and no one would ever use Fedora in production "eat your brane [sic]" then I don't think you can take the "just let them build their own kernel" position.
Here is my core concern:
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.
Then we get to say "what you've done is unsupported, even though we enabled a config option in the kernel that does nothing but enable the way you've setup your system."
How is this truly different than microcode updates, firmware updates, etc? Enabling the option enables use of the TXT hardware feature if the user so chooses. Nothing more. And if it breaks, they get to keep both parts. Do you really think (and if so, why) that it will be harder to diagnose failures and assign blame properly for this situation than for buggy microcode or firmware?
Or, far more likely, no one in Fedora, outside of a few people at the NSA testing behind closed doors, ever uses this. The enablement of this config option in Fedora is used to justify the stability of the technology, and subsequent enablement in RHEL. And then Red Hat is on the hook for truly supporting something that they have no realistic chance of being able to support, when it breaks. Then the powers-that-be ask me why we enabled this in Fedora, and what testing we did?
At its core, we're being asked to enable functionality for the sole purpose of supporting a chunk of proprietary software, in a configuration that 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.
You're being asked to enable support for a hardware feature that some users want to use. And you were already dependent on Intel for correct operation of their hardware. Nothing new to see here, move along...
On Wed, 2010-03-31 at 16:43 -0400, Tom "spot" Callaway wrote:
I'm of the opinion that we shouldn't be enabling "dead code" chunks at random, especially not in situations like this where the primary use is to encourage vendor utilization of closed source binary blobs or trusting a hardware vendor in matters of encryption.
I'm... slightly uncomfortable with this line of argument.
I have a little trouble distinguishing the TXT use case from hardware passwords on hard drives. It's an ATA feature; hdparm has support for it. It depends on an implementation that's buried in the drive's firmware, and you'd hope a competent vendor would have some quantity of encryption involved with it to defeat obvious physical attacks. Normal people never use it, but we've enabled them to do so, and they get to keep both pieces.
Or another analogy: AES-NI processors almost certainly have some amount of it implemented in microcode. Should we refuse to upload microcode updates for them?
I think it's a goofy feature, and I think anyone who actually trusts Intel's measurement firmware's resistance to attack is out of their mind. But I have difficulty coming up with a dogmatic argument against it.
- ajax
On Wed, 2010-03-31 at 16:40 -0400, Eric Paris wrote:
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.
I'm not reading that from the IBM message you linked. Do you have some other source for this statement?
- ajax
On Wed, 2010-03-31 at 16:46 -0400, Adam Jackson wrote:
On Wed, 2010-03-31 at 16:40 -0400, Eric Paris wrote:
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.
I'm not reading that from the IBM message you linked. Do you have some other source for this statement?
George and I actually say the same thing, I'm just not using lots of TLA's nor am I being quite as precise about my language :). The TXT technology exists to create a TCG compliant DRTM which is how you get my translation. Hopefully George will confirm that if not the precision of the language the the gist and meaning of my interpretation is correct.
-Eric
On Wed, 31 Mar 2010, Eric Paris wrote:
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.
My feeling is that this needs to be dealt with upstream, and that the open source tboot needs to be delivered first.
Are there any objections to enabling CONFIG_INTEL_TXT on x86_64?
Yes.
- We should be doing kernel development upstream unless there's an extraordinary reason not to (typically, following a request from Linus).
- We should not be adding kernel infrastructure to support proprietary, closed source
- Especially so, given that this is a security feature
I'd love to see support for TXT -- I think we can do some very important things with it, but I don't think it's workable as open source if it depends on closed proprietary code.
- James
On Wed, Mar 31, 2010 at 11:51 PM, James Morris jmorris@namei.org wrote:
On Wed, 31 Mar 2010, Eric Paris wrote:
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.
My feeling is that this needs to be dealt with upstream, and that the open source tboot needs to be delivered first.
Are there any objections to enabling CONFIG_INTEL_TXT on x86_64?
Yes.
- We should be doing kernel development upstream unless there's an
extraordinary reason not to (typically, following a request from Linus).
What?
This is not a about adding non upstream code to the kernel but enabling a config option.
So I don't really get what you are saying ...
On Thu, 2010-04-01 at 08:51 +1100, James Morris wrote:
On Wed, 31 Mar 2010, Eric Paris wrote:
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.
My feeling is that this needs to be dealt with upstream, and that the open source tboot needs to be delivered first.
Done and done. We are turning on an upstream config option.....
Are there any objections to enabling CONFIG_INTEL_TXT on x86_64?
Yes.
- We should be doing kernel development upstream unless there's an extraordinary reason not to (typically, following a request from Linus).
Done...
- We should not be adding kernel infrastructure to support proprietary, closed source
We aren't...
- Especially so, given that this is a security feature
I'd love to see support for TXT -- I think we can do some very important things with it, but I don't think it's workable as open source if it depends on closed proprietary code.
What is this code you speak of?
-Eric
On Wed, 31 Mar 2010, Eric Paris wrote:
On Thu, 2010-04-01 at 08:51 +1100, James Morris wrote:
On Wed, 31 Mar 2010, Eric Paris wrote:
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.
My feeling is that this needs to be dealt with upstream, and that the open source tboot needs to be delivered first.
Done and done. We are turning on an upstream config option.....
Interesting -- looks like this went in without any signoffs from security folk. The last I recall upstream was objecting to the binary blob aspect.
I'd love to see support for TXT -- I think we can do some very important things with it, but I don't think it's workable as open source if it depends on closed proprietary code.
What is this code you speak of?
You mention
"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"
Does TXT still depend on this proprietary blob?
- James
On Thu, 2010-04-01 at 09:15 +1100, James Morris wrote:
On Wed, 31 Mar 2010, Eric Paris wrote:
On Thu, 2010-04-01 at 08:51 +1100, James Morris wrote:
On Wed, 31 Mar 2010, Eric Paris wrote:
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.
My feeling is that this needs to be dealt with upstream, and that the open source tboot needs to be delivered first.
Done and done. We are turning on an upstream config option.....
Interesting -- looks like this went in without any signoffs from security folk. The last I recall upstream was objecting to the binary blob aspect.
I'd love to see support for TXT -- I think we can do some very important things with it, but I don't think it's workable as open source if it depends on closed proprietary code.
What is this code you speak of?
You mention
"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"
Does TXT still depend on this proprietary blob?
If you choose to purchase certain hardware, such as the IBM system X referenced in the discussion there is no need for any proprietary blobs as the system takes care of supplying everything that is needed for it to function. Some older laptops and desktop chipsets might be able to be made to work with a closed source binary blob signed by Intel. So no, TXT does not still depend on a separate proprietary blob you need to go and download. But the use of such a blob is not precluded if you as a user make that choice to enable functionality of your existing system.
-Eric
* James Morris (jmorris@namei.org) wrote:
You mention
"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"
Does TXT still depend on this proprietary blob?
Yes (TXT as in CPU instructions, not TXT as in CONFIG_TXT). The SENTER insn will still load the binary blob. However SENTER is something that is done by tboot before the kernel is launched. The difference now is that Fedora does not need to care about the SINIT AC module in terms of grub.conf, distribution, etc. tboot knows how to find SINIT AC from the BIOS, and some hw vendors like IBM are willing to deliver it that way.
thanks, -chris
On Wed, 31 Mar 2010, Eric Paris wrote:
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.)
Also, why is there no chance of this being open sourced?
On Thu, 2010-04-01 at 09:24 +1100, James Morris wrote:
On Wed, 31 Mar 2010, Eric Paris wrote:
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.)
Also, why is there no chance of this being open sourced?
Simple answer is 'because Intel says so.' I'm sorry but I don't think I'm allowed to divulge any reasons Intel may or may not have shared with Red Hat. I will say that a large sticking point is the fact that even if it was open source the requirement that it be signed by an Intel key to function would still have made the SINIT AC module unacceptable to fedora. Something so closely tied to hardware needs to be dealt with by the hardware vendors and IBM has agreed to take that step.
-Eric
On Wed, 31 Mar 2010, Eric Paris wrote:
Simple answer is 'because Intel says so.' I'm sorry but I don't think I'm allowed to divulge any reasons Intel may or may not have shared with Red Hat.
It seems odd to me that the full design and operation of a security mechanism is not being made available, and that the reasons for this are also not able to be divulged.
Note that an SINIT AC module was recently reverse engineered, found to be buggy, and then used break TXT:
http://theinvisiblethings.blogspot.com/2009/12/another-txt-attack.html
I really hope the secrecy of the AC module is not part of its security design.
In any case, I don't see any technical reason not to enable the option.
- James
On Thu, 2010-04-01 at 15:02 +1100, James Morris wrote:
On Wed, 31 Mar 2010, Eric Paris wrote:
Simple answer is 'because Intel says so.' I'm sorry but I don't think I'm allowed to divulge any reasons Intel may or may not have shared with Red Hat.
It seems odd to me that the full design and operation of a security mechanism is not being made available, and that the reasons for this are also not able to be divulged.
Note that an SINIT AC module was recently reverse engineered, found to be buggy, and then used break TXT:
http://theinvisiblethings.blogspot.com/2009/12/another-txt-attack.html
I really hope the secrecy of the AC module is not part of its security design.
In any case, I don't see any technical reason not to enable the option.
As far as I know the security of TXT in no way relies upon keeping the SINIT module closed source.
On 04/01/2010 09:38 AM, Stephen Smalley wrote:
As far as I know the security of TXT in no way relies upon keeping the SINIT module closed source.
And yet, Intel refuses to open source it, quite adamantly.
On top of that, even if they did open source it, the hardcoded key requirement prevents anyone from actually using the SINIT module when built from source (well, except perhaps Intel and whomever they gave the key to).
~spot
kernel@lists.fedoraproject.org