Rusty's Bleeding Edge Page

So, there's been lots of talk of cryptographically-signed kernel modules. Security-wise, it's not a win by itself (you need lots of other things), but it does mean that you can prevent some trivial stuff. I've been playing with them.

I am not a lawyer, but the question that Andrew Tridgell raised was, does distributing cryptographically-signed modules violate the GPL, or weaken future legal defence against really noxious Digital Rights Manglement (DRM)? Linus has stated that he can't see how the GPL can effect such a thing, since the keys aren't a derived work, but I believe that's overly simplistic.

DRM methods are designed to restrict the execution of modified programs. The GPL is designed to ensure your right to modify programs (and, presumably, use them). So in simplistic terms, DRM is inimical to the GPL, and vice versa. But does the GPL say anything about it?

Section 3 of the GPL states what you must do if you want to distribute binaries of the GPL work. Someone distributing Linux to run on a computer clearly comes under this section, as does a Linux distributor shipping a pre-compiled Linux kernel. If that section says you have to do something, you have to do it to meet the license.

This section explains that you must provide the source code, in one of three ways. There are a few phrases in this section which attract attention:

1. "Complete corresponding machine-readable source code",
2. "The source code for a work means the preferred form of the work for making modifications to it", and
3. "For an executable work, complete source code means... plus the scripts used to control compilation and installation of the executable."

Does the "complete source code" include the keys used to sign the executable so it can actually run? Does the "scripts use to control compilation and installation" include the keys? It's not spelled out. But "preferred form of the work for making modifications" strongly implies what is spelled out in the premble, which say the purpose of the license is to "guarantee your freedom to share and change free software".

So you could argue that if it's necessary for modification (either as part of the "complete source code" or "scripts used to control compilation and installation"), you have to offer it with the binary. That's clearly the intent of section 3, but I don't know enough to say if the wording is sufficient.

So, where are we with the kernel module-signing issue? This seems to be OK (at least, Eben Moglen says it's OK, and he's a real lawyer). As he says "It doesn't violate any principal of freedom". To quote him in more detail:

There are imaginable situations in which a private encryption key could be part of the "complete and corresponding source code" under section 3, if the code functionally cannot be built without it. But that's not this situation: a session key created during the course of the build is "provided" when the build ritual that creates and uses that key is provided.

[/IP] permanent link