enable CONFIG_INTEL_TXT

[Stephen Smalley]

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.
-- 
Stephen Smalley
National Security Agency