From: Theodore Tso <tytso@mit.edu>
Newsgroups: fa.linux.kernel
Subject: Re: [RFC v3][PATCH 2/2] intel_txt: Intel(R) TXT and tboot kernel
Date: Tue, 12 May 2009 21:02:31 UTC
Message-ID: <fa.6D+Z/TdKCIPS98tb8pMuWl9SGXE@ifi.uio.no>

On Thu, May 07, 2009 at 09:49:07PM -0700, Joseph Cihula wrote:
> Linux support for Intel(R) Trusted Execution Technology.

It should be noted that one of the prime purposes of the Trusted
Execution Technology (TXT), aka LaGrande Technology is for DRM
enforcement systems that can be nearly uncrackable.

It can be used for other things, such as restricting who can look at
your medical records (basically, the same technology that prevents you
from breaking the DRM on say, a high-definition movie from Hollywood)
can also be used to enforced who can look at your certain records,
such as medical records in a highly secure and non-circumvental
fashion.

Ross Anderson was one of the first to write about these concerns, over
five years ago:

     http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html

It's interesting that his 2003 document was able to predict the
emergence of the LaGrande Technology (see question 15 in the above
FAQ).

So we should expect a certain amount of controversy and people
lobbying to resist the acceptance of this patch.

Regards,

						- Ted

From: Theodore Tso <tytso@mit.edu>
Newsgroups: fa.linux.kernel
Subject: Re: [RFC v3][PATCH 2/2] intel_txt: Intel(R) TXT and tboot kernel
Date: Fri, 15 May 2009 12:08:27 UTC
Message-ID: <fa.XTMHUA6J/+RVgcbmKzK8fsat/ek@ifi.uio.no>

On Thu, May 14, 2009 at 06:45:29PM -0700, Cihula, Joseph wrote:
>
> For a balanced view on Trusted Computing, people should also read
> David Safford's (IBM) rebuttal whitepaper at:
> http://www.research.ibm.com/gsal/tcpa/tcpa_rebuttal.pdf.

Note that most of what David wrote about in his paper was specific to
TCPA, and not necessarily the TXT/LaGrande technology.  I recently
defended TCPA to someone who expressed concerns about IMA going into
the kernel, on the grounds that TCPA was so badly done it was almost
impossible to use it to create a workable DRM system.  Given how TCPA
works, this is definitely true, and I judge that the benefits (being
able to protect private keys under the user's controlled) outweighs
the potential downsides (namely that of DRM, given that it was pretty
much impossible to make a workable DRM system using the TCPA/IMA
architecture alone).

However, it seems to me that TXT/LaGrande's main purpose for existence
was to repair the defects in TCPA that made it essentially unsuable
for DRM purposes.  With TCPA, any time you changed *anything* in the
boot path --- installed a new BIOS, upgraded to a new kernel to fix a
security vulnerability, updated to a new Nvidia proprietary video
driver slightly less likely to crash your sustem --- it would change
the trusted boot measurements, and would require an exchange to
"Circuity City DIVX hotline" (as a generic stand-in for whoever is
Hollywood's current monkey paw towards trying to implement DRM) to
approve a transfer of the TCPA trusted keys, which would be
essentially be a consumer support nightmare, and there would be no way
for "Circuit City" to know whether the kernel you are claiming was the
latest update from Fedora or Novell or Canonical was really an
authorized upgrade, or whether it was a custom kernel with patches to
tap into video and audio paths to steal Hollywood's precious bodily
fluids.

With TXT, however, all of these problems go away.  What you end up
booting is completely under "Circit City's DIVX's" control, and may
include a miniature Windows environment running in the trusted
environment; it could then take over a portion of the screen for the
video output, and the hardware would have special features set up to
prevent the host OS from having any access to the video output of the
movie player running in the TXT environment.  (This was how Intel
presented the LaGrande technology to the Kernel Summit several years
ago, and I assume the capabilities of TXT hasn't change significantly
since then.)

Essentially, it's hard for me to think up situations where the TCPA
chip would not be sufficient in terms of being a solution to a
security problem that has the user's best interests at heart, rather
than that of Hollywood, and where TXT would be a such a solution.
Medical records are perhaps the best example I can come up with; and
maybe some kind of bank security system where you're only allowed to
engage in on-line banking if you run a bank-supplied application in
the TXT environment.  However, it's hard for me to believe banks and
hospitals will invest in solutions that implement these sorts of
benign solutions, and it's all too easy for me to believe that
Hollywood will invest in these sorts of solutions.

That being said, it's not clear to me that stopping the technology
from going into Linux really isn't going to help matters;
realistically, the Linux desktop is miniscule[1], and whether or not
we add support for TXT in the mainline Linux kernel isn't going to
stop Hollywood's plans.  A much better approach would be for the FSF
to organize a boycott urging users users not to buy *any* hardware
that is TXT enabled, whether it is going to be booting Windows, MacOS
X, or Linux.  And note that I said *hardware*, not CPU.  In order for
TXT to work, the BIOS, motherboard, video chipset, etc., all have to
be working in concert in order to provide a secure environment that
can't be tapped in by the Host OS.

[1] The one potential risk I could see is TXT being used in Moblin,
and that being used as a scheme to implement DRM ala Hollywood style.
But realistically, even if we don't let it into mainline kernel, it
won't stop Moblin hardware vendors from shipping it.

The bottom line is it this is a social problem, not a technical
problem, and probably needs to be solved by social means (i.e., an
FSF-led boycott).  But from a technical point of view, I would be
shocked if the first major user of the TXT technology *wasn't* to
provide DRM enforcement of one kind or another.

Regards,

						- Ted

From: Theodore Tso <tytso@mit.edu>
Newsgroups: fa.linux.kernel
Subject: Re: [RFC v3][PATCH 2/2] intel_txt: Intel(R) TXT and tboot kernel
Date: Fri, 15 May 2009 12:29:21 UTC
Message-ID: <fa.SpRUQz/wk451VkSmQjsDH567rwY@ifi.uio.no>

BTW, see this slide set:

http://invisiblethingslab.com/resources/bh09dc/Attacking%20Intel%20TXT%20-%20slide

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

From: Theodore Tso <tytso@mit.edu>
Newsgroups: fa.linux.kernel
Subject: Re: [RFC v3][PATCH 2/2] intel_txt: Intel(R) TXT and tboot kernel
Date: Tue, 26 May 2009 02:31:40 UTC
Message-ID: <fa.veCUYLF22hiLsekL677PCoB1Y9Y@ifi.uio.no>

On Mon, May 25, 2009 at 08:14:36PM -0400, Richard M Stallman wrote:
>     Linus says he hates drm but does not want to stop it through legal
>     means, because its impossible.
>
> It is quite possible to block use of DRM in Linux.  All they need to
> do is move to GPLv3.  Eben Moglen worked out for them how they could
> do this if they want to.

Actually, moving Linux to GPLv3 would do absolutely nothing to stop
DRM as implemented by the LaGrande/TXT technology.  That's because
what is actually running inside the trusted execution environment
doesn't have to be GPL'ed code at all.  It doesn't even really need to
be an OS, since it relies on Linux to effectively be a sophisticated
bootloader and networking stack and windowing manager for it.

This is one of the reasons why I've always personally thought it was a
very bad idea to try to stop DRM via copyright licenses such as the
GPLv3; you might be able to prevent one which requires a "trusted
kernel", via the GPLv3's "anti-TIVO clause".  However, the
LaGrande/TXT doesn't require a trusted kernel.  You can modify the
kernel all you want.  However, if the kernel tries tampering with the
trusted image which TXT provides, it will be detected and the trusted
boot operation will fail --- but the code which does the digital
signature check and the code running in the tboot environment isn't
GPL'ed code at all, and part of the enforcement is done in hardware.

Consider the situation where the DRM'ed code was running as part of
Windows Vista, and so a Linux user downloaded code which ran the
DRM'ed application under Windows Vista under KVM in an virtual
environment.  It's obvious that whether Linux is licensed under GPLv2
or GPLv3 would make no difference in prohibited the DRM'ed code to be
run in VM, right?  TXT is basically this, except that (a) the hardware
provides strong protection against tampering once the trusted
environment is established, and (b) there are well defined interfaces
for thet trusted enviroment use the filesystem, device drivers, and
networking stack of the host OS to do its I/O (with everything stored
in the filesystem, or fetched over the network, protected via either
encryption or digital signatures, or both).

GPLv3 simply won't help address the DRM issue in this situation ---
just as the GPLv3 won't prevent the next Bernie Madoff from using
GPL'ed software to run a Ponzi scheme.  Sometimes, you can't use
copyright licenses to prevent people from doing evil things with the
software that we write and maintain.  That doesn't excuse the bad use
cases; just that copyright licenses isn't the right tool to use to
prevent these situations from happening.

							- Ted