linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: Flame Linus to a crisp!
       [not found] <20030424041004$113a@gated-at.bofh.it>
@ 2003-04-24  4:53 ` Tony 'Nicoya' Mantler
  0 siblings, 0 replies; 130+ messages in thread
From: Tony 'Nicoya' Mantler @ 2003-04-24  4:53 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel

In article <20030424041004$113a@gated-at.bofh.it>,
 Linus Torvalds <torvalds@transmeta.com> wrote:

[...]
:   I want to make it clear that DRM is perfectly ok with Linux!
[...]

Well ok then. I assume for DRM to be in the kernel it would have to somehow be 
in a useful form, and to be in a useful form it would have to be secure. I think 
everyone can agree it does no good to have completely useless code cluttering 
the kernel.

I see two directions of signing, a bottom up (like media DRM) and a top down 
(like X-Box or TCPA).

The latter should be very easy to implement securely and doesn't really qualify 
as "DRM", but the former doesn't seem so simple.

If we assume the context of a standard PC, there would be nothing stopping a 
user from replacing his signed DRM-compliant kernel with another unsigned kernel 
which would put on a puppet show for the DRM app, pretending to be signed.

The kernel must invariably be considered untrusted client code - code which in 
this case controls every aspect of the system that a DRM app could interact 
with, allowing it 100% freedom to fool a DRM app into thinking it's operaing in 
a secure environment, or on a different computer, or on the cold side of pluto. 
There's nothing stopping it, especially with the source freely available.

Making DRM in linux sercure would be like winning a hand of poker against 
someone who can change all the playing cards at will.

How would you, or anyone, intend to address this? (besides changing the 
definition of a "standard desktop PC" to only include systems like X-Box which 
refuse to run unsigned code, and can't be overridden by the user)


Unless this is just a very silly troll?


Cheers - Tony 'Nicoya' Mantler :)

-- 
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada           --           http://nicoya.feline.pp.se/

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-28 14:01           ` Zack Gilburd
@ 2003-04-28 14:30             ` Geert Uytterhoeven
  0 siblings, 0 replies; 130+ messages in thread
From: Geert Uytterhoeven @ 2003-04-28 14:30 UTC (permalink / raw)
  To: Zack Gilburd; +Cc: Andre Hedrick, Linux Kernel Development

On Mon, 28 Apr 2003, Zack Gilburd wrote:
> On Mon, 28 Apr 2003 03:35:10 -0700 (PDT)
> Andre Hedrick <andre@linux-ide.org> wrote:
> 
> > There is one fundamental problem, and nobody has addressed.
> > 
> > Who will enforce the GPL over DRM violations?
> > Since it is a blanket over the entire kernel, and you have formally
> > (for the most part) have authorized DRM, thus one assumes you are the only
> > one who can pursue in a court of law.
> 
> Unless I am missing something, I was hoping for more of a sparse DRM implementation; not a blanket.
> 
> I was hoping to be able to `modprobe drm` for when I needed to use DRM and likewise `rmmod drm` for when I didn't want it.  Maybe I am a little late in this disucssion, but that's just my hopes and whishes.

Unfortunately that's not going to work, since your DRM module cannot trust the
kernel it's loaded by.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-26 18:41         ` viro
  2003-04-26 18:48           ` Linus Torvalds
@ 2003-04-28 14:20           ` John Stoffel
  1 sibling, 0 replies; 130+ messages in thread
From: John Stoffel @ 2003-04-28 14:20 UTC (permalink / raw)
  To: viro; +Cc: Linus Torvalds, linux-kernel


viro> On Sat, Apr 26, 2003 at 06:22:50PM +0000, Linus Torvalds wrote:
>> We've seen this before. Remember when dongles were plentiful in the
>> software world? People literally had problems with having dongles on top
>> of dongles to run a few programs. They all died out, simply because
>> consumers _hate_ that kind of lock-in thing.

viro> Not all of them.  And they had spawned similar software turds -
viro> ask any sysadmin who'd dealt with FlexLM and its ilk and you'll
viro> hear a _lot_ of horror stories about the induced inconveniencies
viro> and breakage.

FlexLM is actually a good product in general, it's when it's tied in
by a vendor to a Dongle that is sucks.  The real horror show in
license managers is the GLBD (Global Location Broker) crap from
HP/IBM.  Thank god FlexLM has mostly killed them off.
 
John
   John Stoffel - Senior Unix Systems Administrator - Lucent Technologies
	 stoffel@lucent.com - http://www.lucent.com - 978-399-0479

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-28 10:35         ` Andre Hedrick
  2003-04-28 12:12           ` Jörn Engel
@ 2003-04-28 14:01           ` Zack Gilburd
  2003-04-28 14:30             ` Geert Uytterhoeven
  1 sibling, 1 reply; 130+ messages in thread
From: Zack Gilburd @ 2003-04-28 14:01 UTC (permalink / raw)
  To: Andre Hedrick; +Cc: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 709 bytes --]

On Mon, 28 Apr 2003 03:35:10 -0700 (PDT)
Andre Hedrick <andre@linux-ide.org> wrote:

> There is one fundamental problem, and nobody has addressed.
> 
> Who will enforce the GPL over DRM violations?
> Since it is a blanket over the entire kernel, and you have formally
> (for the most part) have authorized DRM, thus one assumes you are the only
> one who can pursue in a court of law.

Unless I am missing something, I was hoping for more of a sparse DRM implementation; not a blanket.

I was hoping to be able to `modprobe drm` for when I needed to use DRM and likewise `rmmod drm` for when I didn't want it.  Maybe I am a little late in this disucssion, but that's just my hopes and whishes.

-Zack Gilburd

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-28 10:35         ` Andre Hedrick
@ 2003-04-28 12:12           ` Jörn Engel
  2003-04-28 14:01           ` Zack Gilburd
  1 sibling, 0 replies; 130+ messages in thread
From: Jörn Engel @ 2003-04-28 12:12 UTC (permalink / raw)
  To: Andre Hedrick; +Cc: Linus Torvalds, linux-kernel

On Mon, 28 April 2003 03:35:10 -0700, Andre Hedrick wrote:
> 
> Who will enforce the GPL over DRM violations?

Anyone that can an want to do it.

Who can enforce the GPL over DRM violations?

> Since it is a blanket over the entire kernel, and you have formally
> (for the most part) have authorized DRM, thus one assumes you are the only
> one who can pursue in a court of law.

My interpretation may be off, but imo I can enforce the GPL as long as
the violating company uses my code as part of their product. Basicaly,
almost anyone on this list can enforce violations against the kernel,
depending on what code has been included.

People may rip out the IDE code because they don't want Andre Hedrick
to have this opertunity, while ripping out all of Linus code should be
a lot harder. But in principle, everyone is equal.

> Regardless of what I or anyone thinks, this effective places total
> copyright to you.  Additionally for you to have a legal position to stand
> on, it may be required for one to show you have total authority/assignment
> of the entire kernel.

Personally, I don't like these copyright assignment procedures. Before
signing any of them, I have to carefully read and reread them, not
missing the hidden legal implications. Why go through that mess, if
nothing forces us.

Am I wrong? Don't know.

Jörn

-- 
Fantasy is more important than knowlegde. Knowlegde is limited,
while fantasy embraces the whole world.
-- Albert Einstein

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-26 18:22       ` Linus Torvalds
  2003-04-26 18:41         ` viro
  2003-04-26 19:23         ` Michael Buesch
@ 2003-04-28 10:35         ` Andre Hedrick
  2003-04-28 12:12           ` Jörn Engel
  2003-04-28 14:01           ` Zack Gilburd
  2 siblings, 2 replies; 130+ messages in thread
From: Andre Hedrick @ 2003-04-28 10:35 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel


Linus,

There is one fundamental problem, and nobody has addressed.

Who will enforce the GPL over DRM violations?
Since it is a blanket over the entire kernel, and you have formally
(for the most part) have authorized DRM, thus one assumes you are the only
one who can pursue in a court of law.

Regardless of what I or anyone thinks, this effective places total
copyright to you.  Additionally for you to have a legal position to stand
on, it may be required for one to show you have total authority/assignment
of the entire kernel.

This is only an old man thinking out loud.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Sat, 26 Apr 2003, Linus Torvalds wrote:

> In article <Pine.GSO.4.21.0304261459210.10838-100000@vervain.sonytel.be>,
> Geert Uytterhoeven  <geert@linux-m68k.org> wrote:
> >
> >Hence the development rate of Linux will go down, since you cannot use your
> >Linux development box running your own development kernel for anything else,
> >since that would require a signed kernel.
> 
> Quite frankly, I suspect a much more likely issue is going to be that
> DRM doesn't matter at all in the long run.
> 
> Maybe I'm just a blue-eyed optimist, but all the _bad_ forms of DRM look
> to be just fundamentally doomed.  They are all designed to screw over
> customers and normal users, and in the world I live in that's not how
> you make friends (or money, which ends up being a lot more relevant to
> most companies). 
> 
> Think about it.  Successful companies give their customers what they
> _want_.  They don't force-feed them.  Look at the total and utter
> failure of commercial on-line music: the DRM things that has been tried
> have been complete failures.  Why? I'm personally convinced the cost is
> only a minor issue - the _anti_convenience of the DRM crap (magic file
> formats that only work with some players etc) is what really kills it in
> the end. 
> 
> And that's a fundamental flaw in any "bad" DRM. It's not going away. 
> 
> We've seen this before. Remember when dongles were plentiful in the
> software world? People literally had problems with having dongles on top
> of dongles to run a few programs. They all died out, simply because
> consumers _hate_ that kind of lock-in thing.
> 
> This is part of the reason why I have no trouble with DRM - let the
> people who want to try it go right ahead. They'll only screw themselves
> over in the end, because the people who do _not_ try to control their
> customers will in the end have the superior product. It's that simple.
> 
> As to the quake-on-PC issue - it's a completely made-up example, but it
> does show the same thing.  Nobody in their right mind would ever _do_ a
> DRM-enabled quake on a PC, because it limits you too much.  PC's are
> _designed_ ot be flexible - that's what makes the PC's.  DRM on a PC is
> a totally braindead idea, and I _hope_ Microsoft goes down that path
> because it will kill them in the end. 
> 
> The place where client authentication makes sense is on specialty boxes. 
> On a dedicated game machine it's an _advantage_ to verify the client,
> exactly to make sure that nobody is cheating.  I think products like the
> PS2 and the Xbox actually make _sense_ - they make it convenient for the
> user, and yes they use DRM techniques to "remove rights", but that's
> very much by design and when you buy the box 99.9% of all people buy it
> _because_ it only does one thing.
> 
> 		Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


^ permalink raw reply	[flat|nested] 130+ messages in thread

* RE: Flame Linus to a crisp!
@ 2003-04-28  9:30 Martin_List-Petersen
  0 siblings, 0 replies; 130+ messages in thread
From: Martin_List-Petersen @ 2003-04-28  9:30 UTC (permalink / raw)
  To: viro; +Cc: linux-kernel


>> We've seen this before. Remember when dongles were plentiful in the
>> software world? People literally had problems with having dongles on top
>> of dongles to run a few programs. They all died out, simply because
>> consumers _hate_ that kind of lock-in thing.
>
>Not all of them.  And they had spawned similar software turds - ask
>any sysadmin who'd dealt with FlexLM and its ilk and you'll hear a
>_lot_ of horror stories about the induced inconveniencies and breakage.
 
Uhh .... don't give me that. ModelSim is just one of these FlexLM horrors.
The best thing is, if you have multiple licenses on one dongle (to share on
the network) and the darn thing doesn't release them, when people stop using
the software.

Or people who simply couldn't get the stuff to work, because of some silly
printerport issues (voltage issues, whatsoever).

Regards,
Martin List-Petersen


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-27 14:21           ` Matthias Andree
@ 2003-04-27 16:13             ` Stephan von Krawczynski
  0 siblings, 0 replies; 130+ messages in thread
From: Stephan von Krawczynski @ 2003-04-27 16:13 UTC (permalink / raw)
  To: Matthias Andree; +Cc: linux-kernel

On Sun, 27 Apr 2003 16:21:06 +0200
Matthias Andree <matthias.andree@gmx.de> wrote:

> The hard part about this discussion is not the technical one, but the
> social one, tell those people who just go to a shop what can happen if
> they buy a copy-protected CD, and what can happen if they tolerate their
> members of parliament voting in favor of DMCA-like laws

Please stop being naive.
In case nobody told you: we are not living in a democracy here (in Germany),
but something that can best be qualified as party-oligarchy. This is why your
MoP is not interested at all in your "tolerance" of his voting. He does not
need you (or your vote) for making his living, he needs his party, and that's
it.

Regards,
Stephan

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 22:29         ` Werner Almesberger
  2003-04-24 22:41           ` Jamie Lokier
  2003-04-24 22:41           ` Alan Cox
@ 2003-04-27 14:21           ` Matthias Andree
  2003-04-27 16:13             ` Stephan von Krawczynski
  2 siblings, 1 reply; 130+ messages in thread
From: Matthias Andree @ 2003-04-27 14:21 UTC (permalink / raw)
  To: Linux Kernel Mailing List

On Thu, 24 Apr 2003, Werner Almesberger wrote:

> A more important barrier than what the GPL allows might be what the
> Linux community accepts. If some DRM extensions are never accepted
> by enough of the "mainstream", they will fail to work.
> 
> The main problem I see with accepting DRM functionality is that it
> will encourage frivolous uses of DRM, just because it's possible
> then. Just like most vendors instinctively default to closed
> source.
> 
> It's also worth to keep in mind that such decisions are frequently
> taken by people with very different agendas, e.g. if "protected by
> DRM" is perceived to appeal to analysts, shareholders or potential
> shareholders, it may quickly become policy in many companies, just
> like patents did.

It seems that the people who form the "market" (and buy shares, write
analyses, buy CDs/DVDs) need to be told the implications of buying
copy-protected material or material that enforces to boot only
particlular kernels or whatever.

The problem is that those in favor of (ab)using DRM to fortifying their
monopoly don't tell you where the other side of the knife cuts. Those
analysts and shareholders are only interested in local, egoistic optima;
Microsoft will tell us that DRM brings "security" -- but they won't tell
all the details, say, you can only play $MEDIA if $COMPANY allows it.

The hard part about this discussion is not the technical one, but the
social one, tell those people who just go to a shop what can happen if
they buy a copy-protected CD, and what can happen if they tolerate their
members of parliament voting in favor of DMCA-like laws (such as the new
German copyright act that doesn't allow you to enforce your right to
fair use, to a private copy of your CD for your car audio, if the vendor
puts protection in place) or voting in favor of big companies rather
than companies. The common people need to understand that their rights
are being taken away, and that these rights are tied to their money.

I haven't seen copy-protected CDs being sold cheaper than unprotected
CDs (which would make some sense, because after the companies' logic,
this will rise the sales). This is the example that has been
established, others are to come. The sharks (see Jamie's WIPO comments)
will know how to defend their territory.

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-25 12:36 Downing, Thomas
@ 2003-04-27  7:25 ` Adrian Bunk
  0 siblings, 0 replies; 130+ messages in thread
From: Adrian Bunk @ 2003-04-27  7:25 UTC (permalink / raw)
  To: Downing, Thomas; +Cc: Kernel Mailing List

On Fri, Apr 25, 2003 at 08:36:00AM -0400, Downing, Thomas wrote:
> From: Adrian Bunk [mailto:bunk@fs.tum.de]
> 
> >On Wed, Apr 23, 2003 at 10:43:37PM -0700, Linus Torvalds wrote:
> >>...
> >> And hey, the fact is (at least as far as I'm concerned), that as long as
> >> you make the hardware, you can control what it runs.
> >>...
> >
> >Linux is currently widely used and through this there comes some power. 
> >Let me try to make examples where this might be important:
> 
> You cast these comments in the context of corporate use, so -
> 
> The primary reason corporations are beginning to adopt Linux is TCO
> - and such adoption is in its early stages, though growing.  Such
> adoption is _only_ to the extent that Linux will run specific
> applications.
> 
> Companies do _not_ adopt Linux because it is the only OS on which
> their critical applications run.  They don't adopt it because it's
> the coolest OS out there.  All the corporate required applications 
> run on other O$'s.  If support for a facility percieved as desirable
> or necessary (in this case, DRM)is not available in Linux due to the
> terms of the GPL, corporations will drop Linux in a heartbeat.
> 
> Some companies (viz certain very large financial institutions) are
> only now just beginning to write applications _on_ Linux.  When
> Linux has a majority market share, with the rest of the market in
> disarray, _then_ you have some power; but only for a limitted time.

There are even in bigger companies already many production machines
running Linux. I don't say that it's impossible for them to switch to a
different OS, but this would be a non-trivial switch (if this is
critical infrastructure) and a non-cheap (both for training the staff
for a different OS and for buying soft- and perhaps hardware) switch.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-26 18:21   ` Rik van Riel
  2003-04-26 23:34     ` Jamie Lokier
@ 2003-04-27  3:59     ` Werner Almesberger
  1 sibling, 0 replies; 130+ messages in thread
From: Werner Almesberger @ 2003-04-27  3:59 UTC (permalink / raw)
  To: Rik van Riel; +Cc: Daniel Phillips, Linus Torvalds, Kernel Mailing List

Rik van Riel wrote:
> Of course, people could still use a hub for their network
> connection and have a second PC sniff the network traffic
> and display everything conveniently on the other monitor.

All the nicely encrypted data ?

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-27  1:31       ` Werner Almesberger
@ 2003-04-27  1:59         ` David Wagner
  0 siblings, 0 replies; 130+ messages in thread
From: David Wagner @ 2003-04-27  1:59 UTC (permalink / raw)
  To: linux-kernel

Werner Almesberger  wrote:
>Eric W. Biederman wrote:
>> Redhat's kernel is unlikely to get my signature.  Possibly
>> at some point there will be a web of trust where that will work
>> but in the first approximation distributors kernels will not
>> load until I sign them.
>
>Yes, that's exactly the "good" kind of DRM.

Semantic quibbling:

Actually, no, I don't think it is.  That's not DRM at all, good
or bad.  It's just plain old signatures, web of trust, etc.  Not
everything that uses crypto or code signing is DRM.

(We're really getting off-topic now, I suppose.)

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-25 11:28     ` Eric W. Biederman
@ 2003-04-27  1:31       ` Werner Almesberger
  2003-04-27  1:59         ` David Wagner
  0 siblings, 1 reply; 130+ messages in thread
From: Werner Almesberger @ 2003-04-27  1:31 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: Daniel Phillips, Linus Torvalds, Kernel Mailing List

Eric W. Biederman wrote:
> Redhat's kernel is unlikely to get my signature.  Possibly
> at some point there will be a web of trust where that will work
> but in the first approximation distributors kernels will not
> load until I sign them.

Yes, that's exactly the "good" kind of DRM. A few things are
special in your case, though:

 - the "rights owner" and the "user" are the same person
 - the "user" can be trusted
 - you control your firmware

Does TCPA (I suppose that's what Linus' endorsement of DRM is
about) even have the concept of user-installed keys or
certificates ?

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-26 18:21   ` Rik van Riel
@ 2003-04-26 23:34     ` Jamie Lokier
  2003-04-27  3:59     ` Werner Almesberger
  1 sibling, 0 replies; 130+ messages in thread
From: Jamie Lokier @ 2003-04-26 23:34 UTC (permalink / raw)
  To: Rik van Riel; +Cc: Daniel Phillips, Linus Torvalds, Kernel Mailing List

Rik van Riel wrote:
> On Thu, 24 Apr 2003, Daniel Phillips wrote:
> > Open source + Linux + DRM could be used to solve the Quake client-side 
> > cheating problem:
> > 
> >    http://catb.org/~esr/writings/quake-cheats.html
> > 
> > To join a game, you'd have to be able to prove you're running code that
> > is secure all the way from boot to reboot, where everything from network
> > driver to physics engine is known to be compiled from open source that
> > all participants agree is good.
> 
> Of course, people could still use a hub for their network
> connection and have a second PC sniff the network traffic
> and display everything conveniently on the other monitor.

How would the sniffer decrypt the traffic?

-- Jamie

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-25 17:37       ` Werner Almesberger
@ 2003-04-26 21:59         ` Daniel Phillips
  0 siblings, 0 replies; 130+ messages in thread
From: Daniel Phillips @ 2003-04-26 21:59 UTC (permalink / raw)
  To: Werner Almesberger; +Cc: Linus Torvalds, Kernel Mailing List

On Friday 25 April 2003 19:37, Werner Almesberger wrote:
> Daniel Phillips wrote:
> > I imagine the likelihood of people running completely separate DRM Linux
> > boxes, just to participate in DRM-controlled online games, is not high.
>
> You could still dual-boot, as many people do today.

Only neanderthals dual-boot ;-)

> > the whole concept is inherently fragile, there are just too many parts
> > involved.
>
> ... and companies relying on DRM are likely to distrust Linux for
> every single such flaw that is found. They'll put up with Windows,
> because they have to.

Companies relying on DRM are candidates for Darwin awards, IMHO.  However, 
the pure technical challenge of trying to make DRM work for something, 
somehow, sometime might be enough to get decent support on Linux.  I wonder 
if the Quake thing is interesting enough to motivate anyone.  It could be 
advertised as "the only place you'll ever get a fair fight".

Maybe DRM support is a way for some Linux vendor to differentiate themselves. 
Now... DRM in Debian?  Sounds like an oxymoron.  I certainly won't be asking 
for it.

> It all makes sense - in some ugly, twisted way.

What seems to be missing is the motivation to get exited about it.  Seems to 
me, I've never bought or played a copy-protected CD, or video disk (took a 
pass on the whole video disk thing, didn't regret it) or anything else, and 
it's not because I'm a fanatic about it, it's just that it never made sense.

The whole DRM thing is likely to land with a dull thud and be as forgotten as 
8 track tapes.  It's all just too clunky, and there's nothing in it for the 
consumer.

Regards,

Daniel


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-26 18:22       ` Linus Torvalds
  2003-04-26 18:41         ` viro
@ 2003-04-26 19:23         ` Michael Buesch
  2003-04-28 10:35         ` Andre Hedrick
  2 siblings, 0 replies; 130+ messages in thread
From: Michael Buesch @ 2003-04-26 19:23 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 26 April 2003 20:22, Linus Torvalds wrote:
> Quite frankly, I suspect a much more likely issue is going to be that
> DRM doesn't matter at all in the long run.
>
> Maybe I'm just a blue-eyed optimist, but all the _bad_ forms of DRM look
> to be just fundamentally doomed.  They are all designed to screw over
> customers and normal users, and in the world I live in that's not how
> you make friends (or money, which ends up being a lot more relevant to
> most companies).

IMHO it's totally impossible at the moment to predict what will happen
to DRM in the future. It can turn the "good" or "bad" way, but nobody
can _yet_ say, which way it'll go. When it's forseeable, it'll be
to late to act against it, if it goes the "bad" one.

> Think about it.  Successful companies give their customers what they
> _want_.  They don't force-feed them.  Look at the total and utter
> failure of commercial on-line music: the DRM things that has been tried
> have been complete failures.  Why? I'm personally convinced the cost is
> only a minor issue - the _anti_convenience of the DRM crap (magic file
> formats that only work with some players etc) is what really kills it in
> the end.
>
> And that's a fundamental flaw in any "bad" DRM. It's not going away.
>
> We've seen this before. Remember when dongles were plentiful in the
> software world? People literally had problems with having dongles on top
> of dongles to run a few programs. They all died out, simply because
> consumers _hate_ that kind of lock-in thing.
>
> This is part of the reason why I have no trouble with DRM - let the
> people who want to try it go right ahead. They'll only screw themselves
> over in the end, because the people who do _not_ try to control their
> customers will in the end have the superior product. It's that simple.

Maybe this is only a local problem to germany (I don't think so :) ),
but almost all people I know don't want to know what their computer
does and how it does it. They only want to "write their e-mails"
or only want to "surf in the internet". They don't care about if
they do it with, or without DRM. IMHO exactly this is the danger of the
whole thing. Most people will accept it, although they are a little bit
snipped in their rights and possibilities.
And they'll accept even more and more and more... .
Another point is, that I haven't found anybody in my environment,
that even knows the words DRM or TCPA. Exactly these persons will
accept it, whether it's "good" or "bad".

But on the other side I think the same way, as you, that DRM has
to go into the kernel.
IMHO that's a little bit sad, because we have no really choice,
because over the time all OSs will include it and than linux can't
survive as an outsider in the same form it "survives" today.

>
> 		Linus

- -- 
Regards Michael Büsch
http://www.8ung.at/tuxsoft
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+qtyvoxoigfggmSgRAsrGAKCKjjxccKoWof63dbG2Go897mkRewCeMdq5
hHjwivTTAgEgc6+ifbcLVE0=
=FKO/
-----END PGP SIGNATURE-----


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-26 18:41         ` viro
@ 2003-04-26 18:48           ` Linus Torvalds
  2003-04-28 14:20           ` John Stoffel
  1 sibling, 0 replies; 130+ messages in thread
From: Linus Torvalds @ 2003-04-26 18:48 UTC (permalink / raw)
  To: viro; +Cc: linux-kernel


On Sat, 26 Apr 2003 viro@parcelfarce.linux.theplanet.co.uk wrote:
> On Sat, Apr 26, 2003 at 06:22:50PM +0000, Linus Torvalds wrote:
>  
> > We've seen this before. Remember when dongles were plentiful in the
> > software world? People literally had problems with having dongles on top
> > of dongles to run a few programs. They all died out, simply because
> > consumers _hate_ that kind of lock-in thing.
> 
> Not all of them.  And they had spawned similar software turds - ask
> any sysadmin who'd dealt with FlexLM and its ilk and you'll hear a
> _lot_ of horror stories about the induced inconveniencies and breakage.

But that's exactly my point. These companies are (in the long run) just 
shooting themselves in the foot.

Sure, they still exist. But they are a niche market (and, btw, you can 
almost always tell which programs still do it: overpriced products for 
niche markets that don't have enough competition).

Any area where there has been even an _ounce_ of competition has dropped 
the DRM crap like a hot potato, because users wouldn't stand for it.

> > _designed_ ot be flexible - that's what makes the PC's.  DRM on a PC is
> > a totally braindead idea, and I _hope_ Microsoft goes down that path
> > because it will kill them in the end. 
>  
> Wolfram Research is still alive.  Remember Mathematica?

And this makes my point invalid exactly _how_?

		Linus


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-26 18:22       ` Linus Torvalds
@ 2003-04-26 18:41         ` viro
  2003-04-26 18:48           ` Linus Torvalds
  2003-04-28 14:20           ` John Stoffel
  2003-04-26 19:23         ` Michael Buesch
  2003-04-28 10:35         ` Andre Hedrick
  2 siblings, 2 replies; 130+ messages in thread
From: viro @ 2003-04-26 18:41 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel

On Sat, Apr 26, 2003 at 06:22:50PM +0000, Linus Torvalds wrote:
 
> We've seen this before. Remember when dongles were plentiful in the
> software world? People literally had problems with having dongles on top
> of dongles to run a few programs. They all died out, simply because
> consumers _hate_ that kind of lock-in thing.

Not all of them.  And they had spawned similar software turds - ask
any sysadmin who'd dealt with FlexLM and its ilk and you'll hear a
_lot_ of horror stories about the induced inconveniencies and breakage.
 
> _designed_ ot be flexible - that's what makes the PC's.  DRM on a PC is
> a totally braindead idea, and I _hope_ Microsoft goes down that path
> because it will kill them in the end. 
 
Wolfram Research is still alive.  Remember Mathematica?

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-26 13:00     ` Geert Uytterhoeven
@ 2003-04-26 18:22       ` Linus Torvalds
  2003-04-26 18:41         ` viro
                           ` (2 more replies)
  0 siblings, 3 replies; 130+ messages in thread
From: Linus Torvalds @ 2003-04-26 18:22 UTC (permalink / raw)
  To: linux-kernel

In article <Pine.GSO.4.21.0304261459210.10838-100000@vervain.sonytel.be>,
Geert Uytterhoeven  <geert@linux-m68k.org> wrote:
>
>Hence the development rate of Linux will go down, since you cannot use your
>Linux development box running your own development kernel for anything else,
>since that would require a signed kernel.

Quite frankly, I suspect a much more likely issue is going to be that
DRM doesn't matter at all in the long run.

Maybe I'm just a blue-eyed optimist, but all the _bad_ forms of DRM look
to be just fundamentally doomed.  They are all designed to screw over
customers and normal users, and in the world I live in that's not how
you make friends (or money, which ends up being a lot more relevant to
most companies). 

Think about it.  Successful companies give their customers what they
_want_.  They don't force-feed them.  Look at the total and utter
failure of commercial on-line music: the DRM things that has been tried
have been complete failures.  Why? I'm personally convinced the cost is
only a minor issue - the _anti_convenience of the DRM crap (magic file
formats that only work with some players etc) is what really kills it in
the end. 

And that's a fundamental flaw in any "bad" DRM. It's not going away. 

We've seen this before. Remember when dongles were plentiful in the
software world? People literally had problems with having dongles on top
of dongles to run a few programs. They all died out, simply because
consumers _hate_ that kind of lock-in thing.

This is part of the reason why I have no trouble with DRM - let the
people who want to try it go right ahead. They'll only screw themselves
over in the end, because the people who do _not_ try to control their
customers will in the end have the superior product. It's that simple.

As to the quake-on-PC issue - it's a completely made-up example, but it
does show the same thing.  Nobody in their right mind would ever _do_ a
DRM-enabled quake on a PC, because it limits you too much.  PC's are
_designed_ ot be flexible - that's what makes the PC's.  DRM on a PC is
a totally braindead idea, and I _hope_ Microsoft goes down that path
because it will kill them in the end. 

The place where client authentication makes sense is on specialty boxes. 
On a dedicated game machine it's an _advantage_ to verify the client,
exactly to make sure that nobody is cheating.  I think products like the
PS2 and the Xbox actually make _sense_ - they make it convenient for the
user, and yes they use DRM techniques to "remove rights", but that's
very much by design and when you buy the box 99.9% of all people buy it
_because_ it only does one thing.

		Linus

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 18:31 ` Daniel Phillips
  2003-04-24 23:15   ` Werner Almesberger
@ 2003-04-26 18:21   ` Rik van Riel
  2003-04-26 23:34     ` Jamie Lokier
  2003-04-27  3:59     ` Werner Almesberger
  1 sibling, 2 replies; 130+ messages in thread
From: Rik van Riel @ 2003-04-26 18:21 UTC (permalink / raw)
  To: Daniel Phillips; +Cc: Linus Torvalds, Kernel Mailing List

On Thu, 24 Apr 2003, Daniel Phillips wrote:

> Open source + Linux + DRM could be used to solve the Quake client-side 
> cheating problem:
> 
>    http://catb.org/~esr/writings/quake-cheats.html
> 
> To join a game, you'd have to be able to prove you're running code that
> is secure all the way from boot to reboot, where everything from network
> driver to physics engine is known to be compiled from open source that
> all participants agree is good.

Of course, people could still use a hub for their network
connection and have a second PC sniff the network traffic
and display everything conveniently on the other monitor.


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 17:32     ` Andreas Boman
  2003-04-24 17:41       ` William Lee Irwin III
@ 2003-04-26 17:05       ` Riley Williams
  1 sibling, 0 replies; 130+ messages in thread
From: Riley Williams @ 2003-04-26 17:05 UTC (permalink / raw)
  To: Andreas Boman, Linus Torvalds; +Cc: Andre Hedrick, Kernel Mailing List

Hi all.

 >>> For those not aware, each and every kernel you download from 
 >>> K.O is DRM signed as a means to authenticate purity.

 >> Yup. And pretty much every official .rpm or .deb package (source
 >> and binary) is already signed by the company that made that
 >> package, for _your_ protection. This is already "accepted
 >> practice", so allowing signing is not something new per se,
 >> including on a binary level.

 > Sure, but today a signed kernel from $vendor doesn't prevent me
 > from running a program I compiled myself, the signature only
 > shows me that the kernel in fact came from $vendor and if I trust
 > that vendor, I can now trust that kernel. 

===8<=== CUT ===>8===

 > In the near future I'm worried about the fact that I could become
 > second class netizen if I don't run a signed $large_linux_vendor
 > kernel and userspace chain all the way up to a signed mozilla. I
 > quite like paying my bills on-line.

Unless I'm misreading the aim of this discussion to date, the result
of this whole flame-thread is quite simple:

 1. At the moment, verification companies such as VeriSign have an
    uphill struggle to get people to sign up with them, as people
    are in general willing to trust each other.

 2. The initiative that Linus started this thread about appears to
    be an attempt to maximise their profits by making every Thomas,
    Richard and Henry sign up with all of them in case they wish
    to run their own software.

 3. As a side-effect of this, every software house in the world is
    to be faced with a bill from each of the verification agencies
    to be permitted to verify their software, probably with annual
    renewal fees, the aim being to force all such software houses
    out of business so Microsoft and their cronies can relax.

Pardon me for my cynicism, but to me, this is just "more of the
same" rubbish that we have had to put up with from Micro$oft for
far too many years...

Best wishes from Riley.
---
 * Nothing as pretty as a smile, nothing as ugly as a frown.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.476 / Virus Database: 273 - Release Date: 24-Apr-2003
 


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 23:15   ` Werner Almesberger
  2003-04-25 11:28     ` Eric W. Biederman
  2003-04-25 14:37     ` Daniel Phillips
@ 2003-04-26 13:00     ` Geert Uytterhoeven
  2003-04-26 18:22       ` Linus Torvalds
  2 siblings, 1 reply; 130+ messages in thread
From: Geert Uytterhoeven @ 2003-04-26 13:00 UTC (permalink / raw)
  To: Werner Almesberger; +Cc: Daniel Phillips, Linus Torvalds, Kernel Mailing List

On Thu, 24 Apr 2003, Werner Almesberger wrote:
> Daniel Phillips wrote:
> > Open source + Linux + DRM could be used to solve the Quake client-side 
> > cheating problem:
> 
> Yes, but in return you'd be excluded from playing Quake unless
> you're running one of those signed kernels or modules.
> 
> So, if I, say, want to test some TCP fix, new VM feature, file
> system improvement, etc., none of the applications that rely on
> DRM would work. This doesn't only affect developers, but also
> their potential testers.

Hence the development rate of Linux will go down, since you cannot use your
Linux development box running your own development kernel for anything else,
since that would require a signed kernel.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-25 20:56       ` Andreas Jellinghaus
@ 2003-04-25 21:50         ` Jamie Lokier
  0 siblings, 0 replies; 130+ messages in thread
From: Jamie Lokier @ 2003-04-25 21:50 UTC (permalink / raw)
  To: Andreas Jellinghaus; +Cc: linux-kernel

Andreas Jellinghaus wrote:
> On Fri, 2003-04-25 at 21:12, Jamie Lokier wrote:
> > Because the only kernels that ISPs accept connections from are signed
> > and encrypted by the computer vendor - which means you _cannot_ trust
> > those kernels to not contain back doors.
> 
> ah, you want to put apache with mod_ssl into the kernel (now that we
> have CONFIG_CRYPTO), including the code to check for client certificates
> and the CA certificate itself? You are very welcome to do so, the GPL
> allowes this.
> 
> Still as you can see, that can also be done in userspace.

Eh?  The chain of trust can be extended to userspace too.

> Maybe you forget "and I cannot replace the kernel but I want to"?
> Now this is not very new: I cannot replace my BIOS either.
> Or in fact we could do both, it's merely the same. The hardware
> can make it difficult, but still it is a hardware issue, right?

Indeed, and I enjoy reverse engineering :)

I don't enjoy reverse engineering encryption chips with embedded keys
though.  That's out of my economic reach, not to mention that much as
I love the idea of being arse-raped daily (i.e. in prison) I don't
fancy the diseases that come with it, nor the shitty dinner menu.

> Maybe it's not such a bad idea to have two computers. One for
> entertainment, online banking and digital video rental and stuff
> like this where you deal with the paranoid and let them waste their
> money on expensive hardware. And one for real work.

Just like we have to have two computers now - one to exchange
documents with other people (Windows + Office) - another to do real
work?

Sounds great...  um.

(Ok, ok, Office isn't such a big deal any more.  (Although even now I
have Word docs that don't work in Openoffice, KOffice or Abiword)).

Ok, I relent.  I suppose it _is_ reasonable that I have one computer I
can run my choice of programs on and a different one that is capable
of connecting to the 2010 Internet.

> CDBTPA? I read "Argh Anonymous" detailed analysis on cypherpunks,
> and I recommend it to you, too. 
> 
> www.inet-one.com/cypherpunks/dir.2002.07.15-2002.07.21/msg00225.html

Thanks for the link.  Sadly the article seems to have gone missing :)

> If you have other sources that also know facts,
> please let me know. They seem kind of rare these days.

Fair point.

I speak about what this stuff _could_ be used for, as a general
warning to be diligent, rather than what is planned right now.

-- Jamie

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-25 19:12     ` Jamie Lokier
@ 2003-04-25 20:56       ` Andreas Jellinghaus
  2003-04-25 21:50         ` Jamie Lokier
  0 siblings, 1 reply; 130+ messages in thread
From: Andreas Jellinghaus @ 2003-04-25 20:56 UTC (permalink / raw)
  To: Jamie Lokier; +Cc: linux-kernel

On Fri, 2003-04-25 at 21:12, Jamie Lokier wrote:
> Because the only kernels that ISPs accept connections from are signed
> and encrypted by the computer vendor - which means you _cannot_ trust
> those kernels to not contain back doors.

ah, you want to put apache with mod_ssl into the kernel (now that we
have CONFIG_CRYPTO), including the code to check for client certificates
and the CA certificate itself? You are very welcome to do so, the GPL
allowes this.

Still as you can see, that can also be done in userspace.

Maybe you forget "and I cannot replace the kernel but I want to"?
Now this is not very new: I cannot replace my BIOS either.
Or in fact we could do both, it's merely the same. The hardware
can make it difficult, but still it is a hardware issue, right?

Or maybe you have been fooled by those who propagate that a TCPA
system will on its own create network connections or accept those.

There is no need to: you can do that in userspace a lot easier
than in a tiny hardware chip on a not bus not connected to the
network driver.

I'm a fool, but as fool I say: nothing bad in the kernel or DRM.
All the bad stuff is in the applications, so you can show the kernel,
DRM and TCPA around and claim it is nice and secure and there is
nothing to worry.

But putting bad stuff into applications is something like a tradition
and who would want to break with a tradition like this?

> The question is, if it is widely implemented in available hardware,
> _will_ everyone be using it whether they want to or not?

Maybe it's not such a bad idea to have two computers. One for
entertainment, online banking and digital video rental and stuff
like this where you deal with the paranoid and let them waste their
money on expensive hardware. And one for real work.

Nearly everyone will still provide hardware that works for a general
purpose user that wants to hack, cheat, change hardware, replace cards,
overclock and all that stuff. Or hack on linux 3.1.*.
There is soo much money in it, and companies like earning money.

> Also, what about the law?  Remember, there have been attempts in the
> last year, in the US, to legislate DRM into all computers.

CDBTPA? I read "Argh Anonymous" detailed analysis on cypherpunks,
and I recommend it to you, too. 

www.inet-one.com/cypherpunks/dir.2002.07.15-2002.07.21/msg00225.html

Lots of stuff I read is not based on facts or even on reading the laws,
specs or things like that, but on rumors and nightmares.

That is one of the few sources of someone who seems to have read the TCPA spec
and the CBDTPA law. If you have other sources that also know facts,
please let me know. They seem kind of rare these days.

Regards, Andreas


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-25  8:13   ` Andreas Jellinghaus
@ 2003-04-25 19:12     ` Jamie Lokier
  2003-04-25 20:56       ` Andreas Jellinghaus
  0 siblings, 1 reply; 130+ messages in thread
From: Jamie Lokier @ 2003-04-25 19:12 UTC (permalink / raw)
  To: Andreas Jellinghaus; +Cc: linux-kernel

Andreas Jellinghaus wrote:
> > Also that day, that same article doesn't load from Al-Jazeera or
> > anywhere else, on the PC you bought from the only affordable store in
> > town. 
> 
> ah, myth. please dig into the tcpa spec and quote where you find
> anything that provides substance for that. possible? even today without
> tcpa or DRM or anything like that.

<paranoid>
There is nothing in the tcpa spec, they'd be foolish to put the _real_
agenda in the spec wouldn't they? :)
</paranoid>

> but why does DRM or TCPA make this easier or harder to work around?

Because the only kernels that ISPs accept connections from are signed
and encrypted by the computer vendor - which means you _cannot_ trust
those kernels to not contain back doors.

> if we could asure that DRM would only be used in 0.1% of all computer
> uses, then banks and stuff could use it, maybe even that digitial video
> rental using the internet (they already do, but without hardware
> support), and everyone else will not. I don't see the problem with
> some uses, but with everyone using it.

The question is, if it is widely implemented in available hardware,
_will_ everyone be using it whether they want to or not?

Also, what about the law?  Remember, there have been attempts in the
last year, in the US, to legislate DRM into all computers.

-- Jamie

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-25 14:37     ` Daniel Phillips
  2003-04-25 15:17       ` Valdis.Kletnieks
@ 2003-04-25 17:37       ` Werner Almesberger
  2003-04-26 21:59         ` Daniel Phillips
  1 sibling, 1 reply; 130+ messages in thread
From: Werner Almesberger @ 2003-04-25 17:37 UTC (permalink / raw)
  To: Daniel Phillips; +Cc: Linus Torvalds, Kernel Mailing List

Daniel Phillips wrote:
> I imagine the likelihood of people running completely separate DRM Linux
> boxes, just to participate in DRM-controlled online games, is not high.

You could still dual-boot, as many people do today.

> the whole concept is inherently fragile, there are just too many parts
> involved.

... and companies relying on DRM are likely to distrust Linux for
every single such flaw that is found. They'll put up with Windows,
because they have to.

It all makes sense - in some ugly, twisted way.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-25 12:29   ` Ragnar Hojland Espinosa
@ 2003-04-25 15:45     ` Timothy Miller
  0 siblings, 0 replies; 130+ messages in thread
From: Timothy Miller @ 2003-04-25 15:45 UTC (permalink / raw)
  To: Ragnar Hojland Espinosa; +Cc: Downing, Thomas, Kernel Mailing List



Ragnar Hojland Espinosa wrote:

>  
>
>>    
>>
>
>What I don't get is why would you think MS you'd be able to open MS docs with
>open office, or how would Wine work.  Or even more simple, would you be able
>to just plug a samba server and that it would be recognized by MS clients as
>a trusted party?
>
>I must surely be missing something..
>  
>

Likewise.  I totally don't understand your question.



^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-25 14:37     ` Daniel Phillips
@ 2003-04-25 15:17       ` Valdis.Kletnieks
  2003-04-25 17:37       ` Werner Almesberger
  1 sibling, 0 replies; 130+ messages in thread
From: Valdis.Kletnieks @ 2003-04-25 15:17 UTC (permalink / raw)
  To: Daniel Phillips; +Cc: Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 497 bytes --]

On Fri, 25 Apr 2003 16:37:31 +0200, Daniel Phillips said:

> To get cheatless online gaming, you would have to necessarily give up a lot 
> of flexibility.  I imagine the likelihood of people running completely 
> separate DRM Linux boxes, just to participate in DRM-controlled online games,
 
> is not high.  Only when if you are faced with absolute necessity of running 
> DRM, are you actually going to do it by choice.  There's going to be a whole 

How many people own both a PC and an XBox?

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 23:15   ` Werner Almesberger
  2003-04-25 11:28     ` Eric W. Biederman
@ 2003-04-25 14:37     ` Daniel Phillips
  2003-04-25 15:17       ` Valdis.Kletnieks
  2003-04-25 17:37       ` Werner Almesberger
  2003-04-26 13:00     ` Geert Uytterhoeven
  2 siblings, 2 replies; 130+ messages in thread
From: Daniel Phillips @ 2003-04-25 14:37 UTC (permalink / raw)
  To: Werner Almesberger; +Cc: Linus Torvalds, Kernel Mailing List

On Friday 25 April 2003 01:15, Werner Almesberger wrote:
> Daniel Phillips wrote:
> > Open source + Linux + DRM could be used to solve the Quake client-side
> > cheating problem:
>
> Yes, but in return you'd be excluded from playing Quake unless
> you're running one of those signed kernels or modules.
>
> So, if I, say, want to test some TCP fix, new VM feature, file
> system improvement, etc., none of the applications that rely on
> DRM would work. This doesn't only affect developers, but also
> their potential testers.

Yes, Ick.  You might see some kind of Linux-Trusted-Quake club rise up, with 
the specific goal of running cheatless deathmatches, but we are getting very 
far from reality here.

To get cheatless online gaming, you would have to necessarily give up a lot 
of flexibility.  I imagine the likelihood of people running completely 
separate DRM Linux boxes, just to participate in DRM-controlled online games, 
is not high.  Only when if you are faced with absolute necessity of running 
DRM, are you actually going to do it by choice.  There's going to be a whole 
pile of new ways for computers to fail to work too, because of this.  Then 
there's the certainty that there will be exploits - the whole concept is 
inherently fragile, there are just too many parts involved.  From a security 
point of view, we would end up worse off than without it, given a newfound 
false sense of security.

So, just call all of the above a valiant effort on my part to find something 
good about this.  Hopefully, after a few years of silliness and much wasted 
effort, it will all fade away like copy-protected floppy disks.

Regards,

Daniel

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 21:38                 ` John Bradford
  2003-04-25  3:20                   ` Shawn
@ 2003-04-25 14:03                   ` Mike Dresser
  1 sibling, 0 replies; 130+ messages in thread
From: Mike Dresser @ 2003-04-25 14:03 UTC (permalink / raw)
  To: John Bradford; +Cc: Kernel Mailing List



On Thu, 24 Apr 2003, John Bradford wrote:

> > > We could always consider wiring everything up with discrete logic.
> > > Anyone got any spare 74138's?
> >
> > I need 1 billion of them please, and I need the overclockable ones :)
>
> Why not just buy one of those 100-in-1 electronics kits from your
> local electonics hobbyist store, and make your very own wire wrap CPU?

They don't usually come with the needed 70W .01 ohm resistor you'd need
to completely emulate a modern cpu.

Mike


^ permalink raw reply	[flat|nested] 130+ messages in thread

* RE: Flame Linus to a crisp!
  2003-04-24 22:45     ` Alan Cox
  2003-04-24 23:59       ` Daniel Phillips
@ 2003-04-25 13:01       ` David Luyer
  1 sibling, 0 replies; 130+ messages in thread
From: David Luyer @ 2003-04-25 13:01 UTC (permalink / raw)
  To: 'Alan Cox', 'Daniel Phillips'
  Cc: 'Jamie Lokier', 'Downing, Thomas',
	'Linux Kernel Mailing List'

> On Iau, 2003-04-24 at 22:42, Daniel Phillips wrote:
> > A more mundane goal would be to prevent the 3D driver from 
> > letting you see through polygons that are supposed to be
> > opaque.
> 
> In the MUD world we solved that by not telling anyone about 
> objects they can't see. 

The problem is not solved in the MUD world particularly well.

Sure, you can not transmit the location of other players, but
the client software (eg. zmud) can still give the client an
advantage over the "innocent telnet using client", by doing
things like keeping a map and tracking your current location
(and even using point-and-click to go to any previously seen
location).

Discworld as an example had an area with left,right,back,forward
directions which zmud was later enhanced to handle.  So to
make things a little harder they changed descriptions a little
when "anomolies" appeared so automated "return to previous
point" procedures would walk through the anomoly and get warped
into a reality with hard to determine rules (directions
left,right,forward,back, but if you go left four times you don't
end up where you started).

And there are other problems from the MUD world that have
parallels in 3D online gaming... triggers, for example.

Even colourization of MUD text by something like TF is
equivalent to 3D drivers doing some kind of enhancement
on distant objects (showing you the distant player movement
that would otherwise be barely percievable).

I'm not holding my breath for the first MUD to use DRM to
ensure the end-user is directly connected to a keyboard
with no triggers, mapping, colourization, etc in between
though :-)

Even if such a setup was possible, and say the keyboard was
even a "signed device", you could still setup a mechanical
device to override the keys for you and some OCR software on
a second PC reading the screen's display and displaying the
colourized version, processing triggers, generating maps,
etc.  There is sufficient technology available these days
that DRM would be insufficient to even protect a MUD from
the most basic forms of cheating.

David.


^ permalink raw reply	[flat|nested] 130+ messages in thread

* RE: Flame Linus to a crisp!
@ 2003-04-25 12:57 Downing, Thomas
  0 siblings, 0 replies; 130+ messages in thread
From: Downing, Thomas @ 2003-04-25 12:57 UTC (permalink / raw)
  To: John Bradford, jamie; +Cc: core, miller, phillips, wli, torvalds, linux-kernel

From: John Bradford [mailto:john@grabjohn.com]

>> > I'd like to see an x86 completely in perf board. I thought my high
>> > school digital electronics type stuff looked bad...
>> 
>> You could do it nowadays using dynamic binary translation, and an
>> absurdly simple CPU capable of accessing a large memory.  You'd need a
>> DIMM for the large memory, but get away with discrete logic for the
>> CPU if you really wanted to.
>> 
>> At perf board sizes using discrete logic, expect it run run quite slow :)
>
> Could we not take this idea to it's logical extreme, and simply
> calculate the results of every opcode, on every value, for every state
> of all of the registers, and store them in an array of DIMMs, and
> simply look up the necessary results?  I.E. a cpu which is one _huge_
> look up table :-).
>
> John.

NOW your'e talking! Alan Turing meets Julian Barbour.

^ permalink raw reply	[flat|nested] 130+ messages in thread

* RE: Flame Linus to a crisp!
@ 2003-04-25 12:41 Downing, Thomas
  0 siblings, 0 replies; 130+ messages in thread
From: Downing, Thomas @ 2003-04-25 12:41 UTC (permalink / raw)
  To: Daniel Phillips, Alan Cox; +Cc: Jamie Lokier, Linux Kernel Mailing List

From: Daniel Phillips [mailto:phillips@arcor.de]

>On Fri 25 Apr 03 00:45, Alan Cox wrote:
>> On Iau, 2003-04-24 at 22:42, Daniel Phillips wrote:
>> > A more mundane goal would be to prevent the 3D driver from letting you
>> > see through polygons that are supposed to be opaque.
>>
>> In the MUD world we solved that by not telling anyone about objects they
>> can't see.
>
> Doing the visibility calculations on the server, down to the pixel, is 
> possible but not really practical.
>
> Regards,
>
> Daniel

Just goes to show that the VDU was the acme of the compute world,
it's been all down hill since... ;-)

^ permalink raw reply	[flat|nested] 130+ messages in thread

* RE: Flame Linus to a crisp!
@ 2003-04-25 12:36 Downing, Thomas
  2003-04-27  7:25 ` Adrian Bunk
  0 siblings, 1 reply; 130+ messages in thread
From: Downing, Thomas @ 2003-04-25 12:36 UTC (permalink / raw)
  To: Adrian Bunk, Linus Torvalds; +Cc: William Lee Irwin III, Kernel Mailing List

From: Adrian Bunk [mailto:bunk@fs.tum.de]

>On Wed, Apr 23, 2003 at 10:43:37PM -0700, Linus Torvalds wrote:
>>...
>> And hey, the fact is (at least as far as I'm concerned), that as long as
>> you make the hardware, you can control what it runs.
>>...
>
>Linux is currently widely used and through this there comes some power. 
>Let me try to make examples where this might be important:

You cast these comments in the context of corporate use, so -

The primary reason corporations are beginning to adopt Linux is TCO
- and such adoption is in its early stages, though growing.  Such
adoption is _only_ to the extent that Linux will run specific
applications.

Companies do _not_ adopt Linux because it is the only OS on which
their critical applications run.  They don't adopt it because it's
the coolest OS out there.  All the corporate required applications 
run on other O$'s.  If support for a facility percieved as desirable
or necessary (in this case, DRM)is not available in Linux due to the
terms of the GPL, corporations will drop Linux in a heartbeat.

Some companies (viz certain very large financial institutions) are
only now just beginning to write applications _on_ Linux.  When
Linux has a majority market share, with the rest of the market in
disarray, _then_ you have some power; but only for a limitted time.

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 14:12 ` Timothy Miller
  2003-04-24 22:48   ` Werner Almesberger
@ 2003-04-25 12:29   ` Ragnar Hojland Espinosa
  2003-04-25 15:45     ` Timothy Miller
  1 sibling, 1 reply; 130+ messages in thread
From: Ragnar Hojland Espinosa @ 2003-04-25 12:29 UTC (permalink / raw)
  To: Timothy Miller; +Cc: Downing, Thomas, Kernel Mailing List

On Thu, Apr 24, 2003 at 10:12:22AM -0400, Timothy Miller wrote:
> 
> As much as I dislike Microsoft for its business practices, I still feel 
> uneasy having illegal copies of their Office suite.  So I use OpenOffice 
> instead.  Likewise, I prefer to use Linux because having a free copy of 
> it is perfectly legal.  And finally, although I do like the idea of 
> being able to sample music before I buy it, I feel an attachment to 
> artists I listen to, so I buy their CD's (despite the fact that it helps 
> the RIAA).
 
> So the idea of having something which prevents me from illegally 
> pirating something doesn't bother me so much.  Whenever I have to do 
> serious work, I either use an OSS tool, or I pay money for a piece of 
> software so I can get support -- sometimes, I even pay for OSS stuff. 
> The idea of a DRM system malfunctioning and preventing me from 
> accessing my legally-licensed material DOES bother me very much, but I 
> think only in the hands of people like us can it be done right, because 
> we're the very ones who would suffer were it to break.

What I don't get is why would you think MS you'd be able to open MS docs with
open office, or how would Wine work.  Or even more simple, would you be able
to just plug a samba server and that it would be recognized by MS clients as
a trusted party?

I must surely be missing something..
-- 
Ragnar Hojland - Project Manager
Linalco "Especialistas Linux y en Software Libre"
http://www.linalco.com Tel: +34-91-5970074 Fax: +34-91-5970083

^ permalink raw reply	[flat|nested] 130+ messages in thread

* RE: Flame Linus to a crisp!
@ 2003-04-25 12:23 Downing, Thomas
  0 siblings, 0 replies; 130+ messages in thread
From: Downing, Thomas @ 2003-04-25 12:23 UTC (permalink / raw)
  To: Jamie Lokier; +Cc: Daniel Phillips, Kernel Mailing List



-----Original Message-----
Jamie Lokier [mailto:jamie@shareable.org]

>Downing, Thomas wrote:
>> How does the server _know_ that the BIOS is what it says it is? Again,
>> what's the protocol?  Saying that they 'have a chat' is bypassing
>> the hard bits.
>> 
>> If I have the BIOS, any secrets it holds are now knowable to me.
>> This means that any protocol that relies on a secret in the BIOS is
>> broken from the start.  So now you need to define a protocol which
>> does not rely on any secret being known to the BIOS.  What is this
> protocol?
>
>What makes you think you can read the BIOS?
If it is a BIOS in the PC-compatible sense, of course I can.
>
>> The proposed 'end-to-end' copy protection schemes for entertainment
>> media etc, rely on proprietary _hardware_.
>
>Yes, that's the severe version of DRM that we're talking about, for
>the game server scenario.
I though that this was in reference to a way to solve Quake etc.
cheating in the current hardware environment.  I you pull in 
extra hardware, the equation changes.
>
>> This is still beatable, although at a higher cost.  Nor is the
>> problem quite parallel.  The broadcast problem is 'how do we keep
>> content encrypted till the last possible moment?' and 'how do we
>> keep the decryption engine tamper proof reverse engineering proof'.
>> The first part is easy.  The second part is not possible in an
>> absolute sense.  It can only be made more or less dificult.  Hence
>> the DMCA etc.
>
>We don't know for sure that it's not possible to make something
>reverse engineering proof.  Although all current CPUs require code to
>be decrypted at some point, there may be modules of computation that
>don't require that, so there would be no way to extract the secret key
>or decryption process in a useful way even when you can see every
>electronic signal in a device.  The jury is out on it, despite what
>slashdotters believe.
>
>-- Jamie

Depends on who sits on the jury.  With few if any exceptions, the top
people in the security field would agree with what I said.  That's not
because I'm brilliant, it's because I'm just parrotting back what
they have said.

As is often said, security is all shades of grey.  It may well be
possible to make a device that is so hard to reverse engineer and so
hard to hack, that it offers protection that lasts as long as the
effective market life of the thing it is protecting.  At that point
it is good enough.  Now you have a foundation on which to base
the required protocol.  You are now done from the theoretic side,
and this debate comes to an end; you have your Quake-cheat blocker.

But if you go on to consider the practical side, even now you have
only solved the easy part: the tough part is correctly implementing
the entire 'soft' chain from this device to the corresponding device
on the server.  Now _that's_ not easy.

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-25  6:08               ` Jan-Benedict Glaw
@ 2003-04-25 11:46                 ` Antonio Vargas
  0 siblings, 0 replies; 130+ messages in thread
From: Antonio Vargas @ 2003-04-25 11:46 UTC (permalink / raw)
  To: Kernel Mailing List

On Fri, Apr 25, 2003 at 08:08:05AM +0200, Jan-Benedict Glaw wrote:
> On Thu, 2003-04-24 17:37:59 -0400, Timothy Miller <miller@techsource.com>
> wrote in message <3EA85937.3050109@techsource.com>:
> > Jamie Lokier wrote:
> 
> > We could always consider wiring everything up with discrete logic. 
> > Anyone got any spare 74138's?
> 
> Erm, we'd try to get speeds about MHz, not Hz or kHz for the whole
> processor:)

Slower hardware means we _really_ notice and _enjoy_ optimisations :)

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 23:15   ` Werner Almesberger
@ 2003-04-25 11:28     ` Eric W. Biederman
  2003-04-27  1:31       ` Werner Almesberger
  2003-04-25 14:37     ` Daniel Phillips
  2003-04-26 13:00     ` Geert Uytterhoeven
  2 siblings, 1 reply; 130+ messages in thread
From: Eric W. Biederman @ 2003-04-25 11:28 UTC (permalink / raw)
  To: Werner Almesberger; +Cc: Daniel Phillips, Linus Torvalds, Kernel Mailing List

Werner Almesberger <wa@almesberger.net> writes:

> Daniel Phillips wrote:
> > Open source + Linux + DRM could be used to solve the Quake client-side 
> > cheating problem:
> 
> Yes, but in return you'd be excluded from playing Quake unless
> you're running one of those signed kernels or modules.

In this context, the only thing I know has been openly discussed
is to have a BIOS that includes a public key of my choosing for
authentication.
 
> So, if I, say, want to test some TCP fix, new VM feature, file
> system improvement, etc., none of the applications that rely on
> DRM would work. This doesn't only affect developers, but also
> their potential testers.

Not so because in a general purpose system the owners of the
system control the keys.
 
> Given that most users will just run a distribution's kernel, with
> all the right signatures, companies will not perceive the few
> cases in which their use of DRM causes problems as very important,
> so they will use DRM.

Redhat's kernel is unlikely to get my signature.  Possibly
at some point there will be a web of trust where that will work
but in the first approximation distributors kernels will not
load until I sign them.
 
> Oh, maybe some developers could be granted the privilege of being
> able to sign their own kernels or modules. So if you're part of
> this circle, you'd be fine, right ? No, even this doesn't work,
> because if you'd leak such a key, you'd certainly get sued for
> damages. And I don't think many people would feel overly pleased
> with the idea of being responsible for the safekeeping of the key
> to a multi-million lawsuit. (And besides, this may turn them into
> targets for key theft/robbery/extortion.)
> 
> (There are of course uses of such signatures that would not have
> those problems. E.g. signatures that prove trustworthiness to the
> local user, instead of a remote party.)

Yes.  And there has been some limited discussion on LinuxBIOS list
about implementing these. 

Eric

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 23:59       ` Daniel Phillips
@ 2003-04-25  9:07         ` Helge Hafting
  0 siblings, 0 replies; 130+ messages in thread
From: Helge Hafting @ 2003-04-25  9:07 UTC (permalink / raw)
  To: Daniel Phillips; +Cc: linux-kernel

Daniel Phillips wrote:
> On Fri 25 Apr 03 00:45, Alan Cox wrote:
[...]
>>In the MUD world we solved that by not telling anyone about objects they
>>can't see.
> 
> Doing the visibility calculations on the server, down to the pixel, is 
> possible but not really practical.
> 
Sure, but one can do better than quake.  The server can have
a look at the "terrain" at startup, and divide it into a
bunch of regions and calculate which regions cannot
bee seen from each other.  You can then do
fast simplified visibility calculation on the server,
by looking up positions in a lookup table. Players
in tunnels and such isn't visible from most of the
level so such structures would then provide the
desired surprises - even for cheaters.

Also, one can use a representation that makes it hard for
an AI to guess what is "wall" and what is a "player".
The players could be polygons just like everything else,
and a good level would have more moving items than
players so movement detection won't be a good
heuristic either.

Helge Hafting





^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-25  7:02                       ` John Bradford
@ 2003-04-25  8:52                         ` Helge Hafting
  0 siblings, 0 replies; 130+ messages in thread
From: Helge Hafting @ 2003-04-25  8:52 UTC (permalink / raw)
  To: John Bradford; +Cc: linux-kernel

John Bradford wrote:

> Could we not take this idea to it's logical extreme, and simply
> calculate the results of every opcode, on every value, for every state
> of all of the registers, and store them in an array of DIMMs, and
> simply look up the necessary results?  I.E. a cpu which is one _huge_
> look up table :-).

You can, if you can keep the internal state sufficiently small.
Say we want to keep the internal state down to 32 bit,
using a 16GB lookup table. (4G*32bit)

What would the state be?  Perhaps one general-purpose
8-bit register, a 16-bit program counter and
8 bits left for the current opcode & flags.

Less opportunities than a 6502, but it'd sure be fast.

Helge Hafting



^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 21:28 ` Jamie Lokier
  2003-04-24 21:42   ` Daniel Phillips
@ 2003-04-25  8:13   ` Andreas Jellinghaus
  2003-04-25 19:12     ` Jamie Lokier
  1 sibling, 1 reply; 130+ messages in thread
From: Andreas Jellinghaus @ 2003-04-25  8:13 UTC (permalink / raw)
  To: linux-kernel

> So, the game server and the BIOS have a chat, through the operating
> system (which counts as an insecure link), and the BIOS tells the
> server that it is the correct DRM BIOS, and it loaded a signed kernel.

[lots of additional chats]

that does not work: the server could chat with a bios in a vmware
unaware of that fact.

but tcpa is a solution to that problem. first it doesn't need 
all those chats but only one where a list of hash value with
a signature is transmitted. the hash values represent the software
packages (such as bios, boot loader, kernel, drivers, ...)
and the signature proofs its authentity.

second the signature proofs the non virtualization:
a key and certificate is required to do that, and the
cert is checked if it has a chain to one root and it
is not revoked. such certificates are only created
by trusted hardware manufacturers and they certify
only real hardware with the private key in a TPM module
that cannot export the key.

however, if someone opens a TPM module and reads the
content physicaly, then the trust is gone (at least
till someone finds out and that key is revoked).
IBM claims their TPM module containt no hardware security
(like that stuff usualy found in smartcards).

> Substitute "broadcaster" for "game server" and you see that the same
> methods ensure that you really have the TV switched on and you are not
> recording the show.

absolutely correct.

But I'd like a small usb device that is like "broadcaster" or "game
server" and tells me when plugged into any machine "this is secure,
no trojans/backdoors/key sniffing software installed". But that might
be even harder to do?

> They also ensure you are not recording a screenshot of a politically
> sensitive article about Iraq that was accidentally shown on CNN's web
> site for 10 minutes.  We can't have people recording things like that.

Hey, good we still have normal photos.  and usualy you can "print"
things on webpages.


> Also that day, that same article doesn't load from Al-Jazeera or
> anywhere else, on the PC you bought from the only affordable store in
> town. 

ah, myth. please dig into the tcpa spec and quote where you find
anything that provides substance for that. possible? even today without
tcpa or DRM or anything like that. but why does DRM or TCPA make this
easier or harder to work around?

if we could asure that DRM would only be used in 0.1% of all computer
uses, then banks and stuff could use it, maybe even that digitial video
rental using the internet (they already do, but without hardware
support), and everyone else will not. I don't see the problem with
some uses, but with everyone using it.

Andreas

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-25  5:47                     ` Jamie Lokier
@ 2003-04-25  7:02                       ` John Bradford
  2003-04-25  8:52                         ` Helge Hafting
  0 siblings, 1 reply; 130+ messages in thread
From: John Bradford @ 2003-04-25  7:02 UTC (permalink / raw)
  To: Jamie Lokier
  Cc: Shawn, John Bradford, Timothy Miller, Daniel Phillips,
	William Lee Irwin III, Linus Torvalds, Kernel Mailing List

> > I'd like to see an x86 completely in perf board. I thought my high
> > school digital electronics type stuff looked bad...
> 
> You could do it nowadays using dynamic binary translation, and an
> absurdly simple CPU capable of accessing a large memory.  You'd need a
> DIMM for the large memory, but get away with discrete logic for the
> CPU if you really wanted to.
> 
> At perf board sizes using discrete logic, expect it run run quite slow :)

Could we not take this idea to it's logical extreme, and simply
calculate the results of every opcode, on every value, for every state
of all of the registers, and store them in an array of DIMMs, and
simply look up the necessary results?  I.E. a cpu which is one _huge_
look up table :-).

John.

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 21:37             ` Timothy Miller
  2003-04-24 21:30               ` Jamie Lokier
@ 2003-04-25  6:08               ` Jan-Benedict Glaw
  2003-04-25 11:46                 ` Antonio Vargas
  1 sibling, 1 reply; 130+ messages in thread
From: Jan-Benedict Glaw @ 2003-04-25  6:08 UTC (permalink / raw)
  To: Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

On Thu, 2003-04-24 17:37:59 -0400, Timothy Miller <miller@techsource.com>
wrote in message <3EA85937.3050109@techsource.com>:
> Jamie Lokier wrote:

> We could always consider wiring everything up with discrete logic. 
> Anyone got any spare 74138's?

Erm, we'd try to get speeds about MHz, not Hz or kHz for the whole
processor:)

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-25  3:20                   ` Shawn
@ 2003-04-25  5:47                     ` Jamie Lokier
  2003-04-25  7:02                       ` John Bradford
  0 siblings, 1 reply; 130+ messages in thread
From: Jamie Lokier @ 2003-04-25  5:47 UTC (permalink / raw)
  To: Shawn
  Cc: John Bradford, Timothy Miller, Daniel Phillips,
	William Lee Irwin III, Linus Torvalds, Kernel Mailing List

Shawn wrote:
> I'd like to see an x86 completely in perf board. I thought my high
> school digital electronics type stuff looked bad...

You could do it nowadays using dynamic binary translation, and an
absurdly simple CPU capable of accessing a large memory.  You'd need a
DIMM for the large memory, but get away with discrete logic for the
CPU if you really wanted to.

At perf board sizes using discrete logic, expect it run run quite slow :)

-- Jamie

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 21:38                 ` John Bradford
@ 2003-04-25  3:20                   ` Shawn
  2003-04-25  5:47                     ` Jamie Lokier
  2003-04-25 14:03                   ` Mike Dresser
  1 sibling, 1 reply; 130+ messages in thread
From: Shawn @ 2003-04-25  3:20 UTC (permalink / raw)
  To: John Bradford
  Cc: Jamie Lokier, Timothy Miller, Daniel Phillips,
	William Lee Irwin III, Linus Torvalds, Kernel Mailing List

I'd like to see an x86 completely in perf board. I thought my high
school digital electronics type stuff looked bad...

On Thu, 2003-04-24 at 17:38, John Bradford wrote:
> > > We could always consider wiring everything up with discrete logic. 
> > > Anyone got any spare 74138's?
> > 
> > I need 1 billion of them please, and I need the overclockable ones :)
> 
> Why not just buy one of those 100-in-1 electronics kits from your
> local electonics hobbyist store, and make your very own wire wrap CPU?
> 
> John.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-25  1:16           ` Jan Harkes
@ 2003-04-25  1:35             ` Stan Bubrouski
  0 siblings, 0 replies; 130+ messages in thread
From: Stan Bubrouski @ 2003-04-25  1:35 UTC (permalink / raw)
  To: Kernel Mailing List

Jan Harkes wrote:


> Are companies required to provide me (as legal owner) of a new copy/CD
> when my harddrive breaks, as the new harddrive will probably change the
> 'trusted' signature of my 'legal playback device'.  What if I buy a new
> computer/player, and all my licensed applications have to be resigned?
> 

Yeah seriously...there are so many issues with DRM that are not clear
cut and have yet to be worked out properly.  Competing ideas with
completely different strategies does not bode well with me.  As a
consumer the idea is absurd until something stable, legal, AND FAIR is
implemented.  Until then I don't even want to see this issue again
on this list because it is moot.  How many DRM prodcts support Linux or
even plan to...yeah...most of them are win32  and have no plans for
even Macs nevermind Linux...

-Stan

> Jan



^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  8:03         ` Jan-Benedict Glaw
@ 2003-04-25  1:16           ` Jan Harkes
  2003-04-25  1:35             ` Stan Bubrouski
  0 siblings, 1 reply; 130+ messages in thread
From: Jan Harkes @ 2003-04-25  1:16 UTC (permalink / raw)
  To: Kernel Mailing List

On Thu, Apr 24, 2003 at 10:03:26AM +0200, Jan-Benedict Glaw wrote:
> On Thu, 2003-04-24 08:44:00 +0100, Jamie Lokier <jamie@shareable.org>
> wrote in message <20030424074400.GD28253@mail.jlokier.co.uk>:
> > It only gets _really_ bad when it becomes illegal to make your own
> > hardware :(
> 
> We're basically already at that point. IIRC, I've read an article about
> something called "Super-DMCA" which prevents you (beside other things) to
> build up "systems" that could scrambl/encrypt sounds for pretected
> transmission (think VoIP over ssh or something like that in hardware).

If is really is that generic, it would be the final blow to copyright
protection. As it also makes it illegal to scramble satellite feeds,
pay-only cable tv, or add DRM to music files that are to be distributed
across the internet. I haven't read the Super-DMCA, but that
interpretation doesn't sound right.

What bothers me about DRM schemes is that they typically only protect
the rights of one party. Copyrights provided temporary protection under
law, what happens when the copyright expires? What happens when congress
tags another 30 years to the lifetime of the copyright, and if I move to
or go on holiday to another country that has a different copyright
expiration date.

Are companies required to provide me (as legal owner) of a new copy/CD
when my harddrive breaks, as the new harddrive will probably change the
'trusted' signature of my 'legal playback device'.  What if I buy a new
computer/player, and all my licensed applications have to be resigned?

Jan

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 22:54             ` Werner Almesberger
@ 2003-04-25  0:26               ` Jamie Lokier
  0 siblings, 0 replies; 130+ messages in thread
From: Jamie Lokier @ 2003-04-25  0:26 UTC (permalink / raw)
  To: Werner Almesberger
  Cc: Alan Cox, Timothy Miller, Andreas Jellinghaus, Linux Kernel Mailing List

Werner Almesberger wrote:
> > Change the rules against the status quo and they all complain, but it
> > is just change and they also all adapt to it.  That is business too.
> 
> In some cases, they show remarkable reluctance to embrace change,
> though. Just consider the enthusiastic response of RIAA, MPAA, etc.
> to how the Internet has improved everybody's ability to distribute
> information.

IMHO the RIAA and MPAA are playing their role perfectly.  While they
_may_ represent pure greed, that greed produces things - mass market
music and films, mass market "stardom" to believe in and follow - that
large numbers of people still want, even though there are plenty of
readily available alternatives.

So long as people want the things that RIAA and MPAA are involved in
creating, but do not want to pay for it, _and_ for the most part just
want to copy because they enjoy saving money, rather than really
thinking through how to create a better, fluffier world, with
sustainable economics in a new form, then the RIAA and MPAA _must_ do
what they do - a role is created, and they fulfil it.

Just ignore the RIAA and MPAA, and listen/watch other stuff.
There's plenty of it.  And support the creators of stuff you like.

If only a few people do that, they may end up stuck in paid-for laws.
If a lot of people do it, though, problem solved.

IMVHO of course :)

-- Jamie

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 10:54       ` Felipe Alfaro Solana
@ 2003-04-25  0:07         ` Clemens Schwaighofer
  0 siblings, 0 replies; 130+ messages in thread
From: Clemens Schwaighofer @ 2003-04-25  0:07 UTC (permalink / raw)
  To: Felipe Alfaro Solana; +Cc: Linus Torvalds, Kernel Mailing List

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Felipe Alfaro Solana wrote:

> On Thu, 2003-04-24 at 07:02, Clemens Schwaighofer wrote:
>
> Can I trust you? Uhmm... Are you really Clemens? Please, prove it with
> this simply challenge: what was the kernel version that first introduced
> explicit return codes in drivers for stating that an IRQ was handled?
> ;-)

I am Clemens, because I really don't know these important details :D

> All of this DRM stuff gives me headaches.

I think it give all thinking people headache, doesn't it? Especially
when you see why it should be used. To control everybody. No wonder they
keep the education budged low in ALL countries around the world ...

panem et circences

- --
Clemens Schwaighofer - IT Engineer & System Administration
==========================================================
Tequila Japan, 6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN
Tel: +81-(0)3-3545-7703            Fax: +81-(0)3-3545-7343
http://www.tequila.jp
==========================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+qHxOjBz/yQjBxz8RAleaAJ9E0J4kqRrhlij6zNu/GMw/xA0xMQCfYBZ5
Ht8vluzC8L8EiM2XZmOzZUk=
=pLkV
-----END PGP SIGNATURE-----


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 22:45     ` Alan Cox
@ 2003-04-24 23:59       ` Daniel Phillips
  2003-04-25  9:07         ` Helge Hafting
  2003-04-25 13:01       ` David Luyer
  1 sibling, 1 reply; 130+ messages in thread
From: Daniel Phillips @ 2003-04-24 23:59 UTC (permalink / raw)
  To: Alan Cox; +Cc: Jamie Lokier, Downing, Thomas, Linux Kernel Mailing List

On Fri 25 Apr 03 00:45, Alan Cox wrote:
> On Iau, 2003-04-24 at 22:42, Daniel Phillips wrote:
> > A more mundane goal would be to prevent the 3D driver from letting you
> > see through polygons that are supposed to be opaque.
>
> In the MUD world we solved that by not telling anyone about objects they
> can't see.

Doing the visibility calculations on the server, down to the pixel, is 
possible but not really practical.

Regards,

Daniel

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 18:31 ` Daniel Phillips
@ 2003-04-24 23:15   ` Werner Almesberger
  2003-04-25 11:28     ` Eric W. Biederman
                       ` (2 more replies)
  2003-04-26 18:21   ` Rik van Riel
  1 sibling, 3 replies; 130+ messages in thread
From: Werner Almesberger @ 2003-04-24 23:15 UTC (permalink / raw)
  To: Daniel Phillips; +Cc: Linus Torvalds, Kernel Mailing List

Daniel Phillips wrote:
> Open source + Linux + DRM could be used to solve the Quake client-side 
> cheating problem:

Yes, but in return you'd be excluded from playing Quake unless
you're running one of those signed kernels or modules.

So, if I, say, want to test some TCP fix, new VM feature, file
system improvement, etc., none of the applications that rely on
DRM would work. This doesn't only affect developers, but also
their potential testers.

Given that most users will just run a distribution's kernel, with
all the right signatures, companies will not perceive the few
cases in which their use of DRM causes problems as very important,
so they will use DRM.

Oh, maybe some developers could be granted the privilege of being
able to sign their own kernels or modules. So if you're part of
this circle, you'd be fine, right ? No, even this doesn't work,
because if you'd leak such a key, you'd certainly get sued for
damages. And I don't think many people would feel overly pleased
with the idea of being responsible for the safekeeping of the key
to a multi-million lawsuit. (And besides, this may turn them into
targets for key theft/robbery/extortion.)

(There are of course uses of such signatures that would not have
those problems. E.g. signatures that prove trustworthiness to the
local user, instead of a remote party.)

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 22:41           ` Jamie Lokier
@ 2003-04-24 22:54             ` Werner Almesberger
  2003-04-25  0:26               ` Jamie Lokier
  0 siblings, 1 reply; 130+ messages in thread
From: Werner Almesberger @ 2003-04-24 22:54 UTC (permalink / raw)
  To: Jamie Lokier
  Cc: Alan Cox, Timothy Miller, Andreas Jellinghaus, Linux Kernel Mailing List

Jamie Lokier wrote:
> Change the rules against the status quo and they all complain, but it
> is just change and they also all adapt to it.  That is business too.

In some cases, they show remarkable reluctance to embrace change,
though. Just consider the enthusiastic response of RIAA, MPAA, etc.
to how the Internet has improved everybody's ability to distribute
information.

Anyway, the question is then what the current trends are. As Linus
has pointed out, there are desirable and there are undesirable
uses of DRM. If endorsing DRM will just get us flooded with the
undesirable ones, plus an insignificant number of the desirable
ones, we'll have made a lousy deal.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  5:43   ` Linus Torvalds
  2003-04-24  6:15     ` William Lee Irwin III
  2003-04-24 10:57     ` Giuliano Pochini
@ 2003-04-24 22:51     ` Adrian Bunk
  2 siblings, 0 replies; 130+ messages in thread
From: Adrian Bunk @ 2003-04-24 22:51 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: William Lee Irwin III, Kernel Mailing List

On Wed, Apr 23, 2003 at 10:43:37PM -0700, Linus Torvalds wrote:
>...
> And hey, the fact is (at least as far as I'm concerned), that as long as
> you make the hardware, you can control what it runs.
>...

Linux is currently widely used and through this there comes some power. 
Let me try to make examples where this might be important:

Fact is:
Cryptographic hardware isn't science fiction. It's not an unsolvable 
technical problem to build a computer and to ensure that only 
$signed_kernel with $binary_only_module loaded and no other modules 
loaded runs on this computer.

Two examples that might make it very important whether the licence of 
Linux allows things like:
1. all the companies participating in TCPA agree that only selected 
   signed kernels run on future hardware
2. [less likely] a big country like the USA makes a law that every OS 
   must include a backdoor that allows unnoticed access for the NSA (it 
   sounds strange but considering the DMCA and current legislative 
   proposals in the USA I wouldn't say this is completely impossible)

That's the point where the fact that Linux is used in many companies 
including big ones becomes important:

For companies it wouldn't be a big problem to use only signed kernels in 
a scenario like the first one above (because of support rules of 
companies like Oracle or SAP they are already often tied to some 
specific kernels) if the licence of Linux allows it.

If the licence of Linux doesn't allow this it would make many of the big 
companies using Linux to opposers of such a proposal.

> 			Linus

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 14:12 ` Timothy Miller
@ 2003-04-24 22:48   ` Werner Almesberger
  2003-04-25 12:29   ` Ragnar Hojland Espinosa
  1 sibling, 0 replies; 130+ messages in thread
From: Werner Almesberger @ 2003-04-24 22:48 UTC (permalink / raw)
  To: Timothy Miller; +Cc: Downing, Thomas, Kernel Mailing List

Timothy Miller wrote:
> One of the things that we could do to accelerate the adoption of Linux 
> is to support DRM.

As long as adoption of Linux is the only thing you care about in
the world, that logic certainly works.

> Yes, we know it's evil, but if we are the ones 
> developing it, at least we know what it is and is not doing and how it 
> works.  

You forgot

  "Yes, we know it's evil, but if we are the ones developing it, we
   can at least be sure that it will be done properly."

as in

  "Yes, officer, I know that I shouldn't drive after drinking that
   bottle of whisky, but I had to get home, and I'm a good driver
   who can handle this."

and

  "Yes, we know it's evil, but if we don't develop it, somebody else
   will."

as in

  "Yes, officer, I know that I shouldn't have parked here, but if
   I hadn't, somebody else would have."

(In the end, I don't think it helps to think of your actions in terms
of "good" or "evil". I find it much more important to consider the
possible consequences, direct and indirect.)

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 21:42   ` Daniel Phillips
@ 2003-04-24 22:45     ` Alan Cox
  2003-04-24 23:59       ` Daniel Phillips
  2003-04-25 13:01       ` David Luyer
  0 siblings, 2 replies; 130+ messages in thread
From: Alan Cox @ 2003-04-24 22:45 UTC (permalink / raw)
  To: Daniel Phillips; +Cc: Jamie Lokier, Downing, Thomas, Linux Kernel Mailing List

On Iau, 2003-04-24 at 22:42, Daniel Phillips wrote:
> A more mundane goal would be to prevent the 3D driver from letting you see 
> through polygons that are supposed to be opaque.

In the MUD world we solved that by not telling anyone about objects they
can't see. 


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 22:29         ` Werner Almesberger
  2003-04-24 22:41           ` Jamie Lokier
@ 2003-04-24 22:41           ` Alan Cox
  2003-04-27 14:21           ` Matthias Andree
  2 siblings, 0 replies; 130+ messages in thread
From: Alan Cox @ 2003-04-24 22:41 UTC (permalink / raw)
  To: Werner Almesberger
  Cc: Timothy Miller, Jamie Lokier, Andreas Jellinghaus,
	Linux Kernel Mailing List

On Iau, 2003-04-24 at 23:29, Werner Almesberger wrote:
> It's also worth to keep in mind that such decisions are frequently
> taken by people with very different agendas, e.g. if "protected by
> DRM" is perceived to appeal to analysts, shareholders or potential
> shareholders, it may quickly become policy in many companies, just
> like patents did.

Abusing DRM is a direct economic winner for anyone who does, thats 
precisely the problem. Its also an economic loss for everyone who
isn't able to abuse it. The latter tend to be have less influence
with the US government.

With DRM the music industry can prevent artists from doing independant
publishing by making the case that "unprotected music is pirate" and
"mandating only signed music can be played". Without it they are doomed
not because of piracy but because they are less efficient than the 
alternatives - to many bands less efficient right now than giving the
stuff away.



^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 22:29         ` Werner Almesberger
@ 2003-04-24 22:41           ` Jamie Lokier
  2003-04-24 22:54             ` Werner Almesberger
  2003-04-24 22:41           ` Alan Cox
  2003-04-27 14:21           ` Matthias Andree
  2 siblings, 1 reply; 130+ messages in thread
From: Jamie Lokier @ 2003-04-24 22:41 UTC (permalink / raw)
  To: Werner Almesberger
  Cc: Alan Cox, Timothy Miller, Andreas Jellinghaus, Linux Kernel Mailing List

Werner Almesberger wrote:
> Just like most vendors instinctively default to closed source.

Quite.  Businesses instinctively do what they believe is in their best
interests, and sometimes it is important to have constraints which
cause businesses to function in our mutual best interest, which
businesses are often not well placed to perceive.

> It's also worth to keep in mind that such decisions are frequently
> taken by people with very different agendas, e.g. if "protected by
> DRM" is perceived to appeal to analysts, shareholders or potential
> shareholders, it may quickly become policy in many companies, just
> like patents did.

In this regard, analysts, shareholders, consumers etc. are just like
business, acting in their own percieved best interest.

Change the rules against the status quo and they all complain, but it
is just change and they also all adapt to it.  That is business too.

-- Jamie

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 22:10 Downing, Thomas
@ 2003-04-24 22:36 ` Jamie Lokier
  0 siblings, 0 replies; 130+ messages in thread
From: Jamie Lokier @ 2003-04-24 22:36 UTC (permalink / raw)
  To: Downing, Thomas; +Cc: Daniel Phillips, Kernel Mailing List

Downing, Thomas wrote:
> How does the server _know_ that the BIOS is what it says it is? Again,
> what's the protocol?  Saying that they 'have a chat' is bypassing
> the hard bits.
> 
> If I have the BIOS, any secrets it holds are now knowable to me.
> This means that any protocol that relies on a secret in the BIOS is
> broken from the start.  So now you need to define a protocol which
> does not rely on any secret being known to the BIOS.  What is this
> protocol?

What makes you think you can read the BIOS?

> The proposed 'end-to-end' copy protection schemes for entertainment
> media etc, rely on proprietary _hardware_.

Yes, that's the severe version of DRM that we're talking about, for
the game server scenario.

> This is still beatable, although at a higher cost.  Nor is the
> problem quite parallel.  The broadcast problem is 'how do we keep
> content encrypted till the last possible moment?' and 'how do we
> keep the decryption engine tamper proof reverse engineering proof'.
> The first part is easy.  The second part is not possible in an
> absolute sense.  It can only be made more or less dificult.  Hence
> the DMCA etc.

We don't know for sure that it's not possible to make something
reverse engineering proof.  Although all current CPUs require code to
be decrypted at some point, there may be modules of computation that
don't require that, so there would be no way to extract the secret key
or decryption process in a useful way even when you can see every
electronic signal in a device.  The jury is out on it, despite what
slashdotters believe.

-- Jamie

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 18:35       ` Alan Cox
  2003-04-24 20:46         ` Timothy Miller
@ 2003-04-24 22:29         ` Werner Almesberger
  2003-04-24 22:41           ` Jamie Lokier
                             ` (2 more replies)
  1 sibling, 3 replies; 130+ messages in thread
From: Werner Almesberger @ 2003-04-24 22:29 UTC (permalink / raw)
  To: Alan Cox
  Cc: Timothy Miller, Jamie Lokier, Andreas Jellinghaus,
	Linux Kernel Mailing List

Alan Cox wrote:
> Either its allowed by the GPL or its not.

A more important barrier than what the GPL allows might be what the
Linux community accepts. If some DRM extensions are never accepted
by enough of the "mainstream", they will fail to work.

The main problem I see with accepting DRM functionality is that it
will encourage frivolous uses of DRM, just because it's possible
then. Just like most vendors instinctively default to closed
source.

It's also worth to keep in mind that such decisions are frequently
taken by people with very different agendas, e.g. if "protected by
DRM" is perceived to appeal to analysts, shareholders or potential
shareholders, it may quickly become policy in many companies, just
like patents did.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/

^ permalink raw reply	[flat|nested] 130+ messages in thread

* RE: Flame Linus to a crisp!
@ 2003-04-24 22:10 Downing, Thomas
  2003-04-24 22:36 ` Jamie Lokier
  0 siblings, 1 reply; 130+ messages in thread
From: Downing, Thomas @ 2003-04-24 22:10 UTC (permalink / raw)
  To: Jamie Lokier; +Cc: Daniel Phillips, Kernel Mailing List

> From: Daniel Phillips [mailto:phillips@arcor.de]
> > To join a game, you'd have to be able to prove you're running code
> > that is secure all the way from boot to reboot, where everything
> > from network driver to physics engine is known to be compiled from
> > open source that all participants agree is good.
> 
> How would you do that?  What's the protocol?

Public key exchange lets you communicate securely over an insecure link.

> So, the game server and the BIOS have a chat, through the operating
> system (which counts as an insecure link), and the BIOS tells the
> server that it is the correct DRM BIOS, and it loaded a signed kernel.

How does the server _know_ that the BIOS is what it says it is? Again,
what's the protocol?  Saying that they 'have a chat' is bypassing
the hard bits.

If I have the BIOS, any secrets it holds are now knowable to me.
This means that any protocol that relies on a secret in the BIOS is
broken from the start.  So now you need to define a protocol which
does not rely on any secret being known to the BIOS.  What is this
protocol?

> Substitute "broadcaster" for "game server" and you see that the same
? methods ensure that you really have the TV switched on and you are not
> recording the show.

The proposed 'end-to-end' copy protection schemes for entertainment
media etc, rely on proprietary _hardware_.  This is still beatable,
although at a higher cost.  Nor is the problem quite parallel.  The
broadcast problem is 'how do we keep content encrypted till the
last possible moment?' and 'how do we keep the decryption engine tamper
proof reverse engineering proof'.  The first part is easy.  The second
part is not possible in an absolute sense.  It can only be made more 
or less dificult.  Hence the DMCA etc.

> They also ensure you are not recording a screenshot of a politically
> sensitive article about Iraq that was accidentally shown on CNN's web
> site for 10 minutes.  We can't have people recording things like that.

God forbid! ;-)


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
@ 2003-04-24 21:55 Daniel Callahan
  0 siblings, 0 replies; 130+ messages in thread
From: Daniel Callahan @ 2003-04-24 21:55 UTC (permalink / raw)
  To: linux-kernel; +Cc: pochini

----
On 24-Apr-2003 Giuliano Pochini wrote:
Free software is free. You can do anything with it, the only contraint
is it must stay free. But cryptography plays a bad role here. Someone
can make hw that accepts only that peice of signed free software. You
have the hw, you have the binaries, you have the sources. But the
sources are completely useless. GPL allows the user to modify it, but
the hw doesn't run the modified copy. DRM can turns free software into
half-proprietary software. I don't like it at all, but I don't see any
solution.
----
The solution lies outside of the GPL.  Not that you're guilty of this, but 
somehow hackerdom has mixed the GPL in with 'the Right to free binaries' and 
'the Right to have compatible hardware'.  And those two Rights are as real as 
the brontosaurus, (i.e., they ain't, despite what many want to believe).  

Free binaries and compatible hardware are privileges.  In the case of 
hardware, that's a damn shame, but there it is.  Apart from mutilating the 
GPL to outlaw development on secured hardware, I can't see the solution 
coming from that direction.  (And even if GPL were modified to cover 
"activities other than copying, distribution and modification", all it would 
do is fork the license.  Linus would use the older license (I'm guessing), 
others would use the anti-DRM license, and Bill Gates would be ROTFLHAO.)

So there's no solution except to learn to live with it *unless* someone is 
brave and savvy enough to create a General Hardware License and found the 
Free Hardware Foundation.  And that still wouldn't make the DRM issue vanish 
-- GNU didn't wipe out proprietary software; it didn't even prevent the Mac 
from using FreeBSD.  It would just create the opportunity for a hardware 
hacker to do what has been done with Linux.

So, if anyone really is waiting for a sign to start the Free Hardware 
Foundation, consider Linus' email to be it.

Daniel.

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 21:28 ` Jamie Lokier
@ 2003-04-24 21:42   ` Daniel Phillips
  2003-04-24 22:45     ` Alan Cox
  2003-04-25  8:13   ` Andreas Jellinghaus
  1 sibling, 1 reply; 130+ messages in thread
From: Daniel Phillips @ 2003-04-24 21:42 UTC (permalink / raw)
  To: Jamie Lokier, Downing, Thomas; +Cc: Kernel Mailing List

On Thu 24 Apr 03 23:28, Jamie Lokier wrote:
> This is how a game server can verify it is working with a known game
> client and the client is connected to a known type of monitor and
> input device.  I.e. it can verify there is no electronic frame grabber
> using the video signals and driving an AI assist through the input
> device.

For the forseeable future, you might as well let people grab frames and try 
to analyze them: this is something people still do much better than machines.

A more mundane goal would be to prevent the 3D driver from letting you see 
through polygons that are supposed to be opaque.

> ...
> Substitute "broadcaster" for "game server" and you see that the same
> methods ensure that you really have the TV switched on and you are not
> recording the show.
>
> They also ensure you are not recording a screenshot of a politically
> sensitive article about Iraq that was accidentally shown on CNN's web
> site for 10 minutes.  We can't have people recording things like that.
>
> Also that day, that same article doesn't load from Al-Jazeera or
> anywhere else, on the PC you bought from the only affordable store in
> town.  Is the net flaky today, or is somebody remote-controlling your
> PC to control your "browsing experience"?

Did I mention I was grasping at straws?  I don't want this junk in my 
hardware any more than you do, I'd much rather have the transistors spent on 
more megahertz than on controlling me, thankyou.

Regards,

Daniel

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 21:30               ` Jamie Lokier
  2003-04-24 21:38                 ` John Bradford
@ 2003-04-24 21:42                 ` Russell King
  1 sibling, 0 replies; 130+ messages in thread
From: Russell King @ 2003-04-24 21:42 UTC (permalink / raw)
  To: Jamie Lokier
  Cc: Timothy Miller, Daniel Phillips, William Lee Irwin III,
	Linus Torvalds, Kernel Mailing List

On Thu, Apr 24, 2003 at 10:30:02PM +0100, Jamie Lokier wrote:
> Timothy Miller wrote:
> > We could always consider wiring everything up with discrete logic. 
> > Anyone got any spare 74138's?
> 
> I need 1 billion of them please, and I need the overclockable ones :)

Ah, you want the 74AC138 version then for fast propagation.

(3 to 8 line decoders/demultiplexers don't have a clock input, so
"overclockable ones" is rather meaningless.) 8)

Is it just me or are we wandering off topic here?

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 21:30               ` Jamie Lokier
@ 2003-04-24 21:38                 ` John Bradford
  2003-04-25  3:20                   ` Shawn
  2003-04-25 14:03                   ` Mike Dresser
  2003-04-24 21:42                 ` Russell King
  1 sibling, 2 replies; 130+ messages in thread
From: John Bradford @ 2003-04-24 21:38 UTC (permalink / raw)
  To: Jamie Lokier
  Cc: Timothy Miller, Daniel Phillips, William Lee Irwin III,
	Linus Torvalds, Kernel Mailing List

> > We could always consider wiring everything up with discrete logic. 
> > Anyone got any spare 74138's?
> 
> I need 1 billion of them please, and I need the overclockable ones :)

Why not just buy one of those 100-in-1 electronics kits from your
local electonics hobbyist store, and make your very own wire wrap CPU?

John.

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 21:08           ` Jamie Lokier
@ 2003-04-24 21:37             ` Timothy Miller
  2003-04-24 21:30               ` Jamie Lokier
  2003-04-25  6:08               ` Jan-Benedict Glaw
  0 siblings, 2 replies; 130+ messages in thread
From: Timothy Miller @ 2003-04-24 21:37 UTC (permalink / raw)
  To: Jamie Lokier
  Cc: Daniel Phillips, William Lee Irwin III, Linus Torvalds,
	Kernel Mailing List



Jamie Lokier wrote:

>  
>
>Suppose I did want to print some wafers.
>
>Suppose, also, that I had developed a method that didn't require a
>$10M+ factory.
>
>(Also suppose I had _very_ steady hands, no dandruff, and my garden
>shed was big enough :)
>
>I'm curious - how do I go about learning what I do and don't need
>patent licenses for making chips, without spending an absurd sum on
>legal fees?
>

We could always consider wiring everything up with discrete logic. 
 Anyone got any spare 74138's?




^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 21:37             ` Timothy Miller
@ 2003-04-24 21:30               ` Jamie Lokier
  2003-04-24 21:38                 ` John Bradford
  2003-04-24 21:42                 ` Russell King
  2003-04-25  6:08               ` Jan-Benedict Glaw
  1 sibling, 2 replies; 130+ messages in thread
From: Jamie Lokier @ 2003-04-24 21:30 UTC (permalink / raw)
  To: Timothy Miller
  Cc: Daniel Phillips, William Lee Irwin III, Linus Torvalds,
	Kernel Mailing List

Timothy Miller wrote:
> We could always consider wiring everything up with discrete logic. 
> Anyone got any spare 74138's?

I need 1 billion of them please, and I need the overclockable ones :)

-- Jamie

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 20:39 Downing, Thomas
@ 2003-04-24 21:28 ` Jamie Lokier
  2003-04-24 21:42   ` Daniel Phillips
  2003-04-25  8:13   ` Andreas Jellinghaus
  0 siblings, 2 replies; 130+ messages in thread
From: Jamie Lokier @ 2003-04-24 21:28 UTC (permalink / raw)
  To: Downing, Thomas; +Cc: Daniel Phillips, Kernel Mailing List

Downing, Thomas wrote:
> From: Daniel Phillips [mailto:phillips@arcor.de]
> > To join a game, you'd have to be able to prove you're running code
> > that is secure all the way from boot to reboot, where everything
> > from network driver to physics engine is known to be compiled from
> > open source that all participants agree is good.
> 
> How would you do that?  What's the protocol?

Public key exchange lets you communicate securely over an insecure link.

So, the game server and the BIOS have a chat, through the operating
system (which counts as an insecure link), and the BIOS tells the
server that it is the correct DRM BIOS, and it loaded a signed kernel.

So the server can trust the kernel.  It chats with the kernel, which
confirms that it is running a signed physics engine, a signed 3rd party
network driver, a signed video driver, the video is connected to a
signed monitor, the input is connected to a signed joystick, and that
conversations on TCP port XXX are connected to the physics engine.

This is how a game server can verify it is working with a known game
client and the client is connected to a known type of monitor and
input device.  I.e. it can verify there is no electronic frame grabber
using the video signals and driving an AI assist through the input
device.

Additionally, the trusted kernel and trusted video driver can prove
that they are encrypting the video link, so that it is imposible to
record the gameplay using standard video recording hardware.

   ---

Substitute "broadcaster" for "game server" and you see that the same
methods ensure that you really have the TV switched on and you are not
recording the show.

They also ensure you are not recording a screenshot of a politically
sensitive article about Iraq that was accidentally shown on CNN's web
site for 10 minutes.  We can't have people recording things like that.

Also that day, that same article doesn't load from Al-Jazeera or
anywhere else, on the PC you bought from the only affordable store in
town.  Is the net flaky today, or is somebody remote-controlling your
PC to control your "browsing experience"?

-- Jamie

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 18:58         ` Daniel Phillips
@ 2003-04-24 21:08           ` Jamie Lokier
  2003-04-24 21:37             ` Timothy Miller
  0 siblings, 1 reply; 130+ messages in thread
From: Jamie Lokier @ 2003-04-24 21:08 UTC (permalink / raw)
  To: Daniel Phillips
  Cc: William Lee Irwin III, Linus Torvalds, Kernel Mailing List

Daniel Phillips wrote:
> On Thu 24 Apr 03 09:44, Jamie Lokier wrote:
> > It only gets _really_ bad when it becomes illegal to make your own
> > hardware :(
> 
> Actually, that's where we were a few years ago with hardware, because nearly 
> anything anybody would want to print on a wafer was covered by patents or 
> copyrights.  It's getting better by leaps and bounds.  Now, a lot of patents 
> have expired, a lot of non-proprietary cores are available, and it's mainly 
> the EDM tools that are non-free.  That's where we coders can help.

Suppose I did want to print some wafers.

Suppose, also, that I had developed a method that didn't require a
$10M+ factory.

(Also suppose I had _very_ steady hands, no dandruff, and my garden
shed was big enough :)

I'm curious - how do I go about learning what I do and don't need
patent licenses for making chips, without spending an absurd sum on
legal fees?

-- Jamie

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 20:50           ` Jamie Lokier
@ 2003-04-24 21:03             ` Chris Adams
  0 siblings, 0 replies; 130+ messages in thread
From: Chris Adams @ 2003-04-24 21:03 UTC (permalink / raw)
  To: linux-kernel

Once upon a time, Jamie Lokier  <jamie@shareable.org> said:
>I wonder whether the FSF shouldn't fork the GPLv3 into two versions,
>according to what philosophy GPLv2 users would like to adopt for their
>own projects :)  (In principle, only the FSF is able to alter the
>license of a many-authored GPL'd project like Linux.  It would be
>unfortunate if they used that special status to promote an agenda
>which a large number existing GPL users disliked).

They can't affect the license of Linux because COPYING included with the
kernel says:

 Also note that the only valid version of the GPL as far as the kernel
 is concerned is _this_ particular version of the license (ie v2, not
 v2.2 or v3.x or whatever), unless explicitly otherwise stated.

Now, IIRC, that paragraph was added after the fact, so someone could go
back to a version before that paragraph and fork under a new version of
the GPL, however they could not take any code from the current versions
of the kernel.

About 20% of the files in the kernel include the "at your option" clause
(this is from looking at the source to RH's 2.4.20-8).

-- 
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 19:39                 ` Balram Adlakha
@ 2003-04-24 21:02                   ` Jamie Lokier
  0 siblings, 0 replies; 130+ messages in thread
From: Jamie Lokier @ 2003-04-24 21:02 UTC (permalink / raw)
  To: Balram Adlakha; +Cc: linux-kernel

Balram Adlakha wrote:
> By the way, I'm just curious, I don't have much knowledge of this,
> can anyone create a processor with the x86 instruction set and sell
> it? Like did AMD and transmeta and all get a license from Intel?

Please, somebody answer this question.  The good folks at Transmeta
should know the answer.

I'm really intersted as I want to do exactly this eventually.

Perhaps the constraints are different when software binary translation
is used?  I.e. I could sell a non-x86 cpu and give away an x86
translator without needing a license from Intel, presumably?

-- Jamie


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 20:46         ` Timothy Miller
@ 2003-04-24 20:50           ` Jamie Lokier
  2003-04-24 21:03             ` Chris Adams
  0 siblings, 1 reply; 130+ messages in thread
From: Jamie Lokier @ 2003-04-24 20:50 UTC (permalink / raw)
  To: Timothy Miller; +Cc: Alan Cox, Andreas Jellinghaus, Linux Kernel Mailing List

Timothy Miller wrote:
> Certainly.  But say the GPL allows it, and say Linus decides he wants 
> it.  There's nothing stopping someone else from forking it and deciding 
> they'll never accept any DRM-related code into their fork.

True but if the GPL allows, nobody could prevent their fork becoming
the heart of a DRM-locked product, either.

I wonder whether the FSF shouldn't fork the GPLv3 into two versions,
according to what philosophy GPLv2 users would like to adopt for their
own projects :)  (In principle, only the FSF is able to alter the
license of a many-authored GPL'd project like Linux.  It would be
unfortunate if they used that special status to promote an agenda
which a large number existing GPL users disliked).

-- Jamie


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 18:35       ` Alan Cox
@ 2003-04-24 20:46         ` Timothy Miller
  2003-04-24 20:50           ` Jamie Lokier
  2003-04-24 22:29         ` Werner Almesberger
  1 sibling, 1 reply; 130+ messages in thread
From: Timothy Miller @ 2003-04-24 20:46 UTC (permalink / raw)
  To: Alan Cox; +Cc: Jamie Lokier, Andreas Jellinghaus, Linux Kernel Mailing List



Alan Cox wrote:

>On Iau, 2003-04-24 at 16:37, Timothy Miller wrote:
>  
>
>>You are free to make a fork of the Linux tree for which DRM is NOT ok.
>>
>>Likewise, Linus is free to allow or disallow whatever he feels like in 
>>HIS tree.
>>    
>>
>
>Actually no.
>
>Either its allowed by the GPL or its not. There are good reasons to
>think that may ways of doing it are not (The GPL defines source
>as including installation instructions). However thats a debate for
>lawyers, and you can have the debate as long as you like but it doesn't
>change what the GPL says..
>
>  
>
>  
>
Certainly.  But say the GPL allows it, and say Linus decides he wants 
it.  There's nothing stopping someone else from forking it and deciding 
they'll never accept any DRM-related code into their fork.

Now, here's something for the lawyers to try to do:  determine that the 
GPL _requires_ DRM.  :)



^ permalink raw reply	[flat|nested] 130+ messages in thread

* RE: Flame Linus to a crisp!
@ 2003-04-24 20:39 Downing, Thomas
  2003-04-24 21:28 ` Jamie Lokier
  0 siblings, 1 reply; 130+ messages in thread
From: Downing, Thomas @ 2003-04-24 20:39 UTC (permalink / raw)
  To: Daniel Phillips, Kernel Mailing List


From: Daniel Phillips [mailto:phillips@arcor.de]

> To join a game, you'd have to be able to prove you're running code that is

> secure all the way from boot to reboot, where everything from network
driver 
> to physics engine is known to be compiled from open source that all 
> participants agree is good.

How would you do that?  What's the protocol?

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 19:22                 ` Linus Torvalds
  2003-04-24 20:19                   ` Jamie Lokier
@ 2003-04-24 20:35                   ` Timothy Miller
  1 sibling, 0 replies; 130+ messages in thread
From: Timothy Miller @ 2003-04-24 20:35 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Daniel Phillips, John Bradford, Jamie Lokier,
	William Lee Irwin III, Kernel Mailing List



Linus Torvalds wrote:

>On Thu, 24 Apr 2003, Timothy Miller wrote:
>  
>
>>For their smaller devices, Xilinx has a free "WebPack" which is a 
>>complete Verilog synthesizer (I don't know if it does VHDL), as well as 
>>place & route, of course.  I think it'll do up to Virtex II 250.  It 
>>also tends use fewer gates for a given design than the version of 
>>Leonardo Spectrum we have.  It just doesn't have a simulator, which is 
>>vital to any good development process.  Also, the Web Pack only runs 
>>under Windows.  Maybe it'll work with WINE?
>>    
>>
>
>It does work with wine - but it's sad how horrible the command line tools
>are (they were apparently first done under UNIX, and then ported to 
>Windows, and they got the Windows command line interface and trying to use 
>them in a sane way with Wine is not exactly much fun).
>
>But yes, with Wine and a few scripts you can actually make the tools 
>usable under Linux - I tried them out and had a small silly "pong" game 
>running on one of those things (a 100k device on one of the cheap 
>development boards).
>
>I have to admit that I would hate to actually use those tools for any real 
>work, though. 
>
>  
>
Where I work we have used the Web Pack (5.1, I believe) for "real work", 
although you can't trust its static timing.  Beyond a certain 
utilization, it completely lies to you, and we can't get it to work 
right, no matter how much we over-constrain a design.  All we can do is 
synthesize and then thoroughly test in real hardware (which isn't hard 
to do when all you're doing is a simple pixel-processing pipeline -- 
either it works, or you get obvious sprinkless all over the monitor 
screen).  If that doesn't work, we get really clever to reduce area, or 
we go to a bigger device.  What can you do with free but closed-source 
software?  :)  Designing for FPGA's is a real pain.  Although the ASIC I 
did was a lot more complex, the process was a lot more straight-forward 
and the tools didn't lie to you.



^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 19:22                 ` Linus Torvalds
@ 2003-04-24 20:19                   ` Jamie Lokier
  2003-04-24 20:35                   ` Timothy Miller
  1 sibling, 0 replies; 130+ messages in thread
From: Jamie Lokier @ 2003-04-24 20:19 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Timothy Miller, Daniel Phillips, John Bradford,
	William Lee Irwin III, Kernel Mailing List

Linus Torvalds wrote:
> > For their smaller devices, Xilinx has a free "WebPack" which is a 
> > complete Verilog synthesizer (I don't know if it does VHDL), as well as 
> > place & route, of course.  I think it'll do up to Virtex II 250.  It 
> > also tends use fewer gates for a given design than the version of 
> > Leonardo Spectrum we have.  It just doesn't have a simulator, which is 
> > vital to any good development process.  Also, the Web Pack only runs 
> > under Windows.  Maybe it'll work with WINE?
> 
> It does work with wine - but it's sad how horrible the command line tools
> are (they were apparently first done under UNIX, and then ported to 
> Windows, and they got the Windows command line interface and trying to use 
> them in a sane way with Wine is not exactly much fun).
> 
> But yes, with Wine and a few scripts you can actually make the tools 
> usable under Linux - I tried them out and had a small silly "pong" game 
> running on one of those things (a 100k device on one of the cheap 
> development boards).

The dongled tools don't work under Wine.  Thankfully they are rarer
nowadays.  Because of a dongle, I had to write a server which ran on
Windows and accepted FPGA compilation commands, so I could invoke a
client from a Makefile on a Linux box.

What is really shitty is that you can't make the FPGA compilers do
anything fundamentally new and better.  Such as taking full advantage
of the FPGA's architecture in ways that the manufacturer hasn't
considered.

You have the equivalent of a closed source compiler & linker.  But you
don't get access to the "assembler" level so if you want to design a
new language and compile that, you must target a language that the
FPGA synthesis tool accepts.  I.e. you don't get to tweak the
placement of wires & logic in enough interesting ways.  Unfortunately,
that makes a big different to performance on an FPGA, because the
"wires" are generally slower than the logic blocks.

(That said, it is no more secret than the Pentium's microcode or
Transmeta's VLIW code.  FPGA tweaking has much more potential, though, IMHO).

> I have to admit that I would hate to actually use those tools for any real 
> work, though. 

The last tool vendor I spoke too wanted US$100,000 for their tool.
I declined.

I've heard you get a more satisfying engineering experience from the
$100,000 tools.  From a vendor, though :)

-- Jamie


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  3:59 Linus Torvalds
                   ` (10 preceding siblings ...)
  2003-04-24 18:31 ` Daniel Phillips
@ 2003-04-24 20:16 ` Nils Holland
  11 siblings, 0 replies; 130+ messages in thread
From: Nils Holland @ 2003-04-24 20:16 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailing List

On Thursday 24 April 2003 05:59, Linus Torvalds wrote:

> In short, it's perfectly ok to sign a kernel image - I do it myself
> indirectly every day through the kernel.org, as kernel.org will sign the
> tar-balls I upload to make sure people can at least verify that they came
> that way. Doing the same thing on the binary is no different: signing a
> binary is a perfectly fine way to show the world that you're the one
> behind it, and that _you_ trust it.

Do I understand that? Well, what you are doing is signing the kernel tar-ball, 
so that when I download it from my favorite mirror, I can check if I really 
received the kernel yoz released yesterday, or if someone probably put some 
funny backdoors in there and now hopes me to become his prey. This has little 
to do with DRM, which stands for Digital Rights Management. Your signing 
doesn't have much to do with rights - I can still use a backdoored kernel if 
I want to. Signing source / binary files for such purposes is clearly ok.

DRM, however, obviously comes in when it comes to managing / securing rights. 
This would mean that under certain conditions, I might not be able to use 
something the way I would like to. As a short example, my digital satellite 
card may refuse to work with a stock kernel because someone thinks I might 
illegally decrypt pay-tv channels. So I might be forced to use a kernel 
signed by <some_vendor>, because that kernel is known to have hooks in it 
that make sure that I can't do such decrypting of pay-tv.

However, what would happen if I want to upgrade to the latest kernel Linus has 
just released? If I compile it myself, my tv card would not work with it. So 
I'd have to wait for whoever signed it to release their signed version. And 
they might even stop signing new kernels at some point in time, or probably 
ask me to pay money to get their specifically signed kernel. And in the end, 
all this nonsense could be there even though I never even intended to do what 
<whoever> wants to prevent me from doing.

To come back from this example to reality, signing things is not neccessarily 
bad. Technology that acts on such signatures is not inherently bad either - 
it's like the kitchen knife that you can use to cut food you want to eat, 
while it can also be used as a lethal weapon. So it always depends on how 
things get used, not on whether they exist or not. Surely, we could ban all 
knives, but the question is if the number of deaths we'd prevent by doing so 
would make up for the difficulites we'd get in the field of food preparation. 
For DRM, about the same question applies. And if the OSS community doesn't 
automatically heasitate to pick this technology up, it's possible that the 
positive effects can be made dominant - if we let all this stuff happen in 
the hands of "the others", it's likely that they would focus on using it only 
for "bad" things. It'd be like a kitchen knive put into the hands of a 
psychopath instead of the hands of a well-meaning housewife.

Bye,
Nils <nils@ravishing.de>

-- 
celine.ravishing.de
Linux 2.4.21-rc1 #5 Tue Apr 22 13:12:21 CEST 2003 i686
  9:59pm  up  4:21,  3 users,  load average: 0.13, 0.04, 0.01


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 13:08     ` Shawn
@ 2003-04-24 20:12       ` Kenneth Johansson
  0 siblings, 0 replies; 130+ messages in thread
From: Kenneth Johansson @ 2003-04-24 20:12 UTC (permalink / raw)
  To: Shawn; +Cc: Kernel Mailing List

On Thu, 2003-04-24 at 15:08, Shawn wrote:
> Ever notice Linus has a very distinct writing style? _under_scores_ 
> and: colons. (Underscored colons sound ouchy!)

_this_ is underline if you have a mail reader that understand that kind
of thing. *bold* and /italic/ there probably is more but I no longer
remember. Have not used a mailer that understand that type of encoding
since I used fidonet in the 80s.

Perhaps you should file a bug for evolution :)



^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 19:23       ` Jamie Lokier
@ 2003-04-24 19:50         ` Balram Adlakha
  0 siblings, 0 replies; 130+ messages in thread
From: Balram Adlakha @ 2003-04-24 19:50 UTC (permalink / raw)
  To: Jamie Lokier; +Cc: linux-kernel

On Friday 25 Apr 2003 12:53 am, Jamie Lokier wrote:
> > >>> I want to make it clear that DRM is perfectly ok with Linux!
> > >>
> > >>thanks for such a clear statement.
> > >
> > >Anybody would think Linux was written solely by Linus, the way His
> > >words are taken as summarising the intent of all its authors...
>
> Firstly, let's be clear I do actually agree with Linus.  The GPL is
> not strong enough to prevent DRM usage, in my opinion.
>
> (Aside: It's not a very convinced opinion, though, nor would I be
> unhappy if a future license were able to prevent free software being
> the basis for devices which it is _illegal_ to reprogram, except under
> very strict conditions.
>
> I consider software barriers fair game, whereas threat of
> imprisonment is a very serious matter.  Then again, think about
> tamper-proof cameras for evidence gathering against abuse by
> authorities - that's a great use of a tamper-proof device, if you can
> trust it).
>
> In response to the person who thanked Linus, fair enough.  It was a
> good thing to do.
>
> However, Linus' statements are sometimes interpreted as allowing or
> disallowing various things as he interprets the GPL - and it is dodgy
> ground for a business to build much on that, because Linus' opinion on
> the license is just that: his opinion.  If he were the sole author, or
> represented all the authors, his opinion would, I believe, hold more
> legal weight than it does.  But he isn't.
>
> I just wanted to point that out, in case the person who thanked him
> for the clear statement took the statement as meaning it was a good
> idea to build a business which depends on that.
>
> Timothy Miller wrote:
> > You are free to make a fork of the Linux tree for which DRM is NOT ok.
> >
> > Likewise, Linus is free to allow or disallow whatever he feels like in
> > HIS tree.
>
> Secondly, this is not logically valid.  It doesn't work like that.
>
> If Linus' interpretation of the GPL is a fair assessment, then I am
> _not_ free to fork the Linux tree and make DRM not ok for the fork.
>
> I'd be free to fork the tree and attach a differing _opinion_ to the
> license, but I cannot add further licensing clauses.  The GPL forbids
> this.
>
> For the same reason, Linus is _not_ free to allow or disallow whatever
> he feels like in his tree, either.
>
> In principle.  In pracice I suspect whatever Linus says goes simply
> because he's the de facto leader and nobody with any clout disagrees
> strongly enough to contest him.  If there were ever a big fork over
> some major ethical issue, that would change.
>
> Thirdly, keep in mind that all the above is just my opinion.  I could
> be mistaken, or irrelevant :)
>
> h.a.n.d.,
> -- Jamie

The thing is that Linus' tree is the "main" tree, and It should remain that 
way so that linux is "one". Linus' _HAS_ the right to do anything he wants 
with his tree, and all the distributors will take _his_ tree and the thing we 
all dread might happen ("you have to have version 12 of red hat linux 
_signed_ kernel to run this thing"). You _ARE_ allowed to have your _OWN_ 
tree without the stuff that you think is not right, but that won't help the 
situation (because that thing you want to run demands a signed kernel)
I think we have a problem here...

-- 
Key fingerprint = A0F8 9D33 45D0 9B0C 7135  4E88 5E08 2EFF A938 9713



^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 19:32               ` Timothy Miller
  2003-04-24 19:22                 ` Linus Torvalds
@ 2003-04-24 19:39                 ` Balram Adlakha
  2003-04-24 21:02                   ` Jamie Lokier
  1 sibling, 1 reply; 130+ messages in thread
From: Balram Adlakha @ 2003-04-24 19:39 UTC (permalink / raw)
  To: linux-kernel

On Friday 25 Apr 2003 1:02 am, Timothy Miller wrote:
> Daniel Phillips wrote:
> >On Thu 24 Apr 03 16:45, Linus Torvalds wrote:
> >>If open hardware is what you want, FPGA's are actually getting to the
> >>point where you can do real CPU's with them. They won't be gigahertz, and
> >>they won't have big nice caches (but hey, you might make something that
> >>clocks fairly close to memory speeds, so you might not care about the
> >>latter once you have the former).
> >>
> >>They're even getting reasonably cheap.
> >
> >The big problem with FPGAs at the moment is that the vendors want you to
> > use their tools, which come with license agreements that limit your
> > options in arbitrary ways, otherwise this would be peachy.
>
> For their smaller devices, Xilinx has a free "WebPack" which is a
> complete Verilog synthesizer (I don't know if it does VHDL), as well as
> place & route, of course.  I think it'll do up to Virtex II 250.  It
> also tends use fewer gates for a given design than the version of
> Leonardo Spectrum we have.  It just doesn't have a simulator, which is
> vital to any good development process.  Also, the Web Pack only runs
> under Windows.  Maybe it'll work with WINE?
>
> I've been working on my own 32-bit CPU design for FPGA lately.  Maybe we
> can get Linux to run on it.  :)

By the way, I'm just curious, I don't have much knowledge of this, can anyone 
create a processor with the x86 instruction set and sell it? Like did AMD and 
transmeta and all get a license from Intel?



^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 17:41       ` William Lee Irwin III
@ 2003-04-24 19:39         ` Balram Adlakha
  0 siblings, 0 replies; 130+ messages in thread
From: Balram Adlakha @ 2003-04-24 19:39 UTC (permalink / raw)
  To: linux-kernel

On Thursday 24 Apr 2003 11:11 pm, William Lee Irwin III wrote:
> On Thu, Apr 24, 2003 at 01:32:55PM -0400, Andreas Boman wrote:
> > Ofcourse thoose things would most likely happen weather linux embraced
> > DRM or not, exept that if linux did not allow signing we would all be
> > forced to use another operating system, exept on that one still working
> > old slow quad xeon box that really doesnt do much, it cant even connect
> > to the internet since its packets arent signed, but its a fun toy to
> > play with and think about the good 'ol days when we could boot linux.
>
> That's pretty much my fear (in which worst-case scenario I just quit).

Me too, I hope this thing doesn't happen or I would be left with my 686 
running NetBSD :(



^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 19:03             ` Daniel Phillips
@ 2003-04-24 19:32               ` Timothy Miller
  2003-04-24 19:22                 ` Linus Torvalds
  2003-04-24 19:39                 ` Balram Adlakha
  0 siblings, 2 replies; 130+ messages in thread
From: Timothy Miller @ 2003-04-24 19:32 UTC (permalink / raw)
  To: Daniel Phillips
  Cc: Linus Torvalds, John Bradford, Jamie Lokier,
	William Lee Irwin III, Kernel Mailing List



Daniel Phillips wrote:

>On Thu 24 Apr 03 16:45, Linus Torvalds wrote:
>  
>
>>If open hardware is what you want, FPGA's are actually getting to the
>>point where you can do real CPU's with them. They won't be gigahertz, and
>>they won't have big nice caches (but hey, you might make something that
>>clocks fairly close to memory speeds, so you might not care about the
>>latter once you have the former).
>>
>>They're even getting reasonably cheap.
>>    
>>
>
>The big problem with FPGAs at the moment is that the vendors want you to use 
>their tools, which come with license agreements that limit your options in 
>arbitrary ways, otherwise this would be peachy.
>
>
>  
>
For their smaller devices, Xilinx has a free "WebPack" which is a 
complete Verilog synthesizer (I don't know if it does VHDL), as well as 
place & route, of course.  I think it'll do up to Virtex II 250.  It 
also tends use fewer gates for a given design than the version of 
Leonardo Spectrum we have.  It just doesn't have a simulator, which is 
vital to any good development process.  Also, the Web Pack only runs 
under Windows.  Maybe it'll work with WINE?

I've been working on my own 32-bit CPU design for FPGA lately.  Maybe we 
can get Linux to run on it.  :)



^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 15:37     ` Timothy Miller
  2003-04-24 18:35       ` Alan Cox
@ 2003-04-24 19:23       ` Jamie Lokier
  2003-04-24 19:50         ` Balram Adlakha
  1 sibling, 1 reply; 130+ messages in thread
From: Jamie Lokier @ 2003-04-24 19:23 UTC (permalink / raw)
  To: Timothy Miller; +Cc: Andreas Jellinghaus, linux-kernel

> >>> I want to make it clear that DRM is perfectly ok with Linux!
> >>thanks for such a clear statement.
> >Anybody would think Linux was written solely by Linus, the way His
> >words are taken as summarising the intent of all its authors...

Firstly, let's be clear I do actually agree with Linus.  The GPL is
not strong enough to prevent DRM usage, in my opinion.

(Aside: It's not a very convinced opinion, though, nor would I be
unhappy if a future license were able to prevent free software being
the basis for devices which it is _illegal_ to reprogram, except under
very strict conditions.

I consider software barriers fair game, whereas threat of
imprisonment is a very serious matter.  Then again, think about
tamper-proof cameras for evidence gathering against abuse by
authorities - that's a great use of a tamper-proof device, if you can
trust it).

In response to the person who thanked Linus, fair enough.  It was a
good thing to do.

However, Linus' statements are sometimes interpreted as allowing or
disallowing various things as he interprets the GPL - and it is dodgy
ground for a business to build much on that, because Linus' opinion on
the license is just that: his opinion.  If he were the sole author, or
represented all the authors, his opinion would, I believe, hold more
legal weight than it does.  But he isn't.

I just wanted to point that out, in case the person who thanked him
for the clear statement took the statement as meaning it was a good
idea to build a business which depends on that.

Timothy Miller wrote:
> You are free to make a fork of the Linux tree for which DRM is NOT ok.
> 
> Likewise, Linus is free to allow or disallow whatever he feels like in 
> HIS tree.

Secondly, this is not logically valid.  It doesn't work like that.

If Linus' interpretation of the GPL is a fair assessment, then I am
_not_ free to fork the Linux tree and make DRM not ok for the fork.

I'd be free to fork the tree and attach a differing _opinion_ to the
license, but I cannot add further licensing clauses.  The GPL forbids
this.

For the same reason, Linus is _not_ free to allow or disallow whatever
he feels like in his tree, either.

In principle.  In pracice I suspect whatever Linus says goes simply
because he's the de facto leader and nobody with any clout disagrees
strongly enough to contest him.  If there were ever a big fork over
some major ethical issue, that would change.

Thirdly, keep in mind that all the above is just my opinion.  I could
be mistaken, or irrelevant :)

h.a.n.d.,
-- Jamie


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 19:32               ` Timothy Miller
@ 2003-04-24 19:22                 ` Linus Torvalds
  2003-04-24 20:19                   ` Jamie Lokier
  2003-04-24 20:35                   ` Timothy Miller
  2003-04-24 19:39                 ` Balram Adlakha
  1 sibling, 2 replies; 130+ messages in thread
From: Linus Torvalds @ 2003-04-24 19:22 UTC (permalink / raw)
  To: Timothy Miller
  Cc: Daniel Phillips, John Bradford, Jamie Lokier,
	William Lee Irwin III, Kernel Mailing List


On Thu, 24 Apr 2003, Timothy Miller wrote:
>
> For their smaller devices, Xilinx has a free "WebPack" which is a 
> complete Verilog synthesizer (I don't know if it does VHDL), as well as 
> place & route, of course.  I think it'll do up to Virtex II 250.  It 
> also tends use fewer gates for a given design than the version of 
> Leonardo Spectrum we have.  It just doesn't have a simulator, which is 
> vital to any good development process.  Also, the Web Pack only runs 
> under Windows.  Maybe it'll work with WINE?

It does work with wine - but it's sad how horrible the command line tools
are (they were apparently first done under UNIX, and then ported to 
Windows, and they got the Windows command line interface and trying to use 
them in a sane way with Wine is not exactly much fun).

But yes, with Wine and a few scripts you can actually make the tools 
usable under Linux - I tried them out and had a small silly "pong" game 
running on one of those things (a 100k device on one of the cheap 
development boards).

I have to admit that I would hate to actually use those tools for any real 
work, though. 

			Linus


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 14:45           ` Linus Torvalds
  2003-04-24 15:00             ` Jeff Garzik
@ 2003-04-24 19:03             ` Daniel Phillips
  2003-04-24 19:32               ` Timothy Miller
  1 sibling, 1 reply; 130+ messages in thread
From: Daniel Phillips @ 2003-04-24 19:03 UTC (permalink / raw)
  To: Linus Torvalds, John Bradford
  Cc: Jamie Lokier, William Lee Irwin III, Kernel Mailing List

On Thu 24 Apr 03 16:45, Linus Torvalds wrote:
> If open hardware is what you want, FPGA's are actually getting to the
> point where you can do real CPU's with them. They won't be gigahertz, and
> they won't have big nice caches (but hey, you might make something that
> clocks fairly close to memory speeds, so you might not care about the
> latter once you have the former).
>
> They're even getting reasonably cheap.

The big problem with FPGAs at the moment is that the vendors want you to use 
their tools, which come with license agreements that limit your options in 
arbitrary ways, otherwise this would be peachy.

Regards,

Daniel

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  7:44       ` Jamie Lokier
  2003-04-24  8:03         ` Jan-Benedict Glaw
  2003-04-24  8:16         ` John Bradford
@ 2003-04-24 18:58         ` Daniel Phillips
  2003-04-24 21:08           ` Jamie Lokier
  2 siblings, 1 reply; 130+ messages in thread
From: Daniel Phillips @ 2003-04-24 18:58 UTC (permalink / raw)
  To: Jamie Lokier, William Lee Irwin III, Linus Torvalds, Kernel Mailing List

On Thu 24 Apr 03 09:44, Jamie Lokier wrote:
> It only gets _really_ bad when it becomes illegal to make your own
> hardware :(

Actually, that's where we were a few years ago with hardware, because nearly 
anything anybody would want to print on a wafer was covered by patents or 
copyrights.  It's getting better by leaps and bounds.  Now, a lot of patents 
have expired, a lot of non-proprietary cores are available, and it's mainly 
the EDM tools that are non-free.  That's where we coders can help.

Until the EDM tools get free, their current owners will continue to dictate 
what you can and can't design.

Regards,

Daniel

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 15:37     ` Timothy Miller
@ 2003-04-24 18:35       ` Alan Cox
  2003-04-24 20:46         ` Timothy Miller
  2003-04-24 22:29         ` Werner Almesberger
  2003-04-24 19:23       ` Jamie Lokier
  1 sibling, 2 replies; 130+ messages in thread
From: Alan Cox @ 2003-04-24 18:35 UTC (permalink / raw)
  To: Timothy Miller
  Cc: Jamie Lokier, Andreas Jellinghaus, Linux Kernel Mailing List

On Iau, 2003-04-24 at 16:37, Timothy Miller wrote:
> You are free to make a fork of the Linux tree for which DRM is NOT ok.
> 
> Likewise, Linus is free to allow or disallow whatever he feels like in 
> HIS tree.

Actually no.

Either its allowed by the GPL or its not. There are good reasons to
think that may ways of doing it are not (The GPL defines source
as including installation instructions). However thats a debate for
lawyers, and you can have the debate as long as you like but it doesn't
change what the GPL says..

Alan


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  3:59 Linus Torvalds
                   ` (9 preceding siblings ...)
  2003-04-24 15:53 ` Elladan
@ 2003-04-24 18:31 ` Daniel Phillips
  2003-04-24 23:15   ` Werner Almesberger
  2003-04-26 18:21   ` Rik van Riel
  2003-04-24 20:16 ` Nils Holland
  11 siblings, 2 replies; 130+ messages in thread
From: Daniel Phillips @ 2003-04-24 18:31 UTC (permalink / raw)
  To: Linus Torvalds, Kernel Mailing List

On Thu 24 Apr 03 05:59, Linus Torvalds wrote:
> ...I wanted to bring this out in the open,
> because I know there are people who think that signed binaries are an act
> of "subversion" (or "perversion") of the GPL, and I wanted to make sure
> that people don't live under mis-apprehension that it can't be done.

Open source + Linux + DRM could be used to solve the Quake client-side 
cheating problem:

   http://catb.org/~esr/writings/quake-cheats.html

To join a game, you'd have to be able to prove you're running code that is 
secure all the way from boot to reboot, where everything from network driver 
to physics engine is known to be compiled from open source that all 
participants agree is good.  You could call this a "white hat" use of DRM.  
It's strictly voluntary and nothing mysterious takes over your computer - no 
spyware, no trojans.  Just Linux, drivers, and the game.

Granted, this is a pretty theoretical application.  Just because of the sheer 
amount of work needed to put all the pieces in in place, DRM will actually be 
used a lot more for what is really easy: trampling on fair use rights.  But 
it's not like fair use isn't already being trampled upon, without the aid of 
DRM.

The point of this is that, to be maximally effective, DRM wants to be coupled 
with open source: with just DRM and no open source, there's no way to achieve 
the same level of trust.  So there is a silver lining, even in this rotten, 
stinking cloud.

Regards,

Daniel

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 11:38     ` Shachar Shemesh
@ 2003-04-24 17:46       ` Shachar Shemesh
  0 siblings, 0 replies; 130+ messages in thread
From: Shachar Shemesh @ 2003-04-24 17:46 UTC (permalink / raw)
  To: Kernel Mailing List; +Cc: Russell King, Arjan van de Ven, Linus Torvalds

Shachar Shemesh wrote:

> Wouldn't "control ... installation" include the keys too?
>
> IANAL, but I am on the board of an NPO that advocates Free and Open 
> Source Software, and that NPO has a lawyer (who is VERY familiar with 
> the GPL). Would it make sense to ask him? After all, that merely means 
> what one lawyer would say.
>
Ok, so I did. The gist of it - a very quick analysis said "no, it does 
not cover the keys". You can now return to your usual debate.

More in details, the keys seem like a late addition to the already 
compiled kernel, have a standalone existance, and are not even code, and 
can therefor not be considered "deriviative work".

-- 
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/



^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 17:32     ` Andreas Boman
@ 2003-04-24 17:41       ` William Lee Irwin III
  2003-04-24 19:39         ` Balram Adlakha
  2003-04-26 17:05       ` Riley Williams
  1 sibling, 1 reply; 130+ messages in thread
From: William Lee Irwin III @ 2003-04-24 17:41 UTC (permalink / raw)
  To: Andreas Boman; +Cc: Linus Torvalds, Andre Hedrick, Kernel Mailing List

On Thu, Apr 24, 2003 at 01:32:55PM -0400, Andreas Boman wrote:
> Ofcourse thoose things would most likely happen weather linux embraced
> DRM or not, exept that if linux did not allow signing we would all be
> forced to use another operating system, exept on that one still working
> old slow quad xeon box that really doesnt do much, it cant even connect
> to the internet since its packets arent signed, but its a fun toy to
> play with and think about the good 'ol days when we could boot linux.

That's pretty much my fear (in which worst-case scenario I just quit).


-- wli

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  5:16   ` Linus Torvalds
  2003-04-24 13:08     ` Shawn
@ 2003-04-24 17:32     ` Andreas Boman
  2003-04-24 17:41       ` William Lee Irwin III
  2003-04-26 17:05       ` Riley Williams
  1 sibling, 2 replies; 130+ messages in thread
From: Andreas Boman @ 2003-04-24 17:32 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Andre Hedrick, Kernel Mailing List

On Thu, 2003-04-24 at 01:16, Linus Torvalds wrote:
> On Wed, 23 Apr 2003, Andre Hedrick wrote:
> > 
> > Now the digital signing issue as a means to protect possible embedded or
> > distribution environments is needed.  DRM cuts two ways and do not forget
> > it!
> 
> This is _the_ most important part to remember.
> 
> Security is a two-edged sword. It can be used _for_ you, and it can be
> used _against_ you. A fence keeps the bad guys out, but by implication the
> bad guys can use it to keep _you_ out, too.
> 
> The technology itself is pretty neutral, and I'm personally pretty
> optimistic that _especially_ in an open-source environment we will find
> that most of the actual effort is going to be going into making security
> be a _pro_consumer_ thing. Security for the user, not to screw the user.
> 
Ofcourse the efforts by the OSS community will focus on security for the
user, and better security is something we all want. No arguments there.

> Put another way: I'd rather embrace it for the positive things it can do
> for us, than have _others_ embrace it for the things it can do for them.

I agree that the licence does/should not disallow signing. However I
don't see how that is tied to "the current DRM initiative" though
(perhaps im just clueless, I have no doubt that you know more of the
details of DRM than I do). We can do this today. There are patches out
there that let the kernel refuse to run unsigned userspace code.
Hardware dongles have been in existence for eons. 

It seems to me that embracing DRM will in the near future allow linux
distro vendors to ship signed binaries, to allow their users to use any
online services that will require a DRM operating system. Perhaps that
is the positive things you refer to.

Further in the future it will allow linux to exist as a current OS,
after we get DRM enabled hardware that refuse to boot unsigned kernels.
Larger linux vendors can afford to have their kernels (and userspace)
signed by $signing_entity. Perhaps they will be able to purchase some
'licence to sign' on their own from hardware vendors, and not have to
wait a few months to get that latest kernel with the 2 liner buffer
overflow patch released. 

> > For those not aware, each and every kernel you download from K.O is DRM
> > signed as a means to authenticate purity.
> 
> Yup. And pretty much every official .rpm or .deb package (source and
> binary) is already signed by the company that made that package, for
> _your_ protection. This is already "accepted practice", so allowing 
> signing is not something new per se, including on a binary level.

Sure, but today a signed kernel from $vendor doesnt prevent me from
running a program I compiled myself, the signature only shows me that
the kernel infact came from $vendor and if I trust that vendor, I can
now trust that kernel. 

> So what I hope this discussion brings as news is to make people aware of
> it. And that very much includes making people aware of the fact that there
> are some scary sides to signing stuff 

I don't feel signing stuff has any scary sides. The scary part is that 
*my* signature will be worthless, and I'm scared that in 10 years I wont
be able to boot my own kernels, or run my own userspace code. 

In the near future I'm worried about the fact that I could become second
class netizen if I dont run a signed $large_linux_vendor kernel and
userspace chain all the way up to a signed mozilla. I quite like paying
my bills on-line.

Ofcourse thoose things would most likely happen weather linux embraced
DRM or not, exept that if linux did not allow signing we would all be
forced to use another operating system, exept on that one still working
old slow quad xeon box that really doesnt do much, it cant even connect
to the internet since its packets arent signed, but its a fun toy to
play with and think about the good 'ol days when we could boot linux.

> - and that they're par for the
> course, and part of the package. I know for a fact that a number of 
> people were hoping for the upsides without any of the downsides. That's 
> not how it works.

I believe the proverb goes: "Du kan inte äta kakan och ha den kvar."
(You can't eat the cookie and still have it left). 

	Andreas



^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  3:59 Linus Torvalds
                   ` (8 preceding siblings ...)
  2003-04-24 12:39 ` Mark Mielke
@ 2003-04-24 15:53 ` Elladan
  2003-04-24 18:31 ` Daniel Phillips
  2003-04-24 20:16 ` Nils Holland
  11 siblings, 0 replies; 130+ messages in thread
From: Elladan @ 2003-04-24 15:53 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailing List

So, there are two basic camps in the whole DRM arena:

1. People who want to somehow make files that only computers they trust
   can play.

2. People who want to make computers that can refuse to run programs
   that aren't approved (eg. by the administrator).

The DRM scheme you've mentioned (embedding public keys in the kernel,
plus hardware support etc.) seem compatible with the second group.
However, it fundamentally has some problems with the first group.

The way people doing the first group operate is to try to hide secret
keys in their software using some trivial obfuscation method.  Their
software then tries to authenticate that the rest of the system is
somehow friendly, and the user has permission to play the file.  If the
software decides everything is good, it then assents to decrypt the file
using the secret keys it has hidden inside it.

This is, of course, technically a joke since breaking the DRM is always
simply a matter of disassembling their code to find where they hid the
key.  It's not like a system where everyone in the world has a copy of
the secret key on their desk can actually be secure.  But anyway...

In practice, what these sorts of DRM people are going to want to do with
a Linux kernel is build some sort of secret, obfuscated binary-only
kernel module which somehow tries to make sure the system is happy and
friendly, and then signal to the application that all is well.


So, here's a question for you:

This clearly looks like it would be legal for the end-user to do, since
the end user can use GPL code for any purpose.

What about a device manufacturer, though?  To keep the key secret, any
DRM scheme of this sort of pretty-much guaranteed to involve some sort
of binary-only kernel module, possibly shipped in ROM next to the
kernel.  Can a company actually ship a device of this sort which uses
such a binary-only module, and be compatible with the GPL?

It seems it could be argued both ways - since the binary module is
clearly meant to be linked into the kernel, it could be considered a
derivative work if they're packaged together.  This isn't quite the same
as an end-user deciding to load some module that happens to be sitting
around.

Alternatively, since the kernel includes a facility to load arbitrary
code into its core image at run-time, it could be argued that the binary
module is still not a derivative work, just some unrelated code which a
proprietary application chooses to insert into the kernel while it's
running, using standard kernel system calls. 

Which interpretation is correct?  I'd suspect the latter, otherwise
linux distributions may already be in trouble...

-J


On Wed, Apr 23, 2003 at 08:59:45PM -0700, Linus Torvalds wrote:
> 
> Ok, 
>  there's no way to do this gracefully, so I won't even try. I'm going to 
> just hunker down for some really impressive extended flaming, and my 
> asbestos underwear is firmly in place, and extremely uncomfortable.
> 
>   I want to make it clear that DRM is perfectly ok with Linux!
> 
> There, I've said it. I'm out of the closet. So bring it on...
> 
> I've had some private discussions with various people about this already,
> and I do realize that a lot of people want to use the kernel in some way
> to just make DRM go away, at least as far as Linux is concerned. Either by
> some policy decision or by extending the GPL to just not allow it.
> 
> In some ways the discussion was very similar to some of the software
> patent related GPL-NG discussions from a year or so ago: "we don't like
> it, and we should change the license to make it not work somehow". 
> 
> And like the software patent issue, I also don't necessarily like DRM
> myself, but I still ended up feeling the same: I'm an "Oppenheimer", and I
> refuse to play politics with Linux, and I think you can use Linux for
> whatever you want to - which very much includes things I don't necessarily
> personally approve of.
> 
> The GPL requires you to give out sources to the kernel, but it doesn't
> limit what you can _do_ with the kernel. On the whole, this is just
> another example of why rms calls me "just an engineer" and thinks I have
> no ideals.
> 
> [ Personally, I see it as a virtue - trying to make the world a slightly
>   better place _without_ trying to impose your moral values on other 
>   people. You do whatever the h*ll rings your bell, I'm just an engineer 
>   who wants to make the best OS possible. ]
> 
> In short, it's perfectly ok to sign a kernel image - I do it myself
> indirectly every day through the kernel.org, as kernel.org will sign the
> tar-balls I upload to make sure people can at least verify that they came
> that way. Doing the same thing on the binary is no different: signing a
> binary is a perfectly fine way to show the world that you're the one
> behind it, and that _you_ trust it.
> 
> And since I can imaging signing binaries myself, I don't feel that I can
> disallow anybody else doing so.
> 
> Another part of the DRM discussion is the fact that signing is only the 
> first step: _acting_ on the fact whether a binary is signed or not (by 
> refusing to load it, for example, or by refusing to give it a secret key) 
> is required too.
> 
> But since the signature is pointless unless you _use_ it for something,
> and since the decision how to use the signature is clearly outside of the
> scope of the kernel itself (and thus not a "derived work" or anything like
> that), I have to convince myself that not only is it clearly ok to act on
> the knowledge of whather the kernel is signed or not, it's also outside of
> the scope of what the GPL talks about, and thus irrelevant to the license.
> 
> That's the short and sweet of it. I wanted to bring this out in the open, 
> because I know there are people who think that signed binaries are an act 
> of "subversion" (or "perversion") of the GPL, and I wanted to make sure 
> that people don't live under mis-apprehension that it can't be done.
> 
> I think there are many quite valid reasons to sign (and verify) your
> kernel images, and while some of the uses of signing are odious, I don't
> see any sane way to distinguish between "good" signers and "bad" signers.
> 
> Comments? I'd love to get some real discussion about this, but in the end 
> I'm personally convinced that we have to allow it.
> 
> Btw, one thing that is clearly _not_ allowed by the GPL is hiding private
> keys in the binary. You can sign the binary that is a result of the build
> process, but you can _not_ make a binary that is aware of certain keys
> without making those keys public - because those keys will obviously have
> been part of the kernel build itself.
> 
> So don't get these two things confused - one is an external key that is
> applied _to_ the kernel (ok, and outside the license), and the other one
> is embedding a key _into_ the kernel (still ok, but the GPL requires that
> such a key has to be made available as "source" to the kernel).
> 
> 			Linus
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  8:59   ` Jamie Lokier
  2003-04-24 12:52     ` Andreas Jellinghaus
@ 2003-04-24 15:37     ` Timothy Miller
  2003-04-24 18:35       ` Alan Cox
  2003-04-24 19:23       ` Jamie Lokier
  1 sibling, 2 replies; 130+ messages in thread
From: Timothy Miller @ 2003-04-24 15:37 UTC (permalink / raw)
  To: Jamie Lokier; +Cc: Andreas Jellinghaus, linux-kernel



Jamie Lokier wrote:

>Andreas Jellinghaus wrote:
>  
>
>>In ka.lists.linux.kernel, you wrote:
>>    
>>
>>>  I want to make it clear that DRM is perfectly ok with Linux!
>>>      
>>>
>>thanks for such a clear statement.
>>    
>>
>
>Anybody would think Linux was written solely by Linus, the way His
>words are taken as summarising the intent of all its authors...
>
>
>  
>
You are free to make a fork of the Linux tree for which DRM is NOT ok.

Likewise, Linus is free to allow or disallow whatever he feels like in 
HIS tree.



^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 14:45           ` Linus Torvalds
@ 2003-04-24 15:00             ` Jeff Garzik
  2003-04-24 19:03             ` Daniel Phillips
  1 sibling, 0 replies; 130+ messages in thread
From: Jeff Garzik @ 2003-04-24 15:00 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: John Bradford, Jamie Lokier, William Lee Irwin III, Kernel Mailing List

On Thu, Apr 24, 2003 at 07:45:16AM -0700, Linus Torvalds wrote:
> On Thu, 24 Apr 2003, John Bradford wrote:
> > Incidently, using the Transmeta CPUs, is it not possible for the user
> > to replace the controlling software with their own code?  I.E. not
> > bother with X86 compatibility at all, but effectively design your own
> > CPU?  Couldn't we make the first Lin-PU this way?

> If open hardware is what you want, FPGA's are actually getting to the
> point where you can do real CPU's with them. They won't be gigahertz, and

Yep.  Check out http://www.opencores.org/   At least one CPU there
already can boot Linux.

I'm waiting for the day, in fact, when somebody will use the OpenCores
tech to build an entirely open system...  They seem to have most of the
pieces done already, though I dunno how applicable Wishbone technology
is to PC-like systems.

	Jeff




^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  8:57 ` Arjan van de Ven
  2003-04-24  9:19   ` Russell King
@ 2003-04-24 14:59   ` Linus Torvalds
  1 sibling, 0 replies; 130+ messages in thread
From: Linus Torvalds @ 2003-04-24 14:59 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: Kernel Mailing List


On 24 Apr 2003, Arjan van de Ven wrote:
> 
> The "hot" issue is partially this part of the GPL:
> 
> For an executable work, complete source code means all the source code
> for all modules it contains, plus any associated interface definition
> files, plus the scripts used to control compilation and installation of
> the executable.
> 
> where it seems to say that if you need a script to be able to usefully
> install a self compiled kernel, that script is part of "the sourcecode".

Yes, that's the part that can be read pretty much any way depending on 
your mood swings. 

In particular, just how far does "installation" go? Clearly it doesn't 
require that you give people ROM masks and soldering irons. Well, clearly 
to _me_ anyway.

So you while you _logically_ may be able to take it to the absurd end
("you need to build me a fab, and make it under the GPL, so that I can
'install' the kernel on the chips"), I'm personally very much against that 
kind of absurdity.

For example, I don't use the Makefile targets to physically install my 
kernels - I end up doing that by hand, with a few "cp -f ..." things. Does 
that mean that I'm in violation of the GPL when I give the end result out 
to somebody? I'd say "clearly not". 

Don't get me wrong - I don't particularly like magic hardware that only 
boots signed kernels for some nefarious reasons. But I bet that pretty 
much _every_ embedded Linux project will have special tools to do the 
"final install", and I can't for the life of me take the logic that far. 

That's _doubly_ true as many of the installs are quite benign, and I see a
lot of good reasons to sign kernel binaries with your own private key to
verify that nobody else has exchanged it with a kernel that is full of
trojans. One environment where you might want to do something like that is
open access machines at a university, for example. You bolt the machines 
down, and you make sure that they don't have any trojans - and _clearly_ 
that has to be allowed by the license.

But such a "make the machines be something the _users_ can trust" is 100%
indistinguishable from a technical standpoint from something where you
"make the machine something that Disney Corp can trust". There is _zero_
technical difference. It's only a matter of intent - and even the intent
will be a matter of interpretation.

This is why I refuse to disallow even the "bad" kinds of uses - because 
not allowing them would automatically also mean that "good" uses aren't 
allowed.

Another way of saying it: I refuse to have some license amendment that
starts talking about "intent" and "user vs corporations" crap and "moral 
rights" etc. I think the GPL is too politicised already, I'd rather have 
it _less_ "crazy talk" than more.

				Linus


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  8:16         ` John Bradford
  2003-04-24  8:31           ` Jamie Lokier
  2003-04-24  8:50           ` Jamie Lokier
@ 2003-04-24 14:45           ` Linus Torvalds
  2003-04-24 15:00             ` Jeff Garzik
  2003-04-24 19:03             ` Daniel Phillips
  2 siblings, 2 replies; 130+ messages in thread
From: Linus Torvalds @ 2003-04-24 14:45 UTC (permalink / raw)
  To: John Bradford; +Cc: Jamie Lokier, William Lee Irwin III, Kernel Mailing List


On Thu, 24 Apr 2003, John Bradford wrote:
> 
> Incidently, using the Transmeta CPUs, is it not possible for the user
> to replace the controlling software with their own code?  I.E. not
> bother with X86 compatibility at all, but effectively design your own
> CPU?  Couldn't we make the first Lin-PU this way?

Well, I have to say that Transmeta CPU's aren't exactly known for their 
openness ;)

Also, the native mode is not very pleasant at all, and it really is 
designed for translation (and with a x86 flavour, too). You might as well 
think of it as a microcode on steroids.

If open hardware is what you want, FPGA's are actually getting to the
point where you can do real CPU's with them. They won't be gigahertz, and
they won't have big nice caches (but hey, you might make something that
clocks fairly close to memory speeds, so you might not care about the
latter once you have the former).

They're even getting reasonably cheap.

		Linus


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24 12:36 Downing, Thomas
@ 2003-04-24 14:12 ` Timothy Miller
  2003-04-24 22:48   ` Werner Almesberger
  2003-04-25 12:29   ` Ragnar Hojland Espinosa
  0 siblings, 2 replies; 130+ messages in thread
From: Timothy Miller @ 2003-04-24 14:12 UTC (permalink / raw)
  To: Downing, Thomas; +Cc: Kernel Mailing List



Downing, Thomas wrote:

>IMHO the DRM issue is not one that will be settled in either the software
>or hardware area, but in the legal one.
>
>[snip]
>
>So this leads me to a position I would have, without reflection, not taken;
>while I despise the current subversion of fair use and first point of sale
>undertaken by MPAA, RIAA, et al., I agree with what I understand Linus to
>say - DRM yes or no should not be mandated by license.
>-
>
>  
>

I feel like I'm late into this discussion, but anyhow...

Do we have any kind of agenda to spread Linux?  I mean, it sure is 
spreading, eating into other markets, for instance Windows.  But how 
interested are we in doing things specifically to accelerate that?  

One of the things that we could do to accelerate the adoption of Linux 
is to support DRM.  Yes, we know it's evil, but if we are the ones 
developing it, at least we know what it is and is not doing and how it 
works.  

As much as I dislike Microsoft for its business practices, I still feel 
uneasy having illegal copies of their Office suite.  So I use OpenOffice 
instead.  Likewise, I prefer to use Linux because having a free copy of 
it is perfectly legal.  And finally, although I do like the idea of 
being able to sample music before I buy it, I feel an attachment to 
artists I listen to, so I buy their CD's (despite the fact that it helps 
the RIAA).

So the idea of having something which prevents me from illegally 
pirating something doesn't bother me so much.  Whenever I have to do 
serious work, I either use an OSS tool, or I pay money for a piece of 
software so I can get support -- sometimes, I even pay for OSS stuff. 
 The idea of a DRM system malfunctioning and preventing me from 
accessing my legally-licensed material DOES bother me very much, but I 
think only in the hands of people like us can it be done right, because 
we're the very ones who would suffer were it to break.

In the end, of course, this is up to Linus, at least in terms of the 
mainline tree.  Whatever his opinion might be, we're going to have to 
make a bullet-proof argument to officially go one way or the other on this.



^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  5:16   ` Linus Torvalds
@ 2003-04-24 13:08     ` Shawn
  2003-04-24 20:12       ` Kenneth Johansson
  2003-04-24 17:32     ` Andreas Boman
  1 sibling, 1 reply; 130+ messages in thread
From: Shawn @ 2003-04-24 13:08 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Andre Hedrick, Kernel Mailing List

Ever notice Linus has a very distinct writing style? _under_scores_ 
and: colons. (Underscored colons sound ouchy!)
			Signatures
after three tabs...

He has very clear and logic oriented writing style, yet unique somehow.
You can almost here him talk when you read a _Linus_ message.

There's only one Linus: Let's keep it that way! Let's sign him with gpg
and take measures so that he _only_ operates in _good_ mode on DRM
enabled LKML.

			Shawn

On Thu, 2003-04-24 at 01:16, Linus Torvalds wrote:
> On Wed, 23 Apr 2003, Andre Hedrick wrote:
> > 
> > Now the digital signing issue as a means to protect possible embedded or
> > distribution environments is needed.  DRM cuts two ways and do not forget
> > it!
> 
> This is _the_ most important part to remember.
> 
> Security is a two-edged sword. It can be used _for_ you, and it can be
> used _against_ you. A fence keeps the bad guys out, but by implication the
> bad guys can use it to keep _you_ out, too.
> 
> The technology itself is pretty neutral, and I'm personally pretty
> optimistic that _especially_ in an open-source environment we will find
> that most of the actual effort is going to be going into making security
> be a _pro_consumer_ thing. Security for the user, not to screw the user.
> 
> Put another way: I'd rather embrace it for the positive things it can do
> for us, than have _others_ embrace it for the things it can do for them.
> 
> > For those not aware, each and every kernel you download from K.O is DRM
> > signed as a means to authenticate purity.
> 
> Yup. And pretty much every official .rpm or .deb package (source and
> binary) is already signed by the company that made that package, for
> _your_ protection. This is already "accepted practice", so allowing 
> signing is not something new per se, including on a binary level.
> 
> So what I hope this discussion brings as news is to make people aware of
> it. And that very much includes making people aware of the fact that there
> are some scary sides to signing stuff - and that they're par for the
> course, and part of the package. I know for a fact that a number of 
> people were hoping for the upsides without any of the downsides. That's 
> not how it works.
> 
> 			Linus
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  8:59   ` Jamie Lokier
@ 2003-04-24 12:52     ` Andreas Jellinghaus
  2003-04-24 15:37     ` Timothy Miller
  1 sibling, 0 replies; 130+ messages in thread
From: Andreas Jellinghaus @ 2003-04-24 12:52 UTC (permalink / raw)
  To: Jamie Lokier; +Cc: linux-kernel

On Thu, 2003-04-24 at 10:59, Jamie Lokier wrote:
> Andreas Jellinghaus wrote:
> > In ka.lists.linux.kernel, you wrote:
> > >   I want to make it clear that DRM is perfectly ok with Linux!
> > 
> > thanks for such a clear statement.
> 
> Anybody would think Linux was written solely by Linus

if someone is so stupid to think that linux was written
by a single person, he would surely name "bill gates".

Andreas


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  3:59 Linus Torvalds
                   ` (7 preceding siblings ...)
  2003-04-24  8:57 ` Arjan van de Ven
@ 2003-04-24 12:39 ` Mark Mielke
  2003-04-24 15:53 ` Elladan
                   ` (2 subsequent siblings)
  11 siblings, 0 replies; 130+ messages in thread
From: Mark Mielke @ 2003-04-24 12:39 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailing List

On Wed, Apr 23, 2003 at 08:59:45PM -0700, Linus Torvalds wrote:
>   I want to make it clear that DRM is perfectly ok with Linux!
> There, I've said it. I'm out of the closet. So bring it on...

How *DARE* you offer stuff for *FREE* when you have a perfectly decent
"GPL-like freedom" license you could enforce?

mark (hehe...)

-- 
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/


^ permalink raw reply	[flat|nested] 130+ messages in thread

* RE: Flame Linus to a crisp!
@ 2003-04-24 12:36 Downing, Thomas
  2003-04-24 14:12 ` Timothy Miller
  0 siblings, 1 reply; 130+ messages in thread
From: Downing, Thomas @ 2003-04-24 12:36 UTC (permalink / raw)
  To: Kernel Mailing List

IMHO the DRM issue is not one that will be settled in either the software
or hardware area, but in the legal one.

What is driving DRM is the desire to control content beyond the point of
sale or distribution.  This cannot be done in any absolute way by
purely technological means.  Any such scheme only sets the bar for how
difficult it is to access the media in a way not intended by the vendor.

This is the motivation behind DMCA, EULA, and all their ilk.  It does not
matter how open the software _and_ hardware are, if those with a vested
interest in strong control of media use have such laws, deep pockets, and
a willingness to aggressively prosecute those the consider in violation
of such laws.

If my contention is correct, then it follows that effective action against
abuses of DRM and related technologies are primarily political and legal,
not technological.  This is not to say the technological side isn't
important - DeCSS is a case in point.

So this leads me to a position I would have, without reflection, not taken;
while I despise the current subversion of fair use and first point of sale
undertaken by MPAA, RIAA, et al., I agree with what I understand Linus to
say - DRM yes or no should not be mandated by license.

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  9:19   ` Russell King
@ 2003-04-24 11:38     ` Shachar Shemesh
  2003-04-24 17:46       ` Shachar Shemesh
  0 siblings, 1 reply; 130+ messages in thread
From: Shachar Shemesh @ 2003-04-24 11:38 UTC (permalink / raw)
  To: Russell King; +Cc: Arjan van de Ven, Linus Torvalds, Kernel Mailing List

Russell King wrote:

>You just arrange for the script to detect whether a private key is
>present.  If none exists, it asks the user whether they want to generate
>a private key, and then calls gpg with the relevant options to do so.
>
>The private key isn't part of the script, nor is it a requirement to
>be able to (successfully) run the script.
>
>Note that the GPL does not say whether the output from the installation
>script has to be usable with the target hardware.
>
>  
>
>On Thu, Apr 24, 2003 at 10:57:21AM +0200, Arjan van de Ven wrote:
>  
>
>For an executable work, complete source code means all the source code
>for all modules it contains, plus any associated interface definition
>files, plus the scripts used to control compilation and installation of
>the executable.
>  
>
Wouldn't "control ... installation" include the keys too?

IANAL, but I am on the board of an NPO that advocates Free and Open 
Source Software, and that NPO has a lawyer (who is VERY familiar with 
the GPL). Would it make sense to ask him? After all, that merely means 
what one lawyer would say.

-- 
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/



^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  5:43   ` Linus Torvalds
  2003-04-24  6:15     ` William Lee Irwin III
@ 2003-04-24 10:57     ` Giuliano Pochini
  2003-04-24 22:51     ` Adrian Bunk
  2 siblings, 0 replies; 130+ messages in thread
From: Giuliano Pochini @ 2003-04-24 10:57 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Kernel Mailing List, Kernel Mailing List, William Lee Irwin III


On 24-Apr-2003 Linus Torvalds wrote:
>> I'm not particularly interested in the high-flown moral issues, but
>> this DRM stuff smelled like nothing more than a transparent ploy to
>> prevent anything but bloze from booting on various boxen to me.
>
> Let's be honest - to some people that is _exactly_ what DRM is. No ifs,
> buts and maybes.
>
> And hey, the fact is (at least as far as I'm concerned), that as long as
> you make the hardware, you can control what it runs.
>
> The GPL requires that you make the software available - but it doesn't
> require that the hardware be made so that you can always upgrade it.

Free software is free. You can do anything with it, the only contraint
is it must stay free. But cryptography plays a bad role here. Someone
can make hw that accepts only that peice of signed free software. You
have the hw, you have the binaries, you have the sources. But the
sources are completely useless. GPL allows the user to modify it, but
the hw doesn't run the modified copy. DRM can turns free software into
half-proprietary software. I don't like it at all, but I don't see any
solution.


Bye.


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  5:02     ` Clemens Schwaighofer
  2003-04-24  5:39       ` viro
@ 2003-04-24 10:54       ` Felipe Alfaro Solana
  2003-04-25  0:07         ` Clemens Schwaighofer
  1 sibling, 1 reply; 130+ messages in thread
From: Felipe Alfaro Solana @ 2003-04-24 10:54 UTC (permalink / raw)
  To: Clemens Schwaighofer; +Cc: Linus Torvalds, Kernel Mailing List

On Thu, 2003-04-24 at 07:02, Clemens Schwaighofer wrote:
> > Because signing is (at least right now) the only way to show that you
> > trust something. And if you can't show that you trust something, you
> can't
> > have any real security.
> 
> so should we start to sign all our emails? so we know we trust each other?

Can I trust you? Uhmm... Are you really Clemens? Please, prove it with
this simply challenge: what was the kernel version that first introduced
explicit return codes in drivers for stating that an IRQ was handled?
;-)

All of this DRM stuff gives me headaches.

-- 
Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
Linux Registered User #287198


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  5:39       ` viro
  2003-04-24  5:56         ` Valdis.Kletnieks
@ 2003-04-24  9:46         ` Clemens Schwaighofer
  1 sibling, 0 replies; 130+ messages in thread
From: Clemens Schwaighofer @ 2003-04-24  9:46 UTC (permalink / raw)
  To: viro; +Cc: Linus Torvalds, Kernel Mailing List

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

viro@parcelfarce.linux.theplanet.co.uk wrote:

> On Thu, Apr 24, 2003 at 02:02:54PM +0900, Clemens Schwaighofer wrote:

>>Point for me is, that with a DRM you could 100% verify that foreign
>>module Y is 100% from company Z. Or that binary product F is 100% from
>>the company and can be trusted to run here or there.
>
> Excuse me, but I don't get the last part.  You know that
> 	F had been built in environment of unspecified degree of security
> 	from source that had been kept in <--->
> 	written by programmers you don't know
> 	who had been hired in conformace with criteria <--->
> 	and released after passing QA of unknown quality (but you can bet
> that they had missed some security holes in the past)
> 	under a license that almost certainly disclaims any responsibility.
>
> Care to explain how does one get from the trust in above to "trusted
to run"?

I am sorry, I read some other posts that came in after I sent this, one
which explains the true status of DRM, which I was not aware of. Seems
to me that it is a super flawed system, far from what it should be.

Well ... this puts total different weight on the "urge" to put it into
the kernel, if it is flawed that much.

- --
Clemens Schwaighofer - IT Engineer & System Administration
==========================================================
Tequila Japan, 6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN
Tel: +81-(0)3-3545-7703            Fax: +81-(0)3-3545-7343
http://www.tequila.jp
==========================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+p7KCjBz/yQjBxz8RAry9AJ4x/m8NU/YYDSlTNc+WmlcTytNV9gCdEKen
7DeQZU/syw7wNAV+ke8XS9w=
=dHj9
-----END PGP SIGNATURE-----


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  8:57 ` Arjan van de Ven
@ 2003-04-24  9:19   ` Russell King
  2003-04-24 11:38     ` Shachar Shemesh
  2003-04-24 14:59   ` Linus Torvalds
  1 sibling, 1 reply; 130+ messages in thread
From: Russell King @ 2003-04-24  9:19 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: Linus Torvalds, Kernel Mailing List

On Thu, Apr 24, 2003 at 10:57:21AM +0200, Arjan van de Ven wrote:
> where it seems to say that if you need a script to be able to usefully
> install a self compiled kernel, that script is part of "the sourcecode".
> Now this of course can't and doesn't mean that people would need to give
> up their private keys to the public; said "script" of course can also
> install a second key or disable the keychecking. 
> 
> Or maybe I'm just totally interpreting this wrong.

You just arrange for the script to detect whether a private key is
present.  If none exists, it asks the user whether they want to generate
a private key, and then calls gpg with the relevant options to do so.

The private key isn't part of the script, nor is it a requirement to
be able to (successfully) run the script.

Note that the GPL does not say whether the output from the installation
script has to be usable with the target hardware.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  8:37 ` Andreas Jellinghaus
@ 2003-04-24  8:59   ` Jamie Lokier
  2003-04-24 12:52     ` Andreas Jellinghaus
  2003-04-24 15:37     ` Timothy Miller
  0 siblings, 2 replies; 130+ messages in thread
From: Jamie Lokier @ 2003-04-24  8:59 UTC (permalink / raw)
  To: Andreas Jellinghaus; +Cc: linux-kernel

Andreas Jellinghaus wrote:
> In ka.lists.linux.kernel, you wrote:
> >   I want to make it clear that DRM is perfectly ok with Linux!
> 
> thanks for such a clear statement.

Anybody would think Linux was written solely by Linus, the way His
words are taken as summarising the intent of all its authors...

-- Jamie


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  8:31           ` Jamie Lokier
@ 2003-04-24  8:59             ` John Bradford
  0 siblings, 0 replies; 130+ messages in thread
From: John Bradford @ 2003-04-24  8:59 UTC (permalink / raw)
  To: Jamie Lokier
  Cc: John Bradford, William Lee Irwin III, Linus Torvalds,
	Kernel Mailing List

> > With open hardware designs, there would be no problem with
> > documentation not being available to write drivers.
> 
> See below...
> 
> > Incidently, using the Transmeta CPUs, is it not possible for the user
> > to replace the controlling software with their own code?  I.E. not
> > bother with X86 compatibility at all, but effectively design your own
> > CPU?  Couldn't we make the first Lin-PU this way?
> 
> In theory; in practice we have no access to documentation.  See above...

I'm now stuck in a mail reading loop, with the see above and see
belows :-)

> That makes Transmeta part of the _old_ industry :)
> 
> I believe present Transmeta CPUs are quite specialised for x86
> behaviour (memory model etc.) anyway.  When you're running on a CPU
> like that, there's probably little to be gained from changing to a
> different front-end instruction set.
> 
> Special tricks like non-cache-ping-ponging locks and faster interrupt
> handling might improve performance, but probably require a change of
> the hardware to implement.

Shame.  I guess it wouldn't really have got us any closer to an open
hardware design anyway, it just seemed like a nice hack :-).

John.

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  3:59 Linus Torvalds
                   ` (6 preceding siblings ...)
  2003-04-24  8:37 ` Andreas Jellinghaus
@ 2003-04-24  8:57 ` Arjan van de Ven
  2003-04-24  9:19   ` Russell King
  2003-04-24 14:59   ` Linus Torvalds
  2003-04-24 12:39 ` Mark Mielke
                   ` (3 subsequent siblings)
  11 siblings, 2 replies; 130+ messages in thread
From: Arjan van de Ven @ 2003-04-24  8:57 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

On Thu, 2003-04-24 at 05:59, Linus Torvalds wrote:

> 
> The GPL requires you to give out sources to the kernel, but it doesn't
> limit what you can _do_ with the kernel. On the whole, this is just
> another example of why rms calls me "just an engineer" and thinks I have
> no ideals.

The "hot" issue is partially this part of the GPL:

For an executable work, complete source code means all the source code
for all modules it contains, plus any associated interface definition
files, plus the scripts used to control compilation and installation of
the executable.

where it seems to say that if you need a script to be able to usefully
install a self compiled kernel, that script is part of "the sourcecode".
Now this of course can't and doesn't mean that people would need to give
up their private keys to the public; said "script" of course can also
install a second key or disable the keychecking. 

Or maybe I'm just totally interpreting this wrong.
 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  8:16         ` John Bradford
  2003-04-24  8:31           ` Jamie Lokier
@ 2003-04-24  8:50           ` Jamie Lokier
  2003-04-24 14:45           ` Linus Torvalds
  2 siblings, 0 replies; 130+ messages in thread
From: Jamie Lokier @ 2003-04-24  8:50 UTC (permalink / raw)
  To: John Bradford; +Cc: William Lee Irwin III, Linus Torvalds, Kernel Mailing List

John Bradford wrote:
> > If the hardware that comes out of industry won't let you hack, hey you
> > still have basic materials like SiO2 from the real world to make your
> > own.  Tough, but rewarding :)
> 
> We should be doing this _anyway_.
> 
> With open hardware designs, there would be no problem with
> documentation not being available to write drivers.

Open hardware design has a long way to come along, but the real
problem is that making hardware is very expensive - because it is
actually very difficult and depends upon enormous global industries.
Even making a one-off PCB is very expensive compared with buying
commodity hardware that does interesting stuff.

I was looking at various lumps of wood, metal and plastic around my
home and realised that I'd have a hard time making _anything_ that I
use daily, let alone computer hardware.

I'd love to find a cheaper, more accessible way of manufacturing
hardware than is available to individuals at present.

In principle, the industry which can make things could make use of
open source designs, and then sell them to us.  I'm not sure how to
make that come about, or how to make those things readily extendable
by enthusiastic users - to close the loop.

-- Jamie

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  5:56         ` Valdis.Kletnieks
@ 2003-04-24  8:46           ` Dax Kelson
  0 siblings, 0 replies; 130+ messages in thread
From: Dax Kelson @ 2003-04-24  8:46 UTC (permalink / raw)
  To: Valdis.Kletnieks
  Cc: viro, Clemens Schwaighofer, Linus Torvalds, Kernel Mailing List

On Thu, 24 Apr 2003 Valdis.Kletnieks@vt.edu wrote:

> On top of which, if a buffer overflow is found, the exploit will run in
> the context of the signed program. 

Two examples I can think of right now:

1. Manipulated 007 save games files can subvert the Xbox when they 
overflow the trusted game.
2. The "hack resistant" series 2 Tivo boxes can be subverted by a 
insecure, signed Linux kernel.

The Tivo kernel is signed with ElGamal, and the Tivo firmware will refuse
to run a non-signed kernel and initrd image. The initrd image has SHA1
hashes of all the bootup config files, binaries and and a hash checker.  
The idea here is that Tivo can control what is executed.

Turns out Tivo signed a kernel+initrd that wasn't locked down properly.  
Oops! This kernel+initrd package has become a hot commodity.

The pieces that come together are:

1. All directories/files are verified EXCEPT stuff on /var
- However, none of the hash checked boot scripts reference anything on 
/var

2. Users can control what command line is passed to the kernel

3. Users can put the Tivo hard drive in a PC and put stuff on /var.

Finally, Tivo didn't validate/scrub the kernel command line properly, and 
people were able to get their own daemons and code running, stored on 
/var, by passing BASH_ENV with a funky value to the kernel.

Dax Kelson


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  3:59 Linus Torvalds
                   ` (5 preceding siblings ...)
  2003-04-24  7:55 ` Jamie Lokier
@ 2003-04-24  8:37 ` Andreas Jellinghaus
  2003-04-24  8:59   ` Jamie Lokier
  2003-04-24  8:57 ` Arjan van de Ven
                   ` (4 subsequent siblings)
  11 siblings, 1 reply; 130+ messages in thread
From: Andreas Jellinghaus @ 2003-04-24  8:37 UTC (permalink / raw)
  To: linux-kernel

In ka.lists.linux.kernel, you wrote:
>   I want to make it clear that DRM is perfectly ok with Linux!

thanks for such a clear statement.

Andreas

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  8:16         ` John Bradford
@ 2003-04-24  8:31           ` Jamie Lokier
  2003-04-24  8:59             ` John Bradford
  2003-04-24  8:50           ` Jamie Lokier
  2003-04-24 14:45           ` Linus Torvalds
  2 siblings, 1 reply; 130+ messages in thread
From: Jamie Lokier @ 2003-04-24  8:31 UTC (permalink / raw)
  To: John Bradford; +Cc: William Lee Irwin III, Linus Torvalds, Kernel Mailing List

John Bradford wrote:
> With open hardware designs, there would be no problem with
> documentation not being available to write drivers.

See below...

> Incidently, using the Transmeta CPUs, is it not possible for the user
> to replace the controlling software with their own code?  I.E. not
> bother with X86 compatibility at all, but effectively design your own
> CPU?  Couldn't we make the first Lin-PU this way?

In theory; in practice we have no access to documentation.  See above...

That makes Transmeta part of the _old_ industry :)

I believe present Transmeta CPUs are quite specialised for x86
behaviour (memory model etc.) anyway.  When you're running on a CPU
like that, there's probably little to be gained from changing to a
different front-end instruction set.

Special tricks like non-cache-ping-ponging locks and faster interrupt
handling might improve performance, but probably require a change of
the hardware to implement.

-- Jamie

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  7:44       ` Jamie Lokier
  2003-04-24  8:03         ` Jan-Benedict Glaw
@ 2003-04-24  8:16         ` John Bradford
  2003-04-24  8:31           ` Jamie Lokier
                             ` (2 more replies)
  2003-04-24 18:58         ` Daniel Phillips
  2 siblings, 3 replies; 130+ messages in thread
From: John Bradford @ 2003-04-24  8:16 UTC (permalink / raw)
  To: Jamie Lokier; +Cc: William Lee Irwin III, Linus Torvalds, Kernel Mailing List

> > Well, my walking out of computing is tied to complete prevention of
> > kernel hacking on commodity hardware, so you've not lost anything yet.
> > I only really care if it's no longer possible to get a commodity system
> > to run Linux on at all, not about crypto dongles.
> 
> If it ever gets that bad, email me and we'll find a way to create
> hardware without those restrictions, and get it to people who want it.
> 
> If the hardware that comes out of industry won't let you hack, hey you
> still have basic materials like SiO2 from the real world to make your
> own.  Tough, but rewarding :)

We should be doing this _anyway_.

With open hardware designs, there would be no problem with
documentation not being available to write drivers.

With open hardware designed by Linux developers, we could have
hardware _designed_ for Linux.

Incidently, using the Transmeta CPUs, is it not possible for the user
to replace the controlling software with their own code?  I.E. not
bother with X86 compatibility at all, but effectively design your own
CPU?  Couldn't we make the first Lin-PU this way?

John.

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  7:44       ` Jamie Lokier
@ 2003-04-24  8:03         ` Jan-Benedict Glaw
  2003-04-25  1:16           ` Jan Harkes
  2003-04-24  8:16         ` John Bradford
  2003-04-24 18:58         ` Daniel Phillips
  2 siblings, 1 reply; 130+ messages in thread
From: Jan-Benedict Glaw @ 2003-04-24  8:03 UTC (permalink / raw)
  To: Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]

On Thu, 2003-04-24 08:44:00 +0100, Jamie Lokier <jamie@shareable.org>
wrote in message <20030424074400.GD28253@mail.jlokier.co.uk>:
> William Lee Irwin III wrote:
> > Well, my walking out of computing is tied to complete prevention of
> > kernel hacking on commodity hardware, so you've not lost anything yet.
> > I only really care if it's no longer possible to get a commodity system
> > to run Linux on at all, not about crypto dongles.
> 
> It only gets _really_ bad when it becomes illegal to make your own
> hardware :(

We're basically already at that point. IIRC, I've read an article about
something called "Super-DMCA" which prevents you (beside other things) to
build up "systems" that could scrambl/encrypt sounds for pretected
transmission (think VoIP over ssh or something like that in hardware).

Even right now, you don't simply have (everywhere on this globe) the
right to build a simple piece of hardware protecting your phone calls...

This said, it _may_ even be illegal from this point of view to create a
"new" general-purpose computer as it could be used for this purpose.

Though, IANAL.

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  3:59 Linus Torvalds
                   ` (4 preceding siblings ...)
  2003-04-24  5:15 ` William Lee Irwin III
@ 2003-04-24  7:55 ` Jamie Lokier
  2003-04-24  8:37 ` Andreas Jellinghaus
                   ` (5 subsequent siblings)
  11 siblings, 0 replies; 130+ messages in thread
From: Jamie Lokier @ 2003-04-24  7:55 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailing List

Linus Torvalds wrote:
[a message which I found quite surreal]

I felt as though I were reading on of those April 1st fake Linus emails.
But my sleep cycle is so screwed everything feels like that today :)

I don't mind if commodity hardware becomes DRM-locked, like the X-box,
so long as it remains legal to develop alternative hardware.  20 years
ago it would have been a real problem, but I think we have access to
enough computing and communications resource today that we could
actually develop alternate hardware if needed - if there enough
motivation.

Not there will ever be a need - see how virtually all the DVD players
you can buy have "play any region" back doors.  If there were lots of
manufacturers of things like the X-box (as you'd expect for a 2006
PC), expect to see some of them putting DRM-disabler back doors in.

The scary part is when it becomes illegal to use those back doors, or
(much worse IMHO) illegal to make your own equipment.

[Oh, I see that has already begun.  Shit!]

On a related note, it's World Intellectual Property Day this Saturday:

    http://www.wipo.int/about-ip/en/index.html?wipo_content_frame=/about-ip/en/world_ip/2003/index.htm

[Personally I find WIPO's cute fluffy leaflets about protecting the
small inventor from the big sharks rather creepy.  They start with
generalities about one-man designers in poorest Africa, and how they
can protect their designs from being ripped off.  Then lead to
examples of where this has worked, and the inventors in the examples
are all huge companies with familiar names, the very companies I see
as big sharks.  Ah well.]

-- Jamie

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  6:15     ` William Lee Irwin III
@ 2003-04-24  7:44       ` Jamie Lokier
  2003-04-24  8:03         ` Jan-Benedict Glaw
                           ` (2 more replies)
  0 siblings, 3 replies; 130+ messages in thread
From: Jamie Lokier @ 2003-04-24  7:44 UTC (permalink / raw)
  To: William Lee Irwin III, Linus Torvalds, Kernel Mailing List

William Lee Irwin III wrote:
> Well, my walking out of computing is tied to complete prevention of
> kernel hacking on commodity hardware, so you've not lost anything yet.
> I only really care if it's no longer possible to get a commodity system
> to run Linux on at all, not about crypto dongles.

Hi William,

If it ever gets that bad, email me and we'll find a way to create
hardware without those restrictions, and get it to people who want it.

If the hardware that comes out of industry won't let you hack, hey you
still have basic materials like SiO2 from the real world to make your
own.  Tough, but rewarding :)

It only gets _really_ bad when it becomes illegal to make your own
hardware :(

-- Jamie

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  5:43   ` Linus Torvalds
@ 2003-04-24  6:15     ` William Lee Irwin III
  2003-04-24  7:44       ` Jamie Lokier
  2003-04-24 10:57     ` Giuliano Pochini
  2003-04-24 22:51     ` Adrian Bunk
  2 siblings, 1 reply; 130+ messages in thread
From: William Lee Irwin III @ 2003-04-24  6:15 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailing List

On Wed, Apr 23, 2003 at 10:43:37PM -0700, Linus Torvalds wrote:
> So I really want to set peoples _expectations_ right. I'd rather lose a 
> developer over a flame-war here on Linux-kernel as a result of this 
> discussion, than having somebody unhappy later on about having "wasted 
> their time" on a project that then allowed things to happen that that 
> developer felt was inherently morally _wrong_.
> And this is where it touches upon kernel development. Not because I expect
> to apply DRM patches in the near future or anything like that: but simply
> because it's better to bring up the issue so that people know where they
> stand, and not have the wrong expectations of how their code might be used
> by third parties.

Well, my walking out of computing is tied to complete prevention of
kernel hacking on commodity hardware, so you've not lost anything yet.
I only really care if it's no longer possible to get a commodity system
to run Linux on at all, not about crypto dongles.


-- wli

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  5:39       ` viro
@ 2003-04-24  5:56         ` Valdis.Kletnieks
  2003-04-24  8:46           ` Dax Kelson
  2003-04-24  9:46         ` Clemens Schwaighofer
  1 sibling, 1 reply; 130+ messages in thread
From: Valdis.Kletnieks @ 2003-04-24  5:56 UTC (permalink / raw)
  To: viro; +Cc: Clemens Schwaighofer, Linus Torvalds, Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 876 bytes --]

On Thu, 24 Apr 2003 06:39:50 BST, viro@parcelfarce.linux.theplanet.co.uk said:

> Excuse me, but I don't get the last part.  You know that
> 	F had been built in environment of unspecified degree of security
> 	from source that had been kept in <--->
> 	written by programmers you don't know
> 	who had been hired in conformace with criteria <--->
> 	and released after passing QA of unknown quality (but you can bet
> that they had missed some security holes in the past)
> 	under a license that almost certainly disclaims any responsibility.
> 
> Care to explain how does one get from the trust in above to "trusted to run"?

On top of which, if a buffer overflow is found, the exploit will run in
the context of the signed program.  What it *does* mean is that once the
ankle-biting script kiddie breaks in, the kernel will hopefully refuse to
run their unsigned exploits.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  5:15 ` William Lee Irwin III
@ 2003-04-24  5:43   ` Linus Torvalds
  2003-04-24  6:15     ` William Lee Irwin III
                       ` (2 more replies)
  0 siblings, 3 replies; 130+ messages in thread
From: Linus Torvalds @ 2003-04-24  5:43 UTC (permalink / raw)
  To: William Lee Irwin III; +Cc: Kernel Mailing List


On Wed, 23 Apr 2003, William Lee Irwin III wrote:
> 
> I'm not particularly interested in the high-flown moral issues, but
> this DRM stuff smelled like nothing more than a transparent ploy to
> prevent anything but bloze from booting on various boxen to me.

Let's be honest - to some people that is _exactly_ what DRM is. No ifs, 
buts and maybes. 

And hey, the fact is (at least as far as I'm concerned), that as long as
you make the hardware, you can control what it runs.

The GPL requires that you make the software available - but it doesn't 
require that the hardware be made so that you can always upgrade it.

You could write a kernel binary into a ROM, and solder it to the
motherboard. That's fine - always has been. As long as you give out the
sources to the software, there's nothing that says that the hardware has
to be built to make it easy - or even possible - to change the binary
there.

The beauty of PC's is how _flexible_ they are, and I think a lot of us
take that kind of flexibility for granted. But the fact is, 99% of the
worlds CPU's tend to go into devices that are _not_ general-purpose or
flexible. And it shouldn't offend us (at most it might make us pity the
poor hobbled hardware).

And there are projects for doing "Open Hardware" (like opencores.org etc),
and that may well end up being a hugely important thing to do. But Linux
is about open source, not open hardware, and hardware openness has never 
been a requirement for running Linux.

> But I suppose it could be used to force particular versions of Linux
> to be used, e.g. ones with particular patches that do permissions
> checks or various things meant to prevent warezing.

Yes, that too. Or it could well be used to allow _running_ of any version 
of Linux at all, but maybe the firmware/hardware combination only gives 
the kernel the keys needed to decrypt incoming cable or satellite feeds if 
it trusts the kernel. 

So under such schenarios, you might have a machine that works as a regular 
PC, but the satellite company requires that only kernels _it_ trusts get 
to unscrambe the incoming feed.

Unfortunate? Yes. I suspect that almost all of us would rather have
unlimited feeds, and just take it on trust that people would do the right
thing. But I can understand why especially embedded Linux users may want
to control these things - and maybe my moral sense is lacking, but I just
can't see myself saying "no, you can't use Linux for that".

> I'm largely baffled as to what this has to do with Linux kernel
> hacking, as DRM appeared to me to primarily be hardware- and firmware-
> level countermeasures to prevent running Linux at all, i.e. boxen we're
> effectively forbidden from porting to.

It has almost zero to do with the kernel code itself, since in the end all
the DRM stuff ends up being at a much lower level (actual hardware, as you
say, along with things like firmware - bioses etc - that decide on whether
to trust what they run).

So in that sense I don't believe it has much of anything to do with the
kernel: you're very unlikely to see any DRM code show up in the "kernel
proper", if that's what you're asking. Although obviously many features in
the kernel can be used to _maintain_ DRM control (ie somehting as simple
as having file permissions is obviously nothing but a very specific form
of rights management).

HOWEVER. The discussion really does matter from a "developer expectation"  
standpoint. There are developers who feel so strongly about DRM that they
do not want to have anything to do with systems that could be "subverted"
by a DRM check. A long private thread I've had over this issue has 
convinced me that this is true, and that some people really do expect the 
GPL to protect them from that worry.

And I do not want to have developers who _think_ that they are protected 
from the kinds of controls that signed binaries together with a fascist 
BIOS can implement. That just leads to frustration and tears. So I want 
this issue brought out in the open, so that nobody feels that they are 
being "taken advantage" of.

Again, from personal email discussions I know that this is a real feeling. 

So I really want to set peoples _expectations_ right. I'd rather lose a 
developer over a flame-war here on Linux-kernel as a result of this 
discussion, than having somebody unhappy later on about having "wasted 
their time" on a project that then allowed things to happen that that 
developer felt was inherently morally _wrong_.

And this is where it touches upon kernel development. Not because I expect
to apply DRM patches in the near future or anything like that: but simply
because it's better to bring up the issue so that people know where they
stand, and not have the wrong expectations of how their code might be used
by third parties.

			Linus


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  5:02     ` Clemens Schwaighofer
@ 2003-04-24  5:39       ` viro
  2003-04-24  5:56         ` Valdis.Kletnieks
  2003-04-24  9:46         ` Clemens Schwaighofer
  2003-04-24 10:54       ` Felipe Alfaro Solana
  1 sibling, 2 replies; 130+ messages in thread
From: viro @ 2003-04-24  5:39 UTC (permalink / raw)
  To: Clemens Schwaighofer; +Cc: Linus Torvalds, Kernel Mailing List

On Thu, Apr 24, 2003 at 02:02:54PM +0900, Clemens Schwaighofer wrote:
 
> Point for me is, that with a DRM you could 100% verify that foreign
> module Y is 100% from company Z. Or that binary product F is 100% from
> the company and can be trusted to run here or there.

Excuse me, but I don't get the last part.  You know that
	F had been built in environment of unspecified degree of security
	from source that had been kept in <--->
	written by programmers you don't know
	who had been hired in conformace with criteria <--->
	and released after passing QA of unknown quality (but you can bet
that they had missed some security holes in the past)
	under a license that almost certainly disclaims any responsibility.

Care to explain how does one get from the trust in above to "trusted to run"?

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  4:54 ` Andre Hedrick
@ 2003-04-24  5:16   ` Linus Torvalds
  2003-04-24 13:08     ` Shawn
  2003-04-24 17:32     ` Andreas Boman
  0 siblings, 2 replies; 130+ messages in thread
From: Linus Torvalds @ 2003-04-24  5:16 UTC (permalink / raw)
  To: Andre Hedrick; +Cc: Kernel Mailing List


On Wed, 23 Apr 2003, Andre Hedrick wrote:
> 
> Now the digital signing issue as a means to protect possible embedded or
> distribution environments is needed.  DRM cuts two ways and do not forget
> it!

This is _the_ most important part to remember.

Security is a two-edged sword. It can be used _for_ you, and it can be
used _against_ you. A fence keeps the bad guys out, but by implication the
bad guys can use it to keep _you_ out, too.

The technology itself is pretty neutral, and I'm personally pretty
optimistic that _especially_ in an open-source environment we will find
that most of the actual effort is going to be going into making security
be a _pro_consumer_ thing. Security for the user, not to screw the user.

Put another way: I'd rather embrace it for the positive things it can do
for us, than have _others_ embrace it for the things it can do for them.

> For those not aware, each and every kernel you download from K.O is DRM
> signed as a means to authenticate purity.

Yup. And pretty much every official .rpm or .deb package (source and
binary) is already signed by the company that made that package, for
_your_ protection. This is already "accepted practice", so allowing 
signing is not something new per se, including on a binary level.

So what I hope this discussion brings as news is to make people aware of
it. And that very much includes making people aware of the fact that there
are some scary sides to signing stuff - and that they're par for the
course, and part of the package. I know for a fact that a number of 
people were hoping for the upsides without any of the downsides. That's 
not how it works.

			Linus


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  3:59 Linus Torvalds
                   ` (3 preceding siblings ...)
  2003-04-24  5:02 ` Mark J Roberts
@ 2003-04-24  5:15 ` William Lee Irwin III
  2003-04-24  5:43   ` Linus Torvalds
  2003-04-24  7:55 ` Jamie Lokier
                   ` (6 subsequent siblings)
  11 siblings, 1 reply; 130+ messages in thread
From: William Lee Irwin III @ 2003-04-24  5:15 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailing List

On Wed, Apr 23, 2003 at 08:59:45PM -0700, Linus Torvalds wrote:
> Comments? I'd love to get some real discussion about this, but in the end 
> I'm personally convinced that we have to allow it.
> Btw, one thing that is clearly _not_ allowed by the GPL is hiding private
> keys in the binary. You can sign the binary that is a result of the build
> process, but you can _not_ make a binary that is aware of certain keys
> without making those keys public - because those keys will obviously have
> been part of the kernel build itself.
> So don't get these two things confused - one is an external key that is
> applied _to_ the kernel (ok, and outside the license), and the other one
> is embedding a key _into_ the kernel (still ok, but the GPL requires that
> such a key has to be made available as "source" to the kernel).

I'm not particularly interested in the high-flown moral issues, but
this DRM stuff smelled like nothing more than a transparent ploy to
prevent anything but bloze from booting on various boxen to me.

But I suppose it could be used to force particular versions of Linux
to be used, e.g. ones with particular patches that do permissions
checks or various things meant to prevent warezing.

I'm largely baffled as to what this has to do with Linux kernel
hacking, as DRM appeared to me to primarily be hardware- and firmware-
level countermeasures to prevent running Linux at all, i.e. boxen we're
effectively forbidden from porting to. Even if vendors distribute their
own special Linux kernels with patches for anti-warezing checks that
boot on the things, the things are basically still just off-limits.

I guess there are other subtleties that fall out of it, like the DRM
stuff might be the only game in town so just not buying hardware you
don't like doesn't work, and just what the heck you paid for if you
can't use the stuff the way you want to (in theory, you could buy a
disk to use as a hockey puck, but this says you have to have some
magic kernel's notion of how to use it), but I'm hard-pressed to get
worked up about it. I'll just take up underwater basket weaving and
replace my computer with a typewriter and a calculator if it really
gets all that bad.


-- wli

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  5:02 ` Mark J Roberts
@ 2003-04-24  5:13   ` Clemens Schwaighofer
  0 siblings, 0 replies; 130+ messages in thread
From: Clemens Schwaighofer @ 2003-04-24  5:13 UTC (permalink / raw)
  To: Kernel Mailing List

Mark J Roberts wrote:

> Linus Torvalds:
> 
>>I want to make it clear that DRM is perfectly ok with Linux!
> 
> 
> What specifically are you referring to?

the fact that he got a call from MPAA ... at night ...

things go down the Spiral ...

-- 
Clemens Schwaighofer - IT Engineer & System Administration
==========================================================
Tequila Japan, 6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN
Tel: +81-(0)3-3545-7703            Fax: +81-(0)3-3545-7343
http://www.tequila.jp
==========================================================


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  4:57   ` Linus Torvalds
@ 2003-04-24  5:02     ` Clemens Schwaighofer
  2003-04-24  5:39       ` viro
  2003-04-24 10:54       ` Felipe Alfaro Solana
  0 siblings, 2 replies; 130+ messages in thread
From: Clemens Schwaighofer @ 2003-04-24  5:02 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailing List

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Linus Torvalds wrote:

If signing something with a public key, makes they GPL, this would be
ridicolous. I mean, when I use GPL mutt & GPL GnuPG and whatever.

Point for me is, that with a DRM you could 100% verify that foreign
module Y is 100% from company Z. Or that binary product F is 100% from
the company and can be trusted to run here or there.

I think the major problem with DRM is the negative vibration it bringts
with its very stupid use in all kind of Mass Media Music/Movie industry.
Which is in a kind of ultimate end-of-its-days panic.

> Because signing is (at least right now) the only way to show that you
> trust something. And if you can't show that you trust something, you
can't
> have any real security.

so should we start to sign all our emails? so we know we trust each other?

- --
Clemens Schwaighofer - IT Engineer & System Administration
==========================================================
Tequila Japan, 6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN
Tel: +81-(0)3-3545-7703            Fax: +81-(0)3-3545-7343
http://www.tequila.jp
==========================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+p2/9jBz/yQjBxz8RAtyMAKDUNJHWC3qRBtHgyVsT+S9d+VxeOQCeNMHU
u5QZX8ds7DS1r8rsYgSsQUw=
=vZBn
-----END PGP SIGNATURE-----


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  3:59 Linus Torvalds
                   ` (2 preceding siblings ...)
  2003-04-24  4:54 ` Andre Hedrick
@ 2003-04-24  5:02 ` Mark J Roberts
  2003-04-24  5:13   ` Clemens Schwaighofer
  2003-04-24  5:15 ` William Lee Irwin III
                   ` (7 subsequent siblings)
  11 siblings, 1 reply; 130+ messages in thread
From: Mark J Roberts @ 2003-04-24  5:02 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailing List

Linus Torvalds:
> I want to make it clear that DRM is perfectly ok with Linux!

What specifically are you referring to?

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  4:43 ` Greg KH
@ 2003-04-24  4:57   ` Linus Torvalds
  2003-04-24  5:02     ` Clemens Schwaighofer
  0 siblings, 1 reply; 130+ messages in thread
From: Linus Torvalds @ 2003-04-24  4:57 UTC (permalink / raw)
  To: Greg KH; +Cc: Kernel Mailing List


On Wed, 23 Apr 2003, Greg KH wrote:
> On Wed, Apr 23, 2003 at 08:59:45PM -0700, Linus Torvalds wrote:
> > 
> > Btw, one thing that is clearly _not_ allowed by the GPL is hiding private
> > keys in the binary. You can sign the binary that is a result of the build
> > process, but you can _not_ make a binary that is aware of certain keys
> > without making those keys public - because those keys will obviously have
> > been part of the kernel build itself.
> 
> The GPL does allow you to embed a public key in the kernel

Absolutely. That's why I said "private key".

It's clearly ok to embed any number of keys you damn well want inside the
kernel itself - it's just that the GPL requires that they be made
available as source, so by implication they had damn well better be
public.

So yes, it's perfectly fine to embed a public key inside the kernel, and 
use that public key to verify some external private key. 

> I know a lot of people can (and do) object to such a potential use of
> Linux, and I'm glad to see you explicitly state that this is an
> acceptable use, it helps to clear up the issue.

The reason I want to make it very explicit is that I know (judging from
the private discussions I've had over the last few weeks) that a lot of
people think that the GPL can be interpreted in such a way that even just
the act of signing a binary would make the key used for the signing be
covered by the GPL. Which obviously would make the act of signing
something totally pointless.

And even if some lawyer could interpret it that way (and hey, they take
limbo classes in law school explicitly to make sure that the lawyers _are_
flexible enough.  Really! Look it up in the dictionary - right next to
"gullible"), I wanted to make sure that we very explicitly do NOT
interpret it that way.

Because signing is (at least right now) the only way to show that you 
trust something. And if you can't show that you trust something, you can't 
have any real security.

The problem with security, of course, is exactly _whom_ the security is
put in place to protect. But that's not a question that we can (or should)
try to answer in a license. That's a question that you have to ask 
yourself when (and if) you're presented with such a device.

			Linus


^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  3:59 Linus Torvalds
  2003-04-24  4:40 ` Joel Jaeggli
  2003-04-24  4:43 ` Greg KH
@ 2003-04-24  4:54 ` Andre Hedrick
  2003-04-24  5:16   ` Linus Torvalds
  2003-04-24  5:02 ` Mark J Roberts
                   ` (8 subsequent siblings)
  11 siblings, 1 reply; 130+ messages in thread
From: Andre Hedrick @ 2003-04-24  4:54 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailing List


Linus,

First Point: DRM is going to happen regardless.
Fact: NCITS T10 adopted MMC3 which is part of SCSI
Fact: MMC3 is the home of CSS.
Fact: SCSI by default supports DRM because of MMC3, see /dev/sg.

Second Point: ATA is a state machine driven protocol.
Fact: DRM requires an alternative state machine.
Fact: Hollywood forced this issue not Linus or me.

Third Point: DRM would be more difficult, had I not introduced Taskfile.
Fact: By forcing the native driver to execute a command sequencer, DRM
      requires more than simple command operations.
Fact: DRM would have happend regardless, so the best one can do is attempt
      to manage the mess.

Fourth Point: The Electronic Frontier Foundation is to BLAME!
Fact: I single handed forced Intel, IBM, Toshiba, and Matshustia to agree
      to an on-off mode for DRM with enduser control lock outs.
Fact: Feb 2001, EFF played a wild card and destroyed the deal.
Fact: IBM (4C) withdraws proposal, under firestorm.
Fact: April 2001, General Purpose Commands happen, Son-of-CPRM.
Fact: GPC creates 16-19 flavors of DRM with backdoor renable register
      banging methods.

I can not show the unpublished version of the of the proposal, unless 4C
agrees to disclose.  Given the simple fact CPRM/DRM is present now, the
only solution was to control it.  I and a few others on the NCITS T13
committee with the help of MicroSoft had managed to make it so the enduser
could disable the feature set.  Again this is all about choice not single
minded dictatorships of nothing or nothing, aka EFF.  The simple fact is
some people may want to use DRM, and to prevent them is to cause a license
twist on GPL.  So now everyone has to live with the fact that DRM is here
and it is now in the hardware.

Now the digital signing issue as a means to protect possible embedded or
distribution environments is needed.  DRM cuts two ways and do not forget
it!  We as the opensouce community can use DRM as a means to allow or deny
an operation.  Now the time has come to determine how to use this tool.
Like fire, control DRM/CPRM and you recieve benefits.  Let it run wild and
you will be burned.

For those not aware, each and every kernel you download from K.O is DRM
signed as a means to authenticate purity.

I suspect, this will fall in to the same arena as LSM, and that is where I
am going to move to push it.  DRM/CPRM has its use, and if managed well
and open we can exploit it in ways that may even cause Hollywood people to
back off.

Regards,

Andre Hedrick
LAD Storage Consulting Group

PS: If this turns into a flame fest, the absolute seriousness of this
issue will be lost.  I have rented a blowtorch and flamethrower, and
prepared to destroy people who attempt to make this messy.  One of the
last things I will do before stepping to the side, will be to resolve this
issue in a constructive way.  So if it turns nasty, I am here for the long
haul, and it has been almost two years since I have scourched lkml.  This
is not how I wanted to go out or move on to the next issue.

On Wed, 23 Apr 2003, Linus Torvalds wrote:

> 
> Ok, 
>  there's no way to do this gracefully, so I won't even try. I'm going to 
> just hunker down for some really impressive extended flaming, and my 
> asbestos underwear is firmly in place, and extremely uncomfortable.
> 
>   I want to make it clear that DRM is perfectly ok with Linux!
> 
> There, I've said it. I'm out of the closet. So bring it on...
> 
> I've had some private discussions with various people about this already,
> and I do realize that a lot of people want to use the kernel in some way
> to just make DRM go away, at least as far as Linux is concerned. Either by
> some policy decision or by extending the GPL to just not allow it.
> 
> In some ways the discussion was very similar to some of the software
> patent related GPL-NG discussions from a year or so ago: "we don't like
> it, and we should change the license to make it not work somehow". 
> 
> And like the software patent issue, I also don't necessarily like DRM
> myself, but I still ended up feeling the same: I'm an "Oppenheimer", and I
> refuse to play politics with Linux, and I think you can use Linux for
> whatever you want to - which very much includes things I don't necessarily
> personally approve of.
> 
> The GPL requires you to give out sources to the kernel, but it doesn't
> limit what you can _do_ with the kernel. On the whole, this is just
> another example of why rms calls me "just an engineer" and thinks I have
> no ideals.
> 
> [ Personally, I see it as a virtue - trying to make the world a slightly
>   better place _without_ trying to impose your moral values on other 
>   people. You do whatever the h*ll rings your bell, I'm just an engineer 
>   who wants to make the best OS possible. ]
> 
> In short, it's perfectly ok to sign a kernel image - I do it myself
> indirectly every day through the kernel.org, as kernel.org will sign the
> tar-balls I upload to make sure people can at least verify that they came
> that way. Doing the same thing on the binary is no different: signing a
> binary is a perfectly fine way to show the world that you're the one
> behind it, and that _you_ trust it.
> 
> And since I can imaging signing binaries myself, I don't feel that I can
> disallow anybody else doing so.
> 
> Another part of the DRM discussion is the fact that signing is only the 
> first step: _acting_ on the fact whether a binary is signed or not (by 
> refusing to load it, for example, or by refusing to give it a secret key) 
> is required too.
> 
> But since the signature is pointless unless you _use_ it for something,
> and since the decision how to use the signature is clearly outside of the
> scope of the kernel itself (and thus not a "derived work" or anything like
> that), I have to convince myself that not only is it clearly ok to act on
> the knowledge of whather the kernel is signed or not, it's also outside of
> the scope of what the GPL talks about, and thus irrelevant to the license.
> 
> That's the short and sweet of it. I wanted to bring this out in the open, 
> because I know there are people who think that signed binaries are an act 
> of "subversion" (or "perversion") of the GPL, and I wanted to make sure 
> that people don't live under mis-apprehension that it can't be done.
> 
> I think there are many quite valid reasons to sign (and verify) your
> kernel images, and while some of the uses of signing are odious, I don't
> see any sane way to distinguish between "good" signers and "bad" signers.
> 
> Comments? I'd love to get some real discussion about this, but in the end 
> I'm personally convinced that we have to allow it.
> 
> Btw, one thing that is clearly _not_ allowed by the GPL is hiding private
> keys in the binary. You can sign the binary that is a result of the build
> process, but you can _not_ make a binary that is aware of certain keys
> without making those keys public - because those keys will obviously have
> been part of the kernel build itself.
> 
> So don't get these two things confused - one is an external key that is
> applied _to_ the kernel (ok, and outside the license), and the other one
> is embedding a key _into_ the kernel (still ok, but the GPL requires that
> such a key has to be made available as "source" to the kernel).
> 
> 			Linus
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 



^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  3:59 Linus Torvalds
  2003-04-24  4:40 ` Joel Jaeggli
@ 2003-04-24  4:43 ` Greg KH
  2003-04-24  4:57   ` Linus Torvalds
  2003-04-24  4:54 ` Andre Hedrick
                   ` (9 subsequent siblings)
  11 siblings, 1 reply; 130+ messages in thread
From: Greg KH @ 2003-04-24  4:43 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailing List

On Wed, Apr 23, 2003 at 08:59:45PM -0700, Linus Torvalds wrote:
> 
> Btw, one thing that is clearly _not_ allowed by the GPL is hiding private
> keys in the binary. You can sign the binary that is a result of the build
> process, but you can _not_ make a binary that is aware of certain keys
> without making those keys public - because those keys will obviously have
> been part of the kernel build itself.

The GPL does allow you to embed a public key in the kernel, which could
enforce only executables signed with a private key from being run, or
only signed modules from being loaded.  Both of which are things that I
know a lot of people want to do (and I've done in the past, see
http://linuxusb.bkbits.net:8080/cryptomark-2.4 for the 2.4 version of a
signed binaries are only allowed to run patch.)

I know a lot of people can (and do) object to such a potential use of
Linux, and I'm glad to see you explicitly state that this is an
acceptable use, it helps to clear up the issue.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 130+ messages in thread

* Re: Flame Linus to a crisp!
  2003-04-24  3:59 Linus Torvalds
@ 2003-04-24  4:40 ` Joel Jaeggli
  2003-04-24  4:43 ` Greg KH
                   ` (10 subsequent siblings)
  11 siblings, 0 replies; 130+ messages in thread
From: Joel Jaeggli @ 2003-04-24  4:40 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Kernel Mailing List

I'm not philosophically opposed to DRM systems. What I am concerned with
is being made a prisoner by my applications. So, if the kernel I run has
to be signed by the someone my proprietary application vendor trusts, so
that I can view a piece of data provided by a third party, that limits the 
freedom I have to choose what I put in my kernel. In some circumstances I 
might be willing to forgo that freedom, but as a general rule I see it as 
an unfortunate instrustion. 

Signatures for the purposes of establishing the identity of authors, and 
the intactness or binary or sources packages. are a seperate issue, 
I support that entirely...

joelja

On Wed, 23 Apr 2003, Linus 
Torvalds wrote:

> 
> Ok, 
>  there's no way to do this gracefully, so I won't even try. I'm going to 
> just hunker down for some really impressive extended flaming, and my 
> asbestos underwear is firmly in place, and extremely uncomfortable.
> 
>   I want to make it clear that DRM is perfectly ok with Linux!
> 
> There, I've said it. I'm out of the closet. So bring it on...
> 
> I've had some private discussions with various people about this already,
> and I do realize that a lot of people want to use the kernel in some way
> to just make DRM go away, at least as far as Linux is concerned. Either by
> some policy decision or by extending the GPL to just not allow it.
> 
> In some ways the discussion was very similar to some of the software
> patent related GPL-NG discussions from a year or so ago: "we don't like
> it, and we should change the license to make it not work somehow". 
> 
> And like the software patent issue, I also don't necessarily like DRM
> myself, but I still ended up feeling the same: I'm an "Oppenheimer", and I
> refuse to play politics with Linux, and I think you can use Linux for
> whatever you want to - which very much includes things I don't necessarily
> personally approve of.
> 
> The GPL requires you to give out sources to the kernel, but it doesn't
> limit what you can _do_ with the kernel. On the whole, this is just
> another example of why rms calls me "just an engineer" and thinks I have
> no ideals.
> 
> [ Personally, I see it as a virtue - trying to make the world a slightly
>   better place _without_ trying to impose your moral values on other 
>   people. You do whatever the h*ll rings your bell, I'm just an engineer 
>   who wants to make the best OS possible. ]
> 
> In short, it's perfectly ok to sign a kernel image - I do it myself
> indirectly every day through the kernel.org, as kernel.org will sign the
> tar-balls I upload to make sure people can at least verify that they came
> that way. Doing the same thing on the binary is no different: signing a
> binary is a perfectly fine way to show the world that you're the one
> behind it, and that _you_ trust it.
> 
> And since I can imaging signing binaries myself, I don't feel that I can
> disallow anybody else doing so.
> 
> Another part of the DRM discussion is the fact that signing is only the 
> first step: _acting_ on the fact whether a binary is signed or not (by 
> refusing to load it, for example, or by refusing to give it a secret key) 
> is required too.
> 
> But since the signature is pointless unless you _use_ it for something,
> and since the decision how to use the signature is clearly outside of the
> scope of the kernel itself (and thus not a "derived work" or anything like
> that), I have to convince myself that not only is it clearly ok to act on
> the knowledge of whather the kernel is signed or not, it's also outside of
> the scope of what the GPL talks about, and thus irrelevant to the license.
> 
> That's the short and sweet of it. I wanted to bring this out in the open, 
> because I know there are people who think that signed binaries are an act 
> of "subversion" (or "perversion") of the GPL, and I wanted to make sure 
> that people don't live under mis-apprehension that it can't be done.
> 
> I think there are many quite valid reasons to sign (and verify) your
> kernel images, and while some of the uses of signing are odious, I don't
> see any sane way to distinguish between "good" signers and "bad" signers.
> 
> Comments? I'd love to get some real discussion about this, but in the end 
> I'm personally convinced that we have to allow it.
> 
> Btw, one thing that is clearly _not_ allowed by the GPL is hiding private
> keys in the binary. You can sign the binary that is a result of the build
> process, but you can _not_ make a binary that is aware of certain keys
> without making those keys public - because those keys will obviously have
> been part of the kernel build itself.
> 
> So don't get these two things confused - one is an external key that is
> applied _to_ the kernel (ok, and outside the license), and the other one
> is embedding a key _into_ the kernel (still ok, but the GPL requires that
> such a key has to be made available as "source" to the kernel).
> 
> 			Linus
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-- 
-------------------------------------------------------------------------- 
Joel Jaeggli	      Academic User Services   joelja@darkwing.uoregon.edu    
--    PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E      --
  In Dr. Johnson's famous dictionary patriotism is defined as the last
  resort of the scoundrel.  With all due respect to an enlightened but
  inferior lexicographer I beg to submit that it is the first.
	   	            -- Ambrose Bierce, "The Devil's Dictionary"




^ permalink raw reply	[flat|nested] 130+ messages in thread

* Flame Linus to a crisp!
@ 2003-04-24  3:59 Linus Torvalds
  2003-04-24  4:40 ` Joel Jaeggli
                   ` (11 more replies)
  0 siblings, 12 replies; 130+ messages in thread
From: Linus Torvalds @ 2003-04-24  3:59 UTC (permalink / raw)
  To: Kernel Mailing List


Ok, 
 there's no way to do this gracefully, so I won't even try. I'm going to 
just hunker down for some really impressive extended flaming, and my 
asbestos underwear is firmly in place, and extremely uncomfortable.

  I want to make it clear that DRM is perfectly ok with Linux!

There, I've said it. I'm out of the closet. So bring it on...

I've had some private discussions with various people about this already,
and I do realize that a lot of people want to use the kernel in some way
to just make DRM go away, at least as far as Linux is concerned. Either by
some policy decision or by extending the GPL to just not allow it.

In some ways the discussion was very similar to some of the software
patent related GPL-NG discussions from a year or so ago: "we don't like
it, and we should change the license to make it not work somehow". 

And like the software patent issue, I also don't necessarily like DRM
myself, but I still ended up feeling the same: I'm an "Oppenheimer", and I
refuse to play politics with Linux, and I think you can use Linux for
whatever you want to - which very much includes things I don't necessarily
personally approve of.

The GPL requires you to give out sources to the kernel, but it doesn't
limit what you can _do_ with the kernel. On the whole, this is just
another example of why rms calls me "just an engineer" and thinks I have
no ideals.

[ Personally, I see it as a virtue - trying to make the world a slightly
  better place _without_ trying to impose your moral values on other 
  people. You do whatever the h*ll rings your bell, I'm just an engineer 
  who wants to make the best OS possible. ]

In short, it's perfectly ok to sign a kernel image - I do it myself
indirectly every day through the kernel.org, as kernel.org will sign the
tar-balls I upload to make sure people can at least verify that they came
that way. Doing the same thing on the binary is no different: signing a
binary is a perfectly fine way to show the world that you're the one
behind it, and that _you_ trust it.

And since I can imaging signing binaries myself, I don't feel that I can
disallow anybody else doing so.

Another part of the DRM discussion is the fact that signing is only the 
first step: _acting_ on the fact whether a binary is signed or not (by 
refusing to load it, for example, or by refusing to give it a secret key) 
is required too.

But since the signature is pointless unless you _use_ it for something,
and since the decision how to use the signature is clearly outside of the
scope of the kernel itself (and thus not a "derived work" or anything like
that), I have to convince myself that not only is it clearly ok to act on
the knowledge of whather the kernel is signed or not, it's also outside of
the scope of what the GPL talks about, and thus irrelevant to the license.

That's the short and sweet of it. I wanted to bring this out in the open, 
because I know there are people who think that signed binaries are an act 
of "subversion" (or "perversion") of the GPL, and I wanted to make sure 
that people don't live under mis-apprehension that it can't be done.

I think there are many quite valid reasons to sign (and verify) your
kernel images, and while some of the uses of signing are odious, I don't
see any sane way to distinguish between "good" signers and "bad" signers.

Comments? I'd love to get some real discussion about this, but in the end 
I'm personally convinced that we have to allow it.

Btw, one thing that is clearly _not_ allowed by the GPL is hiding private
keys in the binary. You can sign the binary that is a result of the build
process, but you can _not_ make a binary that is aware of certain keys
without making those keys public - because those keys will obviously have
been part of the kernel build itself.

So don't get these two things confused - one is an external key that is
applied _to_ the kernel (ok, and outside the license), and the other one
is embedding a key _into_ the kernel (still ok, but the GPL requires that
such a key has to be made available as "source" to the kernel).

			Linus


^ permalink raw reply	[flat|nested] 130+ messages in thread

end of thread, other threads:[~2003-04-28 14:19 UTC | newest]

Thread overview: 130+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20030424041004$113a@gated-at.bofh.it>
2003-04-24  4:53 ` Flame Linus to a crisp! Tony 'Nicoya' Mantler
2003-04-28  9:30 Martin_List-Petersen
  -- strict thread matches above, loose matches on Subject: below --
2003-04-25 12:57 Downing, Thomas
2003-04-25 12:41 Downing, Thomas
2003-04-25 12:36 Downing, Thomas
2003-04-27  7:25 ` Adrian Bunk
2003-04-25 12:23 Downing, Thomas
2003-04-24 22:10 Downing, Thomas
2003-04-24 22:36 ` Jamie Lokier
2003-04-24 21:55 Daniel Callahan
2003-04-24 20:39 Downing, Thomas
2003-04-24 21:28 ` Jamie Lokier
2003-04-24 21:42   ` Daniel Phillips
2003-04-24 22:45     ` Alan Cox
2003-04-24 23:59       ` Daniel Phillips
2003-04-25  9:07         ` Helge Hafting
2003-04-25 13:01       ` David Luyer
2003-04-25  8:13   ` Andreas Jellinghaus
2003-04-25 19:12     ` Jamie Lokier
2003-04-25 20:56       ` Andreas Jellinghaus
2003-04-25 21:50         ` Jamie Lokier
2003-04-24 12:36 Downing, Thomas
2003-04-24 14:12 ` Timothy Miller
2003-04-24 22:48   ` Werner Almesberger
2003-04-25 12:29   ` Ragnar Hojland Espinosa
2003-04-25 15:45     ` Timothy Miller
2003-04-24  3:59 Linus Torvalds
2003-04-24  4:40 ` Joel Jaeggli
2003-04-24  4:43 ` Greg KH
2003-04-24  4:57   ` Linus Torvalds
2003-04-24  5:02     ` Clemens Schwaighofer
2003-04-24  5:39       ` viro
2003-04-24  5:56         ` Valdis.Kletnieks
2003-04-24  8:46           ` Dax Kelson
2003-04-24  9:46         ` Clemens Schwaighofer
2003-04-24 10:54       ` Felipe Alfaro Solana
2003-04-25  0:07         ` Clemens Schwaighofer
2003-04-24  4:54 ` Andre Hedrick
2003-04-24  5:16   ` Linus Torvalds
2003-04-24 13:08     ` Shawn
2003-04-24 20:12       ` Kenneth Johansson
2003-04-24 17:32     ` Andreas Boman
2003-04-24 17:41       ` William Lee Irwin III
2003-04-24 19:39         ` Balram Adlakha
2003-04-26 17:05       ` Riley Williams
2003-04-24  5:02 ` Mark J Roberts
2003-04-24  5:13   ` Clemens Schwaighofer
2003-04-24  5:15 ` William Lee Irwin III
2003-04-24  5:43   ` Linus Torvalds
2003-04-24  6:15     ` William Lee Irwin III
2003-04-24  7:44       ` Jamie Lokier
2003-04-24  8:03         ` Jan-Benedict Glaw
2003-04-25  1:16           ` Jan Harkes
2003-04-25  1:35             ` Stan Bubrouski
2003-04-24  8:16         ` John Bradford
2003-04-24  8:31           ` Jamie Lokier
2003-04-24  8:59             ` John Bradford
2003-04-24  8:50           ` Jamie Lokier
2003-04-24 14:45           ` Linus Torvalds
2003-04-24 15:00             ` Jeff Garzik
2003-04-24 19:03             ` Daniel Phillips
2003-04-24 19:32               ` Timothy Miller
2003-04-24 19:22                 ` Linus Torvalds
2003-04-24 20:19                   ` Jamie Lokier
2003-04-24 20:35                   ` Timothy Miller
2003-04-24 19:39                 ` Balram Adlakha
2003-04-24 21:02                   ` Jamie Lokier
2003-04-24 18:58         ` Daniel Phillips
2003-04-24 21:08           ` Jamie Lokier
2003-04-24 21:37             ` Timothy Miller
2003-04-24 21:30               ` Jamie Lokier
2003-04-24 21:38                 ` John Bradford
2003-04-25  3:20                   ` Shawn
2003-04-25  5:47                     ` Jamie Lokier
2003-04-25  7:02                       ` John Bradford
2003-04-25  8:52                         ` Helge Hafting
2003-04-25 14:03                   ` Mike Dresser
2003-04-24 21:42                 ` Russell King
2003-04-25  6:08               ` Jan-Benedict Glaw
2003-04-25 11:46                 ` Antonio Vargas
2003-04-24 10:57     ` Giuliano Pochini
2003-04-24 22:51     ` Adrian Bunk
2003-04-24  7:55 ` Jamie Lokier
2003-04-24  8:37 ` Andreas Jellinghaus
2003-04-24  8:59   ` Jamie Lokier
2003-04-24 12:52     ` Andreas Jellinghaus
2003-04-24 15:37     ` Timothy Miller
2003-04-24 18:35       ` Alan Cox
2003-04-24 20:46         ` Timothy Miller
2003-04-24 20:50           ` Jamie Lokier
2003-04-24 21:03             ` Chris Adams
2003-04-24 22:29         ` Werner Almesberger
2003-04-24 22:41           ` Jamie Lokier
2003-04-24 22:54             ` Werner Almesberger
2003-04-25  0:26               ` Jamie Lokier
2003-04-24 22:41           ` Alan Cox
2003-04-27 14:21           ` Matthias Andree
2003-04-27 16:13             ` Stephan von Krawczynski
2003-04-24 19:23       ` Jamie Lokier
2003-04-24 19:50         ` Balram Adlakha
2003-04-24  8:57 ` Arjan van de Ven
2003-04-24  9:19   ` Russell King
2003-04-24 11:38     ` Shachar Shemesh
2003-04-24 17:46       ` Shachar Shemesh
2003-04-24 14:59   ` Linus Torvalds
2003-04-24 12:39 ` Mark Mielke
2003-04-24 15:53 ` Elladan
2003-04-24 18:31 ` Daniel Phillips
2003-04-24 23:15   ` Werner Almesberger
2003-04-25 11:28     ` Eric W. Biederman
2003-04-27  1:31       ` Werner Almesberger
2003-04-27  1:59         ` David Wagner
2003-04-25 14:37     ` Daniel Phillips
2003-04-25 15:17       ` Valdis.Kletnieks
2003-04-25 17:37       ` Werner Almesberger
2003-04-26 21:59         ` Daniel Phillips
2003-04-26 13:00     ` Geert Uytterhoeven
2003-04-26 18:22       ` Linus Torvalds
2003-04-26 18:41         ` viro
2003-04-26 18:48           ` Linus Torvalds
2003-04-28 14:20           ` John Stoffel
2003-04-26 19:23         ` Michael Buesch
2003-04-28 10:35         ` Andre Hedrick
2003-04-28 12:12           ` Jörn Engel
2003-04-28 14:01           ` Zack Gilburd
2003-04-28 14:30             ` Geert Uytterhoeven
2003-04-26 18:21   ` Rik van Riel
2003-04-26 23:34     ` Jamie Lokier
2003-04-27  3:59     ` Werner Almesberger
2003-04-24 20:16 ` Nils Holland

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).