Messages in this thread | | | Date | Fri, 15 May 2009 08:26:44 -0400 | From | Theodore Tso <> | Subject | Re: [RFC v3][PATCH 2/2] intel_txt: Intel(R) TXT and tboot kernel support |
| |
BTW, see this slide set:
http://invisiblethingslab.com/resources/bh09dc/Attacking%20Intel%20TXT%20-%20slides.pdf
For more details about why a TCPA-style solution (referred to in the slide set as a Static Root of Trust Measurement) doesn't really work for widespread consumer-usable DRM, where as a Dynamic Root of Trust Measurement (DRTM) scheme, such as provided by TXT, makes this be a much more tractable solution.
Also see their early results for attacking TXT via bugs in the SMM Bios. The one thing which is not discussed much in this slide decks is the hardware implemented features which lock out the Host OS from being able to read or modify memory used by the trusted code running in the secure VM (which must be locked into memory) once the SENTER instruction is given.
Obviously, yes, it's all under the user's control --- you don't have to boot a TXT VM image. On the other hand, you don't have to have access to your on-line banking, medical records, or watch a movie from Hollywood, and in the future, it might be that running TXT is the only way to do that. (The argument that it's always under the user's control is a standard line used by people defending DRM --- after all, you don't have to listen to the protected music, or watch the protected movie. It shifts the ground from the question societal question of "is DRM good for society", to a user freedom question, which is always true --- of course, user's are also free to boycott purchases of hardware that enable DRM; that is also their choice.)
- Ted
| |