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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox