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.