User: Password:
Subscribe / Log in / New account

Enabling Intel TXT in Fedora

Enabling Intel TXT in Fedora

Posted Apr 8, 2010 15:52 UTC (Thu) by BenHutchings (subscriber, #37955)
Parent article: Enabling Intel TXT in Fedora

While I really don't want to rely on yet more non-free code, I'm not sure how this is qualitatively different from the way Linux normally relies on a non-free BIOS (or other platform firmware). With ACPI methods the kernel does at least get to interpret and limit what the code does, but SMM is a black box that the kernel has no control over at all (not even to disable it altogether).

(Log in to post comments)

Enabling Intel TXT in Fedora

Posted Apr 8, 2010 20:54 UTC (Thu) by gmaxwell (guest, #30048) [Link]

One non-trivial qualitative difference is that this is _new_ and that Linux vendors have gained (/are gaining) the market power to push back against these blobbish approaches. That other things are bad isn't really a rational reason to reject adding a new thing which is just as bad: It's a lot easier to avoid incorporating a new thing than it is to go and replace the existing stuff.

Perhaps more fundamentally this kind of functionality, if widely deployed, risks fundamentally changing how things work for users and distributors alike.

For example, if a network service you use begins requiring systems to attest that they are running one of a finite set of 'approved' kernels then you lose the freedom to load customized kernels without giving up those services, developers lose some of their testing freedom since users won't run test builds, and your distributor loses the ability to rapidly push updates without worrying about breaking users.

Of course— you could counter that market forces will temper that kind of lock-down. But I think thats far from clear. While the cost of lock-down is that every user, every developer, and every distributor loses freedom only fairly few of the users will _notice_ the lost of freedom, and half the time they'll attribute problems to the developers/distribution changing things. Developers/distributors are just along for the ride, they can't tell their users "well don't use service XX" and expect many of the users to listen.

So it doesn't seem clear to me that the market demand will be strongly connected to the actual harm that could result from the widespread use of TXT.

And, of course, it's sensible to talk about preserving freedom in this context: Freedom is one of fedora's core values.

I think it's most interesting to note that keeping attestation _out_ of the default install is probably completely effective against building a widespread expectation that attestation is available, yet keeping it out of the default install would do little to harm advanced users whom want to take advantage of some of the few user friendly uses for this technology.

Perhaps you think that the concerns about remote attestation ultimately removing the freedom from our free software are a bit far out— but the fact that I can seriously raise them is an important qualitative difference between TXT and things like SMM.

Enabling Intel TXT in Fedora

Posted Apr 19, 2010 14:36 UTC (Mon) by robbe (subscriber, #16131) [Link]

> Of course— you could counter that market forces will temper that kind
> of lock-down.

Sure. There's also nobody buying closed cellphones...

If the legitimate security concern is really all there is to it (I doubt it), I think this scheme could work:

Connecting to the internet is only allowed if you buy mandatory insurance (as is done for cars). The insurance has to pay out if your device harms the network (DoS, Spam, Worm, whatever). Rational insurers can ask lower premiums for operating systems and/or configurations that they found to be less risky. That you really run this configuration could be enforced contractually, or even via this fancy remote attestation. Other models are lower/increasing premiums according to a user's incidence record.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds