enable CONFIG_INTEL_TXT

[Stephen Smalley]

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...

-- 
Stephen Smalley
National Security Agency