Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Flame Linus to a crisp!
Original-Message-ID: <Pine.LNX.4.44.0304232012400.19176-100000@home.transmeta.com>
Date: Thu, 24 Apr 2003 03:59:51 GMT
Message-ID: <fa.l5spn1v.1k1q2pp@ifi.uio.no>

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 whether 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

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: Flame Linus to a crisp!
Original-Message-ID: <Pine.LNX.4.44.0304232146020.19326-100000@home.transmeta.com>
Date: Thu, 24 Apr 2003 04:58:06 GMT
Message-ID: <fa.l3svo9u.1m1s31o@ifi.uio.no>

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

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: Flame Linus to a crisp!
Original-Message-ID: <Pine.LNX.4.44.0304232204480.19326-100000@home.transmeta.com>
Date: Thu, 24 Apr 2003 05:19:11 GMT
Message-ID: <fa.l5tdn9s.1k1e21q@ifi.uio.no>

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

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: Flame Linus to a crisp!
Original-Message-ID: <Pine.LNX.4.44.0304232217550.19326-100000@home.transmeta.com>
Date: Thu, 24 Apr 2003 05:44:02 GMT
Message-ID: <fa.l6d7nhv.1khk29p@ifi.uio.no>

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 scenarios, you might have a machine that works as a regular
PC, but the satellite company requires that only kernels _it_ trusts get
to unscramble 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 something 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

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: Flame Linus to a crisp!
Original-Message-ID: <Pine.LNX.4.44.0304240741530.20549-100000@home.transmeta.com>
Date: Thu, 24 Apr 2003 14:45:23 GMT
Message-ID: <fa.l7crops.1jh02hu@ifi.uio.no>

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

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: Flame Linus to a crisp!
Original-Message-ID: <Pine.LNX.4.44.0304240745531.20549-100000@home.transmeta.com>
Date: Thu, 24 Apr 2003 15:00:07 GMT
Message-ID: <fa.l7crp20.1jh02pq@ifi.uio.no>

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

Newsgroups: fa.linux.kernel
From: torvalds@transmeta.com (Linus Torvalds)
Subject: Re: Flame Linus to a crisp!
Original-Message-ID: <b8eipq$fpk$1@penguin.transmeta.com>
Date: Sat, 26 Apr 2003 18:24:03 GMT
Message-ID: <fa.k62c0rg.fns7om@ifi.uio.no>

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_ to 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