Misunderstanding of embedded system designers [LWN.net]

Misunderstanding of embedded system designers

Posted Jan 17, 2006 1:52 UTC (Tue) by karim (subscriber, #114)
In reply to: Misunderstanding of embedded system designers by nchip
Parent article: GPLv3: a first look

Well, if we're going to discuss "other ways" of doing DRM, here's a basic
example applied to the kernel (not that the kernel developers have
agreed to use GPL3 for the kernel, but just for the sake of argument):

Prior to booting kernel, let the firmware verify the kernel's signature.
Whether or not the signature is valid, boot the thing. But, if it isn't
valid, lock up or disable or just don't enable those hardware components
that control access to the "stuff" -- and do this in a way that requires
a hard reset for another pass at lock/don't-lock. Then package all the
proprietary/DRM software into individual applications. So everything just
runs as normal up to the time these apps try to access the hardware,
and now because it's disabled, the device is useless.

Using the words of the draft, there are no codes for you to "install and/
or execute" the work. In fact, you're free to install and execute any
kernel you wish. Plus, the kernel's "functioning in all circumstances is
identical". It's just that hardware beneath it just doesn't work any more,
and that, consequently, the proprietary applications running on top can't
do anything because the hardware is disabled.

There you have it, GPL3-compatible DRM -- to the best of my understanding
of course, and mind you I'm not a lawyer.

Again, fighting DRM is a worthy goal, but this is the wrong venue.

Karim

(Log in to post comments)

Misunderstanding of embedded system designers

Posted Jan 17, 2006 7:11 UTC (Tue) by foom (subscriber, #14868) [Link]

I think it is clear that the GPL can only protect the works that it covers. So, if you can fully use the
hypothetical GPLv3'd kernel but some proprietary app is protected by DRM, there can be nothing
wrong with that. Yes, you cannot use the proprietary application, but, you must be able to fully use
everything on the system protected by the GPL.

However, note one further wrinkle. Let's assume that there will be an LGPLv3 similar to the current
LGPL + GPLv3 changes. Then, said proprietary app must allow the replacement of LGPL'd
subcomponents and still function. Such as...GNU libc. So, you can build your proprietary app with a
DRM checksum, but, I have to be able to replace the GNU libc and have the app still function.

Of course, you can build your app without libc, too...

Misunderstanding of embedded system designers

Posted Jan 17, 2006 8:22 UTC (Tue) by phip (subscriber, #1715) [Link]

It may be a small victory, but at least the pre-boot firmware could not be derived from free (GPL3) signature-checking code.

Another small benefit is it makes life more difficult for developers of locked-down hardware. They need to pay careful attention to how the lock-down is implemented to avoid violating the license, and if they slip up, it will be clear that they had every intention of violating the spirit of the license, even if the violation of the letter may be accidental.

Every little bit helps.

-Phil

'cannot be part of an effective prevention measure'

Posted Jan 18, 2006 0:54 UTC (Wed) by xoddam (subscriber, #2322) [Link]

That use case would be compatible with this draft of the GPLv3, yes.
Thankyou for pointing out the loophole; the final licence may close it.

Supposing some OS kernel is licensed under a GPLv3 which retains this
loophole and used in a system such as you describe -- the GPLv3 kernel is
constrained not to be part of an 'effective prevention measure', meaning
that it is explicitly permitted to use the kernel (modified or not) as a
tool to reverse-engineer the DRM-enabled firmware, devices and
applications.

An OS kernel is fairly well positioned to do this job. I think DRM
device developers would be best advised not to use a GPLv3 kernel.

'cannot be part of an effective prevention measure'

Posted Jan 18, 2006 16:23 UTC (Wed) by karim (subscriber, #114) [Link]

FWIW, you'd be amazed what can be done by a piece of
hardware. So a scenario where the hardware has a latch
that can only be set once until hard-reset or power
down is very possible. Whether you can get the OS to
boot or not, and regardless of what that OS tries to
do, that hardware won't change state ... that's one
thing that's nice about hardware, you actually get to
control what software can and cannot do ...

Karim

'cannot be part of an effective prevention measure'

Posted Jan 20, 2006 3:24 UTC (Fri) by xoddam (subscriber, #2322) [Link]

> Whether you can get the OS to boot or not, and regardless
> of what that OS tries to do, that hardware won't change state ...

So I fisrt boot the unmodified, signed kernel to which I have the source
(six months behind the current free version) and have the hardware fully
enabled. Now I use some kernel exploit (reported and promptly fixed some
time in the last six months) to kexec an updated kernel, configured as I
please. Voilà! I 0wn my own box.

'cannot be part of an effective prevention measure'

Posted Jan 20, 2006 3:48 UTC (Fri) by karim (subscriber, #114) [Link]

Ah ... yes ... thanks for bitting ... At last someone steps
up to the challenge ;D

It's worthy to note that the problem you allude to is
something a designer of such a system would absolutely need
to catter for even today. IOW, this is not an unknown issue.

Think no glibc ... think selinux ...

Not that it's easy to get it right. The hacks we've seen on
some consoles are based on similar ideas ...

Karim

'cannot be part of an effective prevention measure'

Posted Jan 20, 2006 8:04 UTC (Fri) by xoddam (subscriber, #2322) [Link]

"the problem you allude to"

There's a problem? I'm not alluding to a problem, I'm working out how to
exercise my rights under the GPL :-)

I understand that if I receive a box with a differently-licenced
operating system then such exploits may violate the DMCA and its
equivalents in countries (such as my own) which have free-trade
agreements with the USA. The purpose of the DRM clause in the draft
GPLv3 is to ensure that GPL software is not used to take away the rights
of its users to use the software as they please.

Given that there is no GPLv3-licenced kernel, and that if there ever is
one it is not likely to be used inside such restricted devices,
*somebody* has to break bad laws and put up a spirited defence to them in
court or a time will come when they are considered normal and therefore
proper.

Misunderstanding of embedded system designers

Posted Jan 19, 2006 9:12 UTC (Thu) by hingo (subscriber, #14792) [Link]

In contrast with other commentors, I'm not at all convinced your scenario is allowed by this draft of v3. It seems that that kind of thing is exactly what it tries to prevent and in my opinion there is no loophole: If the key the manufacturer possesses is needed to use features of the hardware, and features can't be used without it, then it is part of the source code. If your interpretation was correct, one could ship binary-only kernel modules by saying "sure, you can do whatever you want with the kernel sources, you just won't have wireless lan (or whatever) anymore. The hardware will boot the kernel, just with less features."

Now on the other hand, it is true that you could make an embedded Linux device and install non-gpl applications on it (Real Player, even Wine + MS Media Player in theory at least) that do the DRM in userspace. That is not forbidden, although such drm won't last very long. Fortunately!

Misunderstanding of embedded system designers

Posted Jan 19, 2006 15:08 UTC (Thu) by karim (subscriber, #114) [Link]

Are you telling me that in your view a software license can actually
dictate a hardware license?

Sorry, as a software publisher you have the right to dictate how
your work is being used, not other people's work -- lest you are
telling me that the GPL3 is a DRM tool itself.

Given that the kernel is not touched in any way and that no part of
it is implementing the software-side of the DRM, there is nothing
that precludes a designer to control the layer beneath the kernel
(i.e. the hardware) and the layer that's over the kernel (i.e. his
applications) as he sees fit. In fact, I'm pretty sure (though I'm
not a lawyer and this is not legal counsel) that if you did try
what you allude to -- using the kernel to circumvent the user-
space DRM -- you'd probably fall under the DMCA ...

Have all the fun you want, but this isn't a loophole, it's just
something the GPL cannot, to the best of my understanding, legally
cover.

Karim

Misunderstanding of embedded system designers

Posted Jan 19, 2006 20:52 UTC (Thu) by Fats (subscriber, #14882) [Link]

"Sorry, as a software publisher you have the right to dictate how
your work is being used, not other people's work -- lest you are
telling me that the GPL3 is a DRM tool itself."

You distribute the GPL3 code with the hardware. If you do something in the hardware that is incompatible with the GPL3 license of the software there is a provision in the license that forces you to not distribute the GPL3 software. You are free to distribute the hardware but not the accompanying GPL3 software. Don't know if this applies to this specific case though.

Misunderstanding of embedded system designers

Posted Jan 19, 2006 23:12 UTC (Thu) by im14u2c (subscriber, #5246) [Link]

Huh? How can the GPL say "You are not allowed to design hardware or software that recognizes only a single binary compilation of this program code."

That simply doesn't make sense. What if I wanted a Linux Security Module that verified all binaries on a system against a write-protected set of binary signatures, to verify no one's intruded on my system? Are you saying I can't do that for GPLv3 programs? That simply makes no sense.

The GPL doesn't say you can't design anything.

Posted Jan 20, 2006 3:28 UTC (Fri) by xoddam (subscriber, #2322) [Link]

The GPL does say you can't sell a version of GPLd software that is not
modifiable by the end-user. Draft GPLv3 says that if you need to sign
the software to run it, you must also provide the necessary key to the
end user -- it is considered part of the source code, and properly so.

Misunderstanding of embedded system designers

Posted Jan 20, 2006 6:36 UTC (Fri) by hingo (subscriber, #14792) [Link]

You mean you have take a hash of the final executable and the hardware will only run that and nothing else? I'm not sure on this one, but that may in fact be allowable (there is no secret key to give away, so you have given the user everything there is). It may not be very wise however, because if there is a bug in your software you cannot update it anymore, you'd have to replace the entire device. (If there is a non-hardware way to update it, the license requires you to provide the user with that mecanism.)

Therefore the wiser thing to do is what Karim above wants to do, have the firmware check whether the executable is signed with a particular key. This way you can later produce updates and sign them. On this issue the v3 is very clear. You have to either a) provide the user with the secret key needed, or (more likely) b) enable the user to alter the device such that he can use another key of his own without losing any functionality because of that.

While I'm writing here, I'll reply to Karim as well: Obviously, the GPL cannot dictate the hardware license. You can build such hardware if you want, and if your software is GPLv3 you'll have to include the secret key. Sorry boy, you are just worng and confused, and you should let go already. (For the benefit of everybody, I don't intend to continue this thread although I fully expect Karim will do so.)

Misunderstanding of embedded system designers

Posted Jan 20, 2006 20:50 UTC (Fri) by karim (subscriber, #114) [Link]

Feel free to paint my position in whichever color makes you feel better. But here's the quote from the license:

"Complete Corresponding Source Code also includes any encryption or authorization codes necessary to install and/or execute the source code of the work, perhaps modified by you, in the recommended or principal context of use, such that its functioning in all circumstances is identical to that of the work, except as altered by your modifications."

And what I suggest does exactly that. The kernel's behavior hasn't changed, its functioning is identical. It's the hardware beneath that isn't functioning the same way from the point of view of the user space applications accessing it ...

If confusion there is, I don't believe it's on my side.

Karim