public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Richard M Stallman <rms@gnu.org>
Cc: Pavel Machek <pavel@ucw.cz>,
	joseph.cihula@intel.com, jmorris@namei.org,
	linux-kernel@vger.kernel.org, mingo@elte.hu,
	arjan@linux.intel.com, hpa@zytor.com, andi@firstfloor.org,
	chrisw@sous-sol.org, jbeulich@novell.com, peterm@redhat.com,
	gang.wei@intel.com, shane.wang@intel.com, gnu@toad.com
Subject: Re: [RFC v3][PATCH 2/2] intel_txt: Intel(R) TXT and tboot kernel support
Date: Mon, 25 May 2009 22:31:05 -0400	[thread overview]
Message-ID: <20090526023105.GB27648@mit.edu> (raw)
In-Reply-To: <E1M8kJQ-0000W3-TE@fencepost.gnu.org>

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

  parent reply	other threads:[~2009-05-26  2:31 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-08  4:49 [RFC v3][PATCH 2/2] intel_txt: Intel(R) TXT and tboot kernel support Joseph Cihula
2009-05-08  6:53 ` Andrew Morton
2009-05-29  1:02   ` Cihula, Joseph
2009-05-08  9:57 ` Ingo Molnar
2009-05-12  5:26   ` Cihula, Joseph
2009-05-12  9:45     ` Ingo Molnar
2009-05-12  9:55       ` Andi Kleen
2009-05-12 21:01 ` Theodore Tso
2009-05-14 15:52   ` Heinz Diehl
2009-05-15  0:17   ` James Morris
2009-05-15  1:45     ` Cihula, Joseph
2009-05-15  1:51       ` Joe Perches
2009-05-15  2:49         ` Cihula, Joseph
2009-05-28  1:12           ` James Morris
2009-05-15 12:07       ` Theodore Tso
2009-05-15 12:26         ` Theodore Tso
2009-05-24 19:42         ` Pavel Machek
2009-05-24 19:42       ` Pavel Machek
     [not found]         ` <E1M8kJQ-0000W3-TE@fencepost.gnu.org>
2009-05-26  2:31           ` Theodore Tso [this message]
     [not found]             ` <E1M9Mig-0003Q4-S1@fencepost.gnu.org>
2009-05-29  9:47               ` Pavel Machek
2009-05-19 20:30     ` Pavel Machek
2009-05-22 16:59       ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090526023105.GB27648@mit.edu \
    --to=tytso@mit.edu \
    --cc=andi@firstfloor.org \
    --cc=arjan@linux.intel.com \
    --cc=chrisw@sous-sol.org \
    --cc=gang.wei@intel.com \
    --cc=gnu@toad.com \
    --cc=hpa@zytor.com \
    --cc=jbeulich@novell.com \
    --cc=jmorris@namei.org \
    --cc=joseph.cihula@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=pavel@ucw.cz \
    --cc=peterm@redhat.com \
    --cc=rms@gnu.org \
    --cc=shane.wang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox