enable CONFIG_INTEL_TXT

[Adam Jackson]

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