Flame Linus to a crisp!
Linus Torvalds
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
>
> 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
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
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
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
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
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
> I want to make it clear that DRM is perfectly ok with Linux!
What specifically are you referring to?
Clemens Schwaighofer
> 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
> 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
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
> 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
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
> 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
> 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
> 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
[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
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.
>
> 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
> > 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.
>
> 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
> 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
> I want to make it clear that DRM is perfectly ok with Linux!
thanks for such a clear statement.
Andreas
Dax Kelson
> 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
> > 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
> > 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
>
> 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.
Jamie Lokier
> 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
> 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
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
> > 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
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
>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
> I want to make it clear that DRM is perfectly ok with Linux!
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...
Downing, Thomas
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
> 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
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
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
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
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
> 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
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
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
> 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
> 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
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
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
> >>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
> 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
> 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
> 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
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
> 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
> 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
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
> > 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
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
From: Daniel Phillips [mailto:phil...@arcor.de]
> To join a game, you'd have to be able to prove you're running code that is
> secure all the way from boot to reboot, where everything from network
driver
> to physics engine is known to be compiled from open source that all
> participants agree is good.
How would you do that? What's the protocol?
Jamie Lokier
> Certainly. But say the GPL allows it, and say Linus decides he wants
> it. There's nothing stopping someone else from forking it and deciding
> they'll never accept any DRM-related code into their fork.
True but if the GPL allows, nobody could prevent their fork becoming
the heart of a DRM-locked product, either.
I wonder whether the FSF shouldn't fork the GPLv3 into two versions,
according to what philosophy GPLv2 users would like to adopt for their
own projects :) (In principle, only the FSF is able to alter the
license of a many-authored GPL'd project like Linux. It would be
unfortunate if they used that special status to promote an agenda
which a large number existing GPL users disliked).
-- Jamie
Jamie Lokier
> By the way, I'm just curious, I don't have much knowledge of this,
> can anyone create a processor with the x86 instruction set and sell
> it? Like did AMD and transmeta and all get a license from Intel?
Please, somebody answer this question. The good folks at Transmeta
should know the answer.
I'm really intersted as I want to do exactly this eventually.
Perhaps the constraints are different when software binary translation
is used? I.e. I could sell a non-x86 cpu and give away an x86
translator without needing a license from Intel, presumably?
-- Jamie
Chris Adams
>I wonder whether the FSF shouldn't fork the GPLv3 into two versions,
>according to what philosophy GPLv2 users would like to adopt for their
>own projects :) (In principle, only the FSF is able to alter the
>license of a many-authored GPL'd project like Linux. It would be
>unfortunate if they used that special status to promote an agenda
>which a large number existing GPL users disliked).
They can't affect the license of Linux because COPYING included with the
kernel says:
Also note that the only valid version of the GPL as far as the kernel
is concerned is _this_ particular version of the license (ie v2, not
v2.2 or v3.x or whatever), unless explicitly otherwise stated.
Now, IIRC, that paragraph was added after the fact, so someone could go
back to a version before that paragraph and fork under a new version of
the GPL, however they could not take any code from the current versions
of the kernel.
About 20% of the files in the kernel include the "at your option" clause
(this is from looking at the source to RH's 2.4.20-8).
--
Chris Adams <cma...@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
Jamie Lokier
> On Thu 24 Apr 03 09:44, Jamie Lokier wrote:
> > It only gets _really_ bad when it becomes illegal to make your own
> > hardware :(
>
> Actually, that's where we were a few years ago with hardware, because nearly
> anything anybody would want to print on a wafer was covered by patents or
> copyrights. It's getting better by leaps and bounds. Now, a lot of patents
> have expired, a lot of non-proprietary cores are available, and it's mainly
> the EDM tools that are non-free. That's where we coders can help.
Suppose I did want to print some wafers.
Suppose, also, that I had developed a method that didn't require a
$10M+ factory.
(Also suppose I had _very_ steady hands, no dandruff, and my garden
shed was big enough :)
I'm curious - how do I go about learning what I do and don't need
patent licenses for making chips, without spending an absurd sum on
legal fees?
-- Jamie
Timothy Miller
Jamie Lokier wrote:
>
>
>Suppose I did want to print some wafers.
>
>Suppose, also, that I had developed a method that didn't require a
>$10M+ factory.
>
>(Also suppose I had _very_ steady hands, no dandruff, and my garden
>shed was big enough :)
>
>I'm curious - how do I go about learning what I do and don't need
>patent licenses for making chips, without spending an absurd sum on
>legal fees?
>
We could always consider wiring everything up with discrete logic.
Anyone got any spare 74138's?
Jamie Lokier
> From: Daniel Phillips [mailto:phil...@arcor.de]
> > To join a game, you'd have to be able to prove you're running code
> > that is secure all the way from boot to reboot, where everything
> > from network driver to physics engine is known to be compiled from
> > open source that all participants agree is good.
>
> How would you do that? What's the protocol?
Public key exchange lets you communicate securely over an insecure link.
So, the game server and the BIOS have a chat, through the operating
system (which counts as an insecure link), and the BIOS tells the
server that it is the correct DRM BIOS, and it loaded a signed kernel.
So the server can trust the kernel. It chats with the kernel, which
confirms that it is running a signed physics engine, a signed 3rd party
network driver, a signed video driver, the video is connected to a
signed monitor, the input is connected to a signed joystick, and that
conversations on TCP port XXX are connected to the physics engine.
This is how a game server can verify it is working with a known game
client and the client is connected to a known type of monitor and
input device. I.e. it can verify there is no electronic frame grabber
using the video signals and driving an AI assist through the input
device.
Additionally, the trusted kernel and trusted video driver can prove
that they are encrypting the video link, so that it is imposible to
record the gameplay using standard video recording hardware.
---
Substitute "broadcaster" for "game server" and you see that the same
methods ensure that you really have the TV switched on and you are not
recording the show.
They also ensure you are not recording a screenshot of a politically
sensitive article about Iraq that was accidentally shown on CNN's web
site for 10 minutes. We can't have people recording things like that.
Also that day, that same article doesn't load from Al-Jazeera or
anywhere else, on the PC you bought from the only affordable store in
town. Is the net flaky today, or is somebody remote-controlling your
PC to control your "browsing experience"?
-- Jamie
Jamie Lokier
> We could always consider wiring everything up with discrete logic.
> Anyone got any spare 74138's?
I need 1 billion of them please, and I need the overclockable ones :)
-- Jamie
John Bradford
> > Anyone got any spare 74138's?
>
> I need 1 billion of them please, and I need the overclockable ones :)
Why not just buy one of those 100-in-1 electronics kits from your
local electonics hobbyist store, and make your very own wire wrap CPU?
John.
Russell King
> Timothy Miller wrote:
> > We could always consider wiring everything up with discrete logic.
> > Anyone got any spare 74138's?
>
> I need 1 billion of them please, and I need the overclockable ones :)
Ah, you want the 74AC138 version then for fast propagation.
(3 to 8 line decoders/demultiplexers don't have a clock input, so
"overclockable ones" is rather meaningless.) 8)
Is it just me or are we wandering off topic here?
--
Russell King (r...@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Daniel Callahan
On 24-Apr-2003 Giuliano Pochini wrote:
Free software is free. You can do anything with it, the only contraint
is it must stay free. But cryptography plays a bad role here. Someone
can make hw that accepts only that peice of signed free software. You
have the hw, you have the binaries, you have the sources. But the
sources are completely useless. GPL allows the user to modify it, but
the hw doesn't run the modified copy. DRM can turns free software into
half-proprietary software. I don't like it at all, but I don't see any
solution.
----
The solution lies outside of the GPL. Not that you're guilty of this, but
somehow hackerdom has mixed the GPL in with 'the Right to free binaries' and
'the Right to have compatible hardware'. And those two Rights are as real as
the brontosaurus, (i.e., they ain't, despite what many want to believe).
Free binaries and compatible hardware are privileges. In the case of
hardware, that's a damn shame, but there it is. Apart from mutilating the
GPL to outlaw development on secured hardware, I can't see the solution
coming from that direction. (And even if GPL were modified to cover
"activities other than copying, distribution and modification", all it would
do is fork the license. Linus would use the older license (I'm guessing),
others would use the anti-DRM license, and Bill Gates would be ROTFLHAO.)
So there's no solution except to learn to live with it *unless* someone is
brave and savvy enough to create a General Hardware License and found the
Free Hardware Foundation. And that still wouldn't make the DRM issue vanish
-- GNU didn't wipe out proprietary software; it didn't even prevent the Mac
from using FreeBSD. It would just create the opportunity for a hardware
hacker to do what has been done with Linux.
So, if anyone really is waiting for a sign to start the Free Hardware
Foundation, consider Linus' email to be it.
Daniel.
Downing, Thomas
> > To join a game, you'd have to be able to prove you're running code
> > that is secure all the way from boot to reboot, where everything
> > from network driver to physics engine is known to be compiled from
> > open source that all participants agree is good.
>
> How would you do that? What's the protocol?
Public key exchange lets you communicate securely over an insecure link.
> So, the game server and the BIOS have a chat, through the operating
> system (which counts as an insecure link), and the BIOS tells the
> server that it is the correct DRM BIOS, and it loaded a signed kernel.
How does the server _know_ that the BIOS is what it says it is? Again,
what's the protocol? Saying that they 'have a chat' is bypassing
the hard bits.
If I have the BIOS, any secrets it holds are now knowable to me.
This means that any protocol that relies on a secret in the BIOS is
broken from the start. So now you need to define a protocol which
does not rely on any secret being known to the BIOS. What is this
protocol?
> Substitute "broadcaster" for "game server" and you see that the same
? methods ensure that you really have the TV switched on and you are not
> recording the show.
The proposed 'end-to-end' copy protection schemes for entertainment
media etc, rely on proprietary _hardware_. This is still beatable,
although at a higher cost. Nor is the problem quite parallel. The
broadcast problem is 'how do we keep content encrypted till the
last possible moment?' and 'how do we keep the decryption engine tamper
proof reverse engineering proof'. The first part is easy. The second
part is not possible in an absolute sense. It can only be made more
or less dificult. Hence the DMCA etc.
> They also ensure you are not recording a screenshot of a politically
> sensitive article about Iraq that was accidentally shown on CNN's web
> site for 10 minutes. We can't have people recording things like that.
God forbid! ;-)
Werner Almesberger
> Either its allowed by the GPL or its not.
A more important barrier than what the GPL allows might be what the
Linux community accepts. If some DRM extensions are never accepted
by enough of the "mainstream", they will fail to work.
The main problem I see with accepting DRM functionality is that it
will encourage frivolous uses of DRM, just because it's possible
then. Just like most vendors instinctively default to closed
source.
It's also worth to keep in mind that such decisions are frequently
taken by people with very different agendas, e.g. if "protected by
DRM" is perceived to appeal to analysts, shareholders or potential
shareholders, it may quickly become policy in many companies, just
like patents did.
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina w...@almesberger.net /
/_http://www.almesberger.net/____________________________________________/
Jamie Lokier
> How does the server _know_ that the BIOS is what it says it is? Again,
> what's the protocol? Saying that they 'have a chat' is bypassing
> the hard bits.
>
> If I have the BIOS, any secrets it holds are now knowable to me.
> This means that any protocol that relies on a secret in the BIOS is
> broken from the start. So now you need to define a protocol which
> does not rely on any secret being known to the BIOS. What is this
> protocol?
What makes you think you can read the BIOS?
> The proposed 'end-to-end' copy protection schemes for entertainment
> media etc, rely on proprietary _hardware_.
Yes, that's the severe version of DRM that we're talking about, for
the game server scenario.
> This is still beatable, although at a higher cost. Nor is the
> problem quite parallel. The broadcast problem is 'how do we keep
> content encrypted till the last possible moment?' and 'how do we
> keep the decryption engine tamper proof reverse engineering proof'.
> The first part is easy. The second part is not possible in an
> absolute sense. It can only be made more or less dificult. Hence
> the DMCA etc.
We don't know for sure that it's not possible to make something
reverse engineering proof. Although all current CPUs require code to
be decrypted at some point, there may be modules of computation that
don't require that, so there would be no way to extract the secret key
or decryption process in a useful way even when you can see every
electronic signal in a device. The jury is out on it, despite what
slashdotters believe.
-- Jamie
Jamie Lokier
> Just like most vendors instinctively default to closed source.
Quite. Businesses instinctively do what they believe is in their best
interests, and sometimes it is important to have constraints which
cause businesses to function in our mutual best interest, which
businesses are often not well placed to perceive.
> It's also worth to keep in mind that such decisions are frequently
> taken by people with very different agendas, e.g. if "protected by
> DRM" is perceived to appeal to analysts, shareholders or potential
> shareholders, it may quickly become policy in many companies, just
> like patents did.
In this regard, analysts, shareholders, consumers etc. are just like
business, acting in their own percieved best interest.
Change the rules against the status quo and they all complain, but it
is just change and they also all adapt to it. That is business too.
-- Jamie
Werner Almesberger
> One of the things that we could do to accelerate the adoption of Linux
> is to support DRM.
As long as adoption of Linux is the only thing you care about in
the world, that logic certainly works.
> Yes, we know it's evil, but if we are the ones
> developing it, at least we know what it is and is not doing and how it
> works.
You forgot
"Yes, we know it's evil, but if we are the ones developing it, we
can at least be sure that it will be done properly."
as in
"Yes, officer, I know that I shouldn't drive after drinking that
bottle of whisky, but I had to get home, and I'm a good driver
who can handle this."
and
"Yes, we know it's evil, but if we don't develop it, somebody else
will."
as in
"Yes, officer, I know that I shouldn't have parked here, but if
I hadn't, somebody else would have."
(In the end, I don't think it helps to think of your actions in terms
of "good" or "evil". I find it much more important to consider the
possible consequences, direct and indirect.)
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina w...@almesberger.net /
/_http://www.almesberger.net/____________________________________________/
Adrian Bunk
>...
> And hey, the fact is (at least as far as I'm concerned), that as long as
> you make the hardware, you can control what it runs.
>...
Linux is currently widely used and through this there comes some power.
Let me try to make examples where this might be important:
Fact is:
Cryptographic hardware isn't science fiction. It's not an unsolvable
technical problem to build a computer and to ensure that only
$signed_kernel with $binary_only_module loaded and no other modules
loaded runs on this computer.
Two examples that might make it very important whether the licence of
Linux allows things like:
1. all the companies participating in TCPA agree that only selected
signed kernels run on future hardware
2. [less likely] a big country like the USA makes a law that every OS
must include a backdoor that allows unnoticed access for the NSA (it
sounds strange but considering the DMCA and current legislative
proposals in the USA I wouldn't say this is completely impossible)
That's the point where the fact that Linux is used in many companies
including big ones becomes important:
For companies it wouldn't be a big problem to use only signed kernels in
a scenario like the first one above (because of support rules of
companies like Oracle or SAP they are already often tied to some
specific kernels) if the licence of Linux allows it.
If the licence of Linux doesn't allow this it would make many of the big
companies using Linux to opposers of such a proposal.
> Linus
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Werner Almesberger
> Change the rules against the status quo and they all complain, but it
> is just change and they also all adapt to it. That is business too.
In some cases, they show remarkable reluctance to embrace change,
though. Just consider the enthusiastic response of RIAA, MPAA, etc.
to how the Internet has improved everybody's ability to distribute
information.
Anyway, the question is then what the current trends are. As Linus
has pointed out, there are desirable and there are undesirable
uses of DRM. If endorsing DRM will just get us flooded with the
undesirable ones, plus an insignificant number of the desirable
ones, we'll have made a lousy deal.
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina w...@almesberger.net /
/_http://www.almesberger.net/____________________________________________/
Werner Almesberger
> Open source + Linux + DRM could be used to solve the Quake client-side
> cheating problem:
Yes, but in return you'd be excluded from playing Quake unless
you're running one of those signed kernels or modules.
So, if I, say, want to test some TCP fix, new VM feature, file
system improvement, etc., none of the applications that rely on
DRM would work. This doesn't only affect developers, but also
their potential testers.
Given that most users will just run a distribution's kernel, with
all the right signatures, companies will not perceive the few
cases in which their use of DRM causes problems as very important,
so they will use DRM.
Oh, maybe some developers could be granted the privilege of being
able to sign their own kernels or modules. So if you're part of
this circle, you'd be fine, right ? No, even this doesn't work,
because if you'd leak such a key, you'd certainly get sued for
damages. And I don't think many people would feel overly pleased
with the idea of being responsible for the safekeeping of the key
to a multi-million lawsuit. (And besides, this may turn them into
targets for key theft/robbery/extortion.)
(There are of course uses of such signatures that would not have
those problems. E.g. signatures that prove trustworthiness to the
local user, instead of a remote party.)
E. Jason Scheck
Werner Almesberger <w...@almesberger.net> wrote:
>Alan Cox wrote:
>> Either its allowed by the GPL or its not.
>
>A more important barrier than what the GPL allows might be what the
>Linux community accepts. If some DRM extensions are never accepted
>by enough of the "mainstream", they will fail to work.
Perhaps someone could show me the flaw in my reasoning below (much
like the algebraic proofs that end in "15 == 16", where there was
a hidden division-by-zero somewhere in the middle)...
1) Linux sources are covered by the GPL.
2) A binary produced from Linux sources is a derived work (pretty
much by definition, since the relationship is nearly 1->1), and
therefore is bound by the GPL.
3) If I add a source file to the Linux sources in a private language,
then I must make the compiler for that language available (but
must the compiler then be GPL)?
4) A signature that is generated from the Linux binary kernel is a
derived work of the binary. (Is it not, the signature could
surely not exist without the binary, and changes every time
the binary changes?)
5) The key used to generate the signature (as well as the tool used
to generate it) is also a derivative work of the binary of the
kernel, and so should then be covered.
No doubt most on this list have heard the folklore of the reasoning behind
RMS creating the GPL. "Legend" has it that RMS was using a printer that had
a bug, and he was frustrated that he was unable to fix the bug. If that
printer were running a DRM-restricted, signed copy of Linux, he still would
be unable to fix the bug. (Similar to, say, a TiVo...).
Jason
Alan Cox
> It's also worth to keep in mind that such decisions are frequently
> taken by people with very different agendas, e.g. if "protected by
> DRM" is perceived to appeal to analysts, shareholders or potential
> shareholders, it may quickly become policy in many companies, just
> like patents did.
Abusing DRM is a direct economic winner for anyone who does, thats
precisely the problem. Its also an economic loss for everyone who
isn't able to abuse it. The latter tend to be have less influence
with the US government.
With DRM the music industry can prevent artists from doing independant
publishing by making the case that "unprotected music is pirate" and
"mandating only signed music can be played". Without it they are doomed
not because of piracy but because they are less efficient than the
alternatives - to many bands less efficient right now than giving the
stuff away.
Alan Cox
> A more mundane goal would be to prevent the 3D driver from letting you see
> through polygons that are supposed to be opaque.
In the MUD world we solved that by not telling anyone about objects they
can't see.
Clemens Schwaighofer
Hash: SHA1
Felipe Alfaro Solana wrote:
> On Thu, 2003-04-24 at 07:02, Clemens Schwaighofer wrote:
>
> Can I trust you? Uhmm... Are you really Clemens? Please, prove it with
> this simply challenge: what was the kernel version that first introduced
> explicit return codes in drivers for stating that an IRQ was handled?
> ;-)
I am Clemens, because I really don't know these important details :D
> All of this DRM stuff gives me headaches.
I think it give all thinking people headache, doesn't it? Especially
when you see why it should be used. To control everybody. No wonder they
keep the education budged low in ALL countries around the world ...
panem et circences
- --
Clemens Schwaighofer - IT Engineer & System Administration
==========================================================
Tequila Japan, 6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN
Tel: +81-(0)3-3545-7703 Fax: +81-(0)3-3545-7343
http://www.tequila.jp
==========================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE+qHxOjBz/yQjBxz8RAleaAJ9E0J4kqRrhlij6zNu/GMw/xA0xMQCfYBZ5
Ht8vluzC8L8EiM2XZmOzZUk=
=pLkV
-----END PGP SIGNATURE-----
Jamie Lokier
> > Change the rules against the status quo and they all complain, but it
> > is just change and they also all adapt to it. That is business too.
>
> In some cases, they show remarkable reluctance to embrace change,
> though. Just consider the enthusiastic response of RIAA, MPAA, etc.
> to how the Internet has improved everybody's ability to distribute
> information.
IMHO the RIAA and MPAA are playing their role perfectly. While they
_may_ represent pure greed, that greed produces things - mass market
music and films, mass market "stardom" to believe in and follow - that
large numbers of people still want, even though there are plenty of
readily available alternatives.
So long as people want the things that RIAA and MPAA are involved in
creating, but do not want to pay for it, _and_ for the most part just
want to copy because they enjoy saving money, rather than really
thinking through how to create a better, fluffier world, with
sustainable economics in a new form, then the RIAA and MPAA _must_ do
what they do - a role is created, and they fulfil it.
Just ignore the RIAA and MPAA, and listen/watch other stuff.
There's plenty of it. And support the creators of stuff you like.
If only a few people do that, they may end up stuck in paid-for laws.
If a lot of people do it, though, problem solved.
IMVHO of course :)
-- Jamie
Jan Harkes
> On Thu, 2003-04-24 08:44:00 +0100, Jamie Lokier <ja...@shareable.org>
> wrote in message <20030424074...@mail.jlokier.co.uk>:
> > It only gets _really_ bad when it becomes illegal to make your own
> > hardware :(
>
> something called "Super-DMCA" which prevents you (beside other things) to
> build up "systems" that could scrambl/encrypt sounds for pretected
> transmission (think VoIP over ssh or something like that in hardware).
If is really is that generic, it would be the final blow to copyright
protection. As it also makes it illegal to scramble satellite feeds,
pay-only cable tv, or add DRM to music files that are to be distributed
across the internet. I haven't read the Super-DMCA, but that
interpretation doesn't sound right.
What bothers me about DRM schemes is that they typically only protect
the rights of one party. Copyrights provided temporary protection under
law, what happens when the copyright expires? What happens when congress
tags another 30 years to the lifetime of the copyright, and if I move to
or go on holiday to another country that has a different copyright
expiration date.
Are companies required to provide me (as legal owner) of a new copy/CD
when my harddrive breaks, as the new harddrive will probably change the
'trusted' signature of my 'legal playback device'. What if I buy a new
computer/player, and all my licensed applications have to be resigned?
Jan
Stan Bubrouski
> Are companies required to provide me (as legal owner) of a new copy/CD
> when my harddrive breaks, as the new harddrive will probably change the
> 'trusted' signature of my 'legal playback device'. What if I buy a new
> computer/player, and all my licensed applications have to be resigned?
>
Yeah seriously...there are so many issues with DRM that are not clear
cut and have yet to be worked out properly. Competing ideas with
completely different strategies does not bode well with me. As a
consumer the idea is absurd until something stable, legal, AND FAIR is
implemented. Until then I don't even want to see this issue again
on this list because it is moot. How many DRM prodcts support Linux or
even plan to...yeah...most of them are win32 and have no plans for
even Macs nevermind Linux...
-Stan
Shawn
school digital electronics type stuff looked bad...
Joseph Pingenot
Trusted Computing Platform Association's website, and it has had me
thinking.
I believe that, if there were ever a DRM implementation to be trusted, it
would have to be Free Software. For example, look at Microsoft's
source code access program for governments. You may look, but not touch,
may not discuss, and especially may not compile.
Yay. Now, how exactly can we even *begin* trusting that the code we *saw*
was the code we're *running*?!
In Free Software, it's transparent; what you see *is* indeed what you get.
No hidden gimmicks or surprises (unless Richie did your C compiler. ;)
It should be noted that we need to talk about two *separate* issues:
Digial Rights Management, and Trusted Computing. As a quick executive
overview, I believe that Digital Rights Management, if implemented,
should be handled in the programming equivalent of a full environmental
suit--much, much harm can come from it. Unfortunately, given the
direction music and movie labels here in the 'States (which, unfortunately,
counts for at least the very large majority of the movies and music seen/
heard at leat in the 'States and in Europe, in my experience). Thus,
it is somewhat forced upon us, and we should have an optional(!)
implementation of it, so that we can continue to interact with the
complacent world.
Trusted Computing, on the other hand, holds a wealth of security enhancement
possiblities for the educated user and for the enterprise, and should
most definitely be embraced, although the non-toxic/carcinogenic
equivalent of programming asbestos should be used, as it also carries with
it the danger of abuse. We *absolutely* need to get full disclosure on
the hardware, and need to sit in on the industry steering committees, e.g.
TCPA. See also my Linux-NG posting at http://lists.debian.org/debian-devel/2002/debian-devel-200212/msg01719.html
(the big section on security torwards the end) for some of what I'd like
to see/implement.
DRM:
I am extremely cautious about Digital Rights Management. Although there is
a little good to be extracted from it (for instance, the ability to make
sure that people can't revise a document one's written); there is much,
much more harm in it. The most obvious of these is the removal of the
fair use rights (although not law, fair use ought to be!). It is
extremely possible and plausible to have DRM or software under the guise
of DRM deny you the right to make a backup copy, change format, or even
select a different player or create your own player! I'm sure we're all
familiar with the Content Scrambling System, yes?
That said, it is somewhat inevitable at this time. The MPAA, RIAA, and
others are forcing it down our throats at the CD and movie stores. Yes,
it can usually be broken, but that's a) illegal in the States, and
b) just a workaround. We should concentrate on elevating bit players to
the foreground, and try to avoid putting any more money in the MPAA/RIAA/
whoever coffers. That's the long-term solution; promote business that
doesn't try to screw us over (as much). I know it's hard; I like to buy
DVDs and CDs too. In fact, I feel like a hypocrite, 'cause I will most
definitely be purchasing CDs and DVDs in the future. *sigh* Any
suggestions on how to not support them (legally!) would be most welcome.
Trusted Computing:
There is actually quite a bit of good that I can see coming from trusted
computing, _provided_ that some things are in place. *If* the user
can set up the signatures herself, this can be a great boon to security.
Imagine being able to ensure that the kernel you're booting was indeed
the one you compiled and signed, and that it's not been rootkited. Even
better, envision signed modules and binaries, making rootkits much, much
harder. How? Well, sign the modules. The kernel then has the public
key and can verify that the module hasn't been tampered with. Even
better, it can refuse to load modules you've not signed, so that crackers
can't set up a module so that not even your low-level tools can pick up
the DoS daemon they've got running on port 666.
Programs, already signed by you or the distro, could be kept signed on disk,
and the kernel, having the appropriate public key supplied by you and/or
the distro, could then verify that the binary hasn't been tampered with.
Extend this to files, so that, for example, the cracker can't edit
inetd.conf to make a bash instance listen in on port 1337, since inetd
could ask the kernel to verify the signature of the file. And, even
better, distribution updates can still be transparent, so long as the
keys haven't changed. The package system just updates the signatures
automatically with the files. This would require adding metadata to the
file to store the signature, but it'd work and do quite a bit to make
rootkits that much harder to implement.
Can this be abused? Absolutely. StarOffice 8 could ask the kernel to
ensure that the StarWriter file has not been modified. But, nobody's
forcing you to use StarOffice 8; use AbiWord instead. Indeed, aside
from asking the kernel to verify the file's integrity, nothing is there
that can't be done with existing cryptographic routines. The difference
is that the kernel is Linux, and doesn't care *what* the word processor
is, so long as it's carrying a trusted signature (by you and/or the
distro). Remember, this is Linux, and you can get the source, and make
it go yourself. It's not Windows, which is closed and has Microsoft's
business plan and Microsoft's interests behind it. Effectively, it's
*your* kernel, and it has *your* interests behind it, because the
hardware only cares that you signed it.
SO LONG as the hardware gives you that right. This is why it's imperative
that we get people on the steering committees. Do we already? It's
extremely unfortunate that one has to be a *business* in order to join
a standards group and steer the future of technology. Unless you happen
to have thousands, if not tens of thousands of dollars lying around that
can't be put to better use. Hopefully, our corporate backers can help
get us in to these meetings; it's imperative that we (the users) can tell
the hardware what to do; not for the hardware to tell *us* what we can do.
We *must* be able to set the signatures via *some* method. This doesn't
need to circumvent the system if designed properly [for instance, requiring
physical access + special knowledge (e.g. password)]. Won't stop
everything, but neither will anything else [for instance, FBI could force
chipmaker to make special chips with special keys to allow them to load,
say, a keysniffer, even if it's embedded into a chip and not otherwise
settable].
There's more that could be done with a trusted architecture [fast hardware
encryption, storing keys so that not even the kernel knows them nor can
get at them; mutual distrust between the key/user credential storage and
the kernel, etc.] to make it a very secure system *if* we can hack on it
too, and ensure that the user is in control. Essentially, we (linux, BSD,
and others) are the ones working for the users. We are extremely
necessary in the fixating the digital future for the users.
This last part was the last part of my debian-devel posting; I think I've
covered it all. I hope that we can adopt the good parts of Trusted
Computing, and I really hope we can help steer it to make sure it goes
in a way that's not constrictive. It's a fine line, but, maybe with
corp. backing (Transmeta, Sun, IBM, Red Hat), we might be able to get
some developers in to the TCPA and others.
After all, if Microsoft can do it, we can do it *better*. (and freer ;)
-Joseph
--
Joseph===============================================tre...@digitasaru.net
"Isn't it illegal for Microsoft to tie any of its software products to its
OS?" --Rob Riggs on slashdot (www.slashdot.org) about Microsoft's order
to cease and decist using Visual Fox Pro on Linux, a non-Microsoft OS.
"Yes. The penalty is dinner with no dessert." --Alien Being, response
Jamie Lokier
> I'd like to see an x86 completely in perf board. I thought my high
> school digital electronics type stuff looked bad...
You could do it nowadays using dynamic binary translation, and an
absurdly simple CPU capable of accessing a large memory. You'd need a
DIMM for the large memory, but get away with discrete logic for the
CPU if you really wanted to.
At perf board sizes using discrete logic, expect it run run quite slow :)
-- Jamie
Jan-Benedict Glaw
wrote in message <3EA85937...@techsource.com>:
> Jamie Lokier wrote:
> We could always consider wiring everything up with discrete logic.
> Anyone got any spare 74138's?
Erm, we'd try to get speeds about MHz, not Hz or kHz for the whole
processor:)
MfG, JBG
--
Jan-Benedict Glaw 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
> > school digital electronics type stuff looked bad...
>
> You could do it nowadays using dynamic binary translation, and an
> absurdly simple CPU capable of accessing a large memory. You'd need a
> DIMM for the large memory, but get away with discrete logic for the
> CPU if you really wanted to.
>
> At perf board sizes using discrete logic, expect it run run quite slow :)
Could we not take this idea to it's logical extreme, and simply
calculate the results of every opcode, on every value, for every state
of all of the registers, and store them in an array of DIMMs, and
simply look up the necessary results? I.E. a cpu which is one _huge_
look up table :-).
John.
Steven Augart
excluding the MMX and FPU registers:
(AX, BX, CX, DX, BP, SI, DI, SP). 32 bits x 8 = 2^256 independent
states to look up in the table, each state having 256 bits of
information. 2^264 total bits of information needed. Assume 1 GB dimms
(2^30 * 8 bits each = 2^33 bits of info), with a volume of 10 cm^3 per
DIMM (including a tiny amount of space for air circulation.).
Need 34508731733952818937173779311385127262255544860851932776 cubic
kilometers of space.
Considerably larger than the volume of the earth, although admittedly
smaller than the total volume of the universe.
--Steven Augart
Andreas Jellinghaus
> system (which counts as an insecure link), and the BIOS tells the
> server that it is the correct DRM BIOS, and it loaded a signed kernel.
[lots of additional chats]
that does not work: the server could chat with a bios in a vmware
unaware of that fact.
but tcpa is a solution to that problem. first it doesn't need
all those chats but only one where a list of hash value with
a signature is transmitted. the hash values represent the software
packages (such as bios, boot loader, kernel, drivers, ...)
and the signature proofs its authentity.
second the signature proofs the non virtualization:
a key and certificate is required to do that, and the
cert is checked if it has a chain to one root and it
is not revoked. such certificates are only created
by trusted hardware manufacturers and they certify
only real hardware with the private key in a TPM module
that cannot export the key.
however, if someone opens a TPM module and reads the
content physicaly, then the trust is gone (at least
till someone finds out and that key is revoked).
IBM claims their TPM module containt no hardware security
(like that stuff usualy found in smartcards).
> Substitute "broadcaster" for "game server" and you see that the same
> methods ensure that you really have the TV switched on and you are not
> recording the show.
absolutely correct.
But I'd like a small usb device that is like "broadcaster" or "game
server" and tells me when plugged into any machine "this is secure,
no trojans/backdoors/key sniffing software installed". But that might
be even harder to do?
> They also ensure you are not recording a screenshot of a politically
> sensitive article about Iraq that was accidentally shown on CNN's web
> site for 10 minutes. We can't have people recording things like that.
Hey, good we still have normal photos. and usualy you can "print"
things on webpages.
> Also that day, that same article doesn't load from Al-Jazeera or
> anywhere else, on the PC you bought from the only affordable store in
> town.
ah, myth. please dig into the tcpa spec and quote where you find
anything that provides substance for that. possible? even today without
tcpa or DRM or anything like that. but why does DRM or TCPA make this
easier or harder to work around?
if we could asure that DRM would only be used in 0.1% of all computer
uses, then banks and stuff could use it, maybe even that digitial video
rental using the internet (they already do, but without hardware
support), and everyone else will not. I don't see the problem with
some uses, but with everyone using it.
Andreas
Helge Hafting
> Could we not take this idea to it's logical extreme, and simply
> calculate the results of every opcode, on every value, for every state
> of all of the registers, and store them in an array of DIMMs, and
> simply look up the necessary results? I.E. a cpu which is one _huge_
> look up table :-).
You can, if you can keep the internal state sufficiently small.
Say we want to keep the internal state down to 32 bit,
using a 16GB lookup table. (4G*32bit)
What would the state be? Perhaps one general-purpose
8-bit register, a 16-bit program counter and
8 bits left for the current opcode & flags.
Less opportunities than a 6502, but it'd sure be fast.
Helge Hafting
Helge Hafting
> On Fri 25 Apr 03 00:45, Alan Cox wrote:
[...]
>>In the MUD world we solved that by not telling anyone about objects they
>>can't see.
>
> possible but not really practical.
>
Sure, but one can do better than quake. The server can have
a look at the "terrain" at startup, and divide it into a
bunch of regions and calculate which regions cannot
bee seen from each other. You can then do
fast simplified visibility calculation on the server,
by looking up positions in a lookup table. Players
in tunnels and such isn't visible from most of the
level so such structures would then provide the
desired surprises - even for cheaters.
Also, one can use a representation that makes it hard for
an AI to guess what is "wall" and what is a "player".
The players could be polygons just like everything else,
and a good level would have more moving items than
players so movement detection won't be a good
heuristic either.
Eric W. Biederman
> Daniel Phillips wrote:
> > Open source + Linux + DRM could be used to solve the Quake client-side
> > cheating problem:
>
> Yes, but in return you'd be excluded from playing Quake unless
> you're running one of those signed kernels or modules.
In this context, the only thing I know has been openly discussed
is to have a BIOS that includes a public key of my choosing for
authentication.
> So, if I, say, want to test some TCP fix, new VM feature, file
> system improvement, etc., none of the applications that rely on
> DRM would work. This doesn't only affect developers, but also
> their potential testers.
Not so because in a general purpose system the owners of the
system control the keys.
> Given that most users will just run a distribution's kernel, with
> all the right signatures, companies will not perceive the few
> cases in which their use of DRM causes problems as very important,
> so they will use DRM.
Redhat's kernel is unlikely to get my signature. Possibly
at some point there will be a web of trust where that will work
but in the first approximation distributors kernels will not
load until I sign them.
> Oh, maybe some developers could be granted the privilege of being
> able to sign their own kernels or modules. So if you're part of
> this circle, you'd be fine, right ? No, even this doesn't work,
> because if you'd leak such a key, you'd certainly get sued for
> damages. And I don't think many people would feel overly pleased
> with the idea of being responsible for the safekeeping of the key
> to a multi-million lawsuit. (And besides, this may turn them into
> targets for key theft/robbery/extortion.)
>
> (There are of course uses of such signatures that would not have
> those problems. E.g. signatures that prove trustworthiness to the
> local user, instead of a remote party.)
Yes. And there has been some limited discussion on LinuxBIOS list
about implementing these.
Eric
Downing, Thomas
-----Original Message-----
Jamie Lokier [mailto:ja...@shareable.org]
>Downing, Thomas wrote:
>> How does the server _know_ that the BIOS is what it says it is? Again,
>> what's the protocol? Saying that they 'have a chat' is bypassing
>> the hard bits.
>>
>> If I have the BIOS, any secrets it holds are now knowable to me.
>> This means that any protocol that relies on a secret in the BIOS is
>> broken from the start. So now you need to define a protocol which
>> does not rely on any secret being known to the BIOS. What is this
> protocol?
>
>What makes you think you can read the BIOS?
If it is a BIOS in the PC-compatible sense, of course I can.
>
>> The proposed 'end-to-end' copy protection schemes for entertainment
>> media etc, rely on proprietary _hardware_.
>
>Yes, that's the severe version of DRM that we're talking about, for
>the game server scenario.
I though that this was in reference to a way to solve Quake etc.
cheating in the current hardware environment. I you pull in
extra hardware, the equation changes.
>
>> This is still beatable, although at a higher cost. Nor is the
>> problem quite parallel. The broadcast problem is 'how do we keep
>> content encrypted till the last possible moment?' and 'how do we
>> keep the decryption engine tamper proof reverse engineering proof'.
>> The first part is easy. The second part is not possible in an
>> absolute sense. It can only be made more or less dificult. Hence
>> the DMCA etc.
>
>We don't know for sure that it's not possible to make something
>reverse engineering proof. Although all current CPUs require code to
>be decrypted at some point, there may be modules of computation that
>don't require that, so there would be no way to extract the secret key
>or decryption process in a useful way even when you can see every
>electronic signal in a device. The jury is out on it, despite what
>slashdotters believe.
>
>-- Jamie
Depends on who sits on the jury. With few if any exceptions, the top
people in the security field would agree with what I said. That's not
because I'm brilliant, it's because I'm just parrotting back what
they have said.
As is often said, security is all shades of grey. It may well be
possible to make a device that is so hard to reverse engineer and so
hard to hack, that it offers protection that lasts as long as the
effective market life of the thing it is protecting. At that point
it is good enough. Now you have a foundation on which to base
the required protocol. You are now done from the theoretic side,
and this debate comes to an end; you have your Quake-cheat blocker.
But if you go on to consider the practical side, even now you have
only solved the easy part: the tough part is correctly implementing
the entire 'soft' chain from this device to the corresponding device
on the server. Now _that's_ not easy.
Downing, Thomas
>On Wed, Apr 23, 2003 at 10:43:37PM -0700, Linus Torvalds wrote:
>>...
>> And hey, the fact is (at least as far as I'm concerned), that as long as
>> you make the hardware, you can control what it runs.
>>...
>
>Linux is currently widely used and through this there comes some power.
>Let me try to make examples where this might be important:
You cast these comments in the context of corporate use, so -
The primary reason corporations are beginning to adopt Linux is TCO
- and such adoption is in its early stages, though growing. Such
adoption is _only_ to the extent that Linux will run specific
applications.
Companies do _not_ adopt Linux because it is the only OS on which
their critical applications run. They don't adopt it because it's
the coolest OS out there. All the corporate required applications
run on other O$'s. If support for a facility percieved as desirable
or necessary (in this case, DRM)is not available in Linux due to the
terms of the GPL, corporations will drop Linux in a heartbeat.
Some companies (viz certain very large financial institutions) are
only now just beginning to write applications _on_ Linux. When
Linux has a majority market share, with the rest of the market in
disarray, _then_ you have some power; but only for a limitted time.
Ragnar Hojland Espinosa
>
> As much as I dislike Microsoft for its business practices, I still feel
> uneasy having illegal copies of their Office suite. So I use OpenOffice
> instead. Likewise, I prefer to use Linux because having a free copy of
> it is perfectly legal. And finally, although I do like the idea of
> being able to sample music before I buy it, I feel an attachment to
> artists I listen to, so I buy their CD's (despite the fact that it helps
> the RIAA).
> So the idea of having something which prevents me from illegally
> pirating something doesn't bother me so much. Whenever I have to do
> serious work, I either use an OSS tool, or I pay money for a piece of
> software so I can get support -- sometimes, I even pay for OSS stuff.
> The idea of a DRM system malfunctioning and preventing me from
> accessing my legally-licensed material DOES bother me very much, but I
> think only in the hands of people like us can it be done right, because
> we're the very ones who would suffer were it to break.
What I don't get is why would you think MS you'd be able to open MS docs with
open office, or how would Wine work. Or even more simple, would you be able
to just plug a samba server and that it would be recognized by MS clients as
a trusted party?
I must surely be missing something..
--
Ragnar Hojland - Project Manager
Linalco "Especialistas Linux y en Software Libre"
http://www.linalco.com Tel: +34-91-5970074 Fax: +34-91-5970083
Downing, Thomas
>On Fri 25 Apr 03 00:45, Alan Cox wrote:
>> On Iau, 2003-04-24 at 22:42, Daniel Phillips wrote:
>> > A more mundane goal would be to prevent the 3D driver from letting you
>> > see through polygons that are supposed to be opaque.
>>
>> In the MUD world we solved that by not telling anyone about objects they
>> can't see.
>
> Doing the visibility calculations on the server, down to the pixel, is
> possible but not really practical.
>
> Regards,
>
> Daniel
Just goes to show that the VDU was the acme of the compute world,
it's been all down hill since... ;-)
Downing, Thomas
>> > I'd like to see an x86 completely in perf board. I thought my high
>> > school digital electronics type stuff looked bad...
>>
>> You could do it nowadays using dynamic binary translation, and an
>> absurdly simple CPU capable of accessing a large memory. You'd need a
>> DIMM for the large memory, but get away with discrete logic for the
>> CPU if you really wanted to.
>>
>> At perf board sizes using discrete logic, expect it run run quite slow :)
>
> Could we not take this idea to it's logical extreme, and simply
> calculate the results of every opcode, on every value, for every state
> of all of the registers, and store them in an array of DIMMs, and
> simply look up the necessary results? I.E. a cpu which is one _huge_
> look up table :-).
>
> John.
NOW your'e talking! Alan Turing meets Julian Barbour.
David Luyer
> > A more mundane goal would be to prevent the 3D driver from
> > letting you see through polygons that are supposed to be
> > opaque.
>
> In the MUD world we solved that by not telling anyone about
> objects they can't see.
The problem is not solved in the MUD world particularly well.
Sure, you can not transmit the location of other players, but
the client software (eg. zmud) can still give the client an
advantage over the "innocent telnet using client", by doing
things like keeping a map and tracking your current location
(and even using point-and-click to go to any previously seen
location).
Discworld as an example had an area with left,right,back,forward
directions which zmud was later enhanced to handle. So to
make things a little harder they changed descriptions a little
when "anomolies" appeared so automated "return to previous
point" procedures would walk through the anomoly and get warped
into a reality with hard to determine rules (directions
left,right,forward,back, but if you go left four times you don't
end up where you started).
And there are other problems from the MUD world that have
parallels in 3D online gaming... triggers, for example.
Even colourization of MUD text by something like TF is
equivalent to 3D drivers doing some kind of enhancement
on distant objects (showing you the distant player movement
that would otherwise be barely percievable).
I'm not holding my breath for the first MUD to use DRM to
ensure the end-user is directly connected to a keyboard
with no triggers, mapping, colourization, etc in between
though :-)
Even if such a setup was possible, and say the keyboard was
even a "signed device", you could still setup a mechanical
device to override the keys for you and some OCR software on
a second PC reading the screen's display and displaying the
colourized version, processing triggers, generating maps,
etc. There is sufficient technology available these days
that DRM would be insufficient to even protect a MUD from
the most basic forms of cheating.
David.
Mike Dresser
On Thu, 24 Apr 2003, John Bradford wrote:
> > > We could always consider wiring everything up with discrete logic.
> > > Anyone got any spare 74138's?
> >
> > I need 1 billion of them please, and I need the overclockable ones :)
>
> Why not just buy one of those 100-in-1 electronics kits from your
> local electonics hobbyist store, and make your very own wire wrap CPU?
They don't usually come with the needed 70W .01 ohm resistor you'd need
to completely emulate a modern cpu.
Mike
Solbu
Hash: SHA1
On torsdag 1. januar 1970 01:00 Clemens Schwaighofer tried to express an opinion:
(Hmm.. I think there is a bug in the KNode version I'm running.
The date is clearly wrong :-) )
> so should we start to sign all our emails? so we know we trust each other?
I do :-)
Every single email & news post I ever send, is signed.
I even tell people I corespond with that also use PGP/GnuPG
that if they get something from me that aint signed, don't trust the message.
But then again, some of my friends (even my dad)
says that I'm security paranoid :-)
- --
Solbu - http://www.solbu.net
Remove 'ugyldig' for email
*****************************************
PGP key ID: 0xFA687324
*****************************************
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE+qU+sT1rWTfpocyQRAsOIAJ42WvjPcJZFPOMDFLG2Rl712HLvKwCcD2oz
MeJVWVKgNI89gOyJrle6GI0=
=p3Np
-----END PGP SIGNATURE-----
Valdis.K...@vt.edu
> To get cheatless online gaming, you would have to necessarily give up a lot
> of flexibility. I imagine the likelihood of people running completely
> separate DRM Linux boxes, just to participate in DRM-controlled online games,
> is not high. Only when if you are faced with absolute necessity of running
> DRM, are you actually going to do it by choice. There's going to be a whole
How many people own both a PC and an XBox?