Flame Linus to a crisp!

944 views
Skip to first unread message

Linus Torvalds

unread,
Apr 23, 2003, 11:59:51 PM4/23/03
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Greg KH

unread,
Apr 24, 2003, 12:42:11 AM4/24/03
to Linus Torvalds, 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

Joel Jaeggli

unread,
Apr 24, 2003, 12:46:22 AM4/24/03
to Linus Torvalds, 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

--
--------------------------------------------------------------------------
Joel Jaeggli Academic User Services joe...@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"

Tony 'Nicoya' Mantler

unread,
Apr 24, 2003, 12:54:41 AM4/24/03
to Linus Torvalds, linux-...@vger.kernel.org
In article <20030424041004$11...@gated-at.bofh.it>,
Linus Torvalds <torv...@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 - nic...@apia.dhs.org
Winnipeg, Manitoba, Canada -- http://nicoya.feline.pp.se/

Linus Torvalds

unread,
Apr 24, 2003, 12:58:06 AM4/24/03
to Greg KH, 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

Andre Hedrick

unread,
Apr 24, 2003, 12:59:17 AM4/24/03
to Linus Torvalds, 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.

Clemens Schwaighofer

unread,
Apr 24, 2003, 1:05:14 AM4/24/03
to Linus Torvalds, 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-----

Mark J Roberts

unread,
Apr 24, 2003, 1:05:54 AM4/24/03
to Linus Torvalds, Kernel Mailing List
Linus Torvalds:

> I want to make it clear that DRM is perfectly ok with Linux!

What specifically are you referring to?

Clemens Schwaighofer

unread,
Apr 24, 2003, 1:14:30 AM4/24/03
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
==========================================================

-

William Lee Irwin III

unread,
Apr 24, 2003, 1:17:15 AM4/24/03
to Linus Torvalds, 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

Linus Torvalds

unread,
Apr 24, 2003, 1:19:11 AM4/24/03
to Andre Hedrick, 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.

vi...@parcelfarce.linux.theplanet.co.uk

unread,
Apr 24, 2003, 1:41:01 AM4/24/03
to Clemens Schwaighofer, 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"?

Linus Torvalds

unread,
Apr 24, 2003, 1:44:02 AM4/24/03
to William Lee Irwin III, 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

Valdis.K...@vt.edu

unread,
Apr 24, 2003, 1:58:33 AM4/24/03
to vi...@parcelfarce.linux.theplanet.co.uk, Clemens Schwaighofer, Linus Torvalds, Kernel Mailing List
On Thu, 24 Apr 2003 06:39:50 BST, vi...@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.

William Lee Irwin III

unread,
Apr 24, 2003, 2:18:05 AM4/24/03
to Linus Torvalds, 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

Jamie Lokier

unread,
Apr 24, 2003, 3:45:30 AM4/24/03
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

Jamie Lokier

unread,
Apr 24, 2003, 3:56:39 AM4/24/03
to Linus Torvalds, 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

Jan-Benedict Glaw

unread,
Apr 24, 2003, 4:04:40 AM4/24/03
to Kernel Mailing List
On Thu, 2003-04-24 08:44:00 +0100, Jamie Lokier <ja...@shareable.org>

wrote in message <20030424074...@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 jbg...@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));

John Bradford

unread,
Apr 24, 2003, 4:14:36 AM4/24/03
to Jamie Lokier, 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.

Jamie Lokier

unread,
Apr 24, 2003, 4:32:53 AM4/24/03
to John Bradford, 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

Andreas Jellinghaus

unread,
Apr 24, 2003, 4:38:22 AM4/24/03
to linux-...@vger.kernel.org
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

Dax Kelson

unread,
Apr 24, 2003, 4:47:29 AM4/24/03
to Valdis.K...@vt.edu, vi...@parcelfarce.linux.theplanet.co.uk, Clemens Schwaighofer, Linus Torvalds, Kernel Mailing List
On Thu, 24 Apr 2003 Valdis.K...@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

Jamie Lokier

unread,
Apr 24, 2003, 4:51:51 AM4/24/03
to John Bradford, 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

John Bradford

unread,
Apr 24, 2003, 4:57:08 AM4/24/03
to Jamie Lokier, 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.

Arjan van de Ven

unread,
Apr 24, 2003, 4:58:31 AM4/24/03
to Linus Torvalds, Kernel Mailing List
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.

signature.asc

Jamie Lokier

unread,
Apr 24, 2003, 5:00:10 AM4/24/03
to Andreas Jellinghaus, linux-...@vger.kernel.org
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

Russell King

unread,
Apr 24, 2003, 5:21:25 AM4/24/03
to Arjan van de Ven, 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 (r...@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html

Clemens Schwaighofer

unread,
Apr 24, 2003, 5:47:56 AM4/24/03
to vi...@parcelfarce.linux.theplanet.co.uk, Linus Torvalds, Kernel Mailing List
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

vi...@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-----

Felipe Alfaro Solana

unread,
Apr 24, 2003, 6:55:15 AM4/24/03
to Clemens Schwaighofer, 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

Giuliano Pochini

unread,
Apr 24, 2003, 6:58:08 AM4/24/03
to Linus Torvalds, 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.

Shachar Shemesh

unread,
Apr 24, 2003, 7:40:39 AM4/24/03
to Russell King, 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/

Mark Mielke

unread,
Apr 24, 2003, 8:33:35 AM4/24/03
to Linus Torvalds, 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...)

--
ma...@mielke.cc/ma...@ncf.ca/ma...@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/

Downing, Thomas

unread,
Apr 24, 2003, 8:37:46 AM4/24/03
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.

Andreas Jellinghaus

unread,
Apr 24, 2003, 8:48:47 AM4/24/03
to Jamie Lokier, linux-...@vger.kernel.org
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

Timothy Miller

unread,
Apr 24, 2003, 9:56:32 AM4/24/03
to Downing, Thomas, 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.

Shawn

unread,
Apr 24, 2003, 10:08:59 AM4/24/03
to Linus Torvalds, 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

Linus Torvalds

unread,
Apr 24, 2003, 10:45:23 AM4/24/03
to John Bradford, 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

Linus Torvalds

unread,
Apr 24, 2003, 11:00:07 AM4/24/03
to Arjan van de Ven, 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.

Jeff Garzik

unread,
Apr 24, 2003, 11:01:19 AM4/24/03
to Linus Torvalds, 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

Timothy Miller

unread,
Apr 24, 2003, 11:21:27 AM4/24/03
to Jamie Lokier, Andreas Jellinghaus, linux-...@vger.kernel.org

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.

Elladan

unread,
Apr 24, 2003, 11:54:53 AM4/24/03
to Linus Torvalds, 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

William Lee Irwin III

unread,
Apr 24, 2003, 1:42:21 PM4/24/03
to Andreas Boman, 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

Shachar Shemesh

unread,
Apr 24, 2003, 1:47:33 PM4/24/03
to Kernel Mailing List, 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".

Timothy Miller

unread,
Apr 24, 2003, 3:16:24 PM4/24/03
to Daniel Phillips, 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. :)

Linus Torvalds

unread,
Apr 24, 2003, 3:24:44 PM4/24/03
to Timothy Miller, 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

Jamie Lokier

unread,
Apr 24, 2003, 3:25:08 PM4/24/03
to Timothy Miller, Andreas Jellinghaus, linux-...@vger.kernel.org
> >>> 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

Alan Cox

unread,
Apr 24, 2003, 3:36:33 PM4/24/03
to Timothy Miller, 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

Balram Adlakha

unread,
Apr 24, 2003, 3:41:37 PM4/24/03
to linux-...@vger.kernel.org
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 :(

Balram Adlakha

unread,
Apr 24, 2003, 3:42:01 PM4/24/03
to linux-...@vger.kernel.org
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?

Balram Adlakha

unread,
Apr 24, 2003, 3:52:38 PM4/24/03
to Jamie Lokier, linux-...@vger.kernel.org

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

Kenneth Johansson

unread,
Apr 24, 2003, 4:13:13 PM4/24/03
to Shawn, 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 :)

Nils Holland

unread,
Apr 24, 2003, 4:17:44 PM4/24/03
to Linus Torvalds, 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 <ni...@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

Timothy Miller

unread,
Apr 24, 2003, 4:20:45 PM4/24/03
to Linus Torvalds, 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.

Jamie Lokier

unread,
Apr 24, 2003, 4:21:08 PM4/24/03
to Linus Torvalds, 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

Timothy Miller

unread,
Apr 24, 2003, 4:30:58 PM4/24/03
to Alan Cox, 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. :)

Downing, Thomas

unread,
Apr 24, 2003, 4:40:13 PM4/24/03