From: Pavel Machek <pavel@ucw.cz>
To: Theodore Tso <tytso@mit.edu>,
"Cihula, Joseph" <joseph.cihula@intel.com>,
James Morris <jmorris@namei.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"mingo@elte.hu" <mingo@elte.hu>,
"arjan@linux.intel.com" <arjan@linux.intel.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"andi@firstfloor.org" <andi@firstfloor.org>,
"chrisw@sous-sol.org" <chrisw@sous-sol.org>,
"jbeulich@novell.com" <jbeulich@novell.com>,
"peterm@redhat.com" <peterm@redhat.com>,
"Wei, Gang" <gang.wei@intel.com>,
"Wang, Shane" <shane.wang@intel.com>, John Gilmore <gnu@toad.com>
Subject: Re: [RFC v3][PATCH 2/2] intel_txt: Intel(R) TXT and tboot kernel support
Date: Sun, 24 May 2009 21:42:45 +0200 [thread overview]
Message-ID: <20090524194245.GC1337@ucw.cz> (raw)
In-Reply-To: <20090515120748.GF6816@mit.edu>
Hi!
> 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.)
How does this interact with keyboard handling?
> 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.
I suspect it does not 'protect' keyboard at all, meaning it is only
useful for drm.
> 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.
I see not merging / dropping changes only useful for drm from linux
kernelas a valid 'social means'...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2009-05-24 19:42 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 [this message]
2009-05-24 19:42 ` Pavel Machek
[not found] ` <E1M8kJQ-0000W3-TE@fencepost.gnu.org>
2009-05-26 2:31 ` Theodore Tso
[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=20090524194245.GC1337@ucw.cz \
--to=pavel@ucw.cz \
--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=peterm@redhat.com \
--cc=shane.wang@intel.com \
--cc=tytso@mit.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.