enable CONFIG_INTEL_TXT

Eric Paris eparis at redhat.com
Wed Mar 31 21:06:35 UTC 2010


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.



More information about the kernel mailing list