LKML Archive on
help / color / mirror / Atom feed
From: Jan Engelhardt <>
To: Bodo Eggert <>
Cc: Linux Kernel Mailing List <>,
	Andrew Morton <>,
	Jon Masters <>,
	Alexey Dobriyan <>
Subject: Re: [PATCH/RFC] alternative aproach to: Ban module license tag string termination trick
Date: Sat, 3 Feb 2007 12:32:08 +0100 (MET)	[thread overview]
Message-ID: <Pine.LNX.4.61.0702031213220.27840@yvahk01.tjqt.qr> (raw)
In-Reply-To: <Pine.LNX.4.58.0702022216120.25199@be1.lrz>

On Feb 3 2007 03:08, Bodo Eggert wrote:
>This patch changes the module license handling code to:
>- allow modules to have multiple licenses
>- access GPL symbols if at least one license is GPL-compatible

I strongly nak that. If you combine two object files (e.g. foo.o, bar.o)
that have different licenses, the resulting object file (comb.o) IMHO
constitutes a combined work, and hence the GPL should be applied to all of
it. That obviously "does not work" - what good is a GPL comb.o file if you
don't have the source to bar.o? I think a module (.ko) should be denied
access to GPL symbols if any of the MODULE_LICENSE()s are not GPL.
Otherwise, ndiswrapper, CiscoVPN, etc. would just add a dummy.c GPL file
with a MODULE_LICENSE("GPL") in there and get the symbols. Though you
could still get at the GPL symbols by use of a dedicated wrapper (think
nvidia kernel module), I would not want to make it easier for them by
allowing your two points. At best, foo.o and bar.o should be compiled
independently to foo.ko and bar.ko and work with EXPORT_SYMBOLs.

>- prevent the "GPL\0 for nothing"-trick
>- fix an off-by-one buffer overflow
>  (exploitable only if the attacker can load modules)
>- move the ndiswrapper check into the new license checking routine
>Signed-Off-By: Bodo Eggert <>
>The license handling code was kind of strange:
> - The kernel itself would only consider the first license, while modpost
>   looks at all of them.
> - If you offer your module under a non-GPL license in addition to GPL,
>   modpost would consider this module to be non-GPL. Therefore you can't
>   say MODULE_LICENSE("GPL");\nMODULE_LICENSE("completely free");

The idea to allow MODULE_LICENSE("GPL");\nMODULE_LICENSE("Public Domain");
is good, but how would you interpret an .o file (with no source!) with
MODULE_LICENSE("GPL");\nMODULE_LICENSE("Proprietary") ? (Well, see above)

>Prohibiting the \0-trick is done by storing the length of the license
>behind the license itself, uuencoded, as $=xyz.
>Currently, only 18 bits (256 KB) of the length are stored, but storing up
>to 30 bits is possible without changing anything besides the macro.
>You can still trick this code by including "...\0license=GPL\0$=$\0..." or
>by manually fabricating this string into .modinfo. Fix: Document this to
>mean that you actually GPL-license the module. 

$=$ is interpreted as what? [Ah ok, uuencoded uint32_t] That does not look
good. What if the length thing does not immediately come after the license
string? (E.g. someone hand-crafted a .ko)

>TODO: get_modinfo: make sure the value returned does not exceed the end of 
>      the buffer.
>diff -X dontdiff -pruN 2.6.19/include/linux/license.h 2.6.19.license/include/linux/license.h
>--- 2.6.19/include/linux/license.h	2006-11-29 22:57:37.000000000 +0100
>+++ 2.6.19.license/include/linux/license.h	2007-02-02 18:30:44.000000000 +0100
>@@ -1,14 +1,27 @@
> #ifndef __LICENSE_H
> #define __LICENSE_H
>-static inline int license_is_gpl_compatible(const char *license)
>+static inline int license_is_gpl_compatible(const char *license,
>+                                            int length)
> {
>-	return (strcmp(license, "GPL") == 0
>-		|| strcmp(license, "GPL v2") == 0
>-		|| strcmp(license, "GPL and additional rights") == 0
>-		|| strcmp(license, "Dual BSD/GPL") == 0
>-		|| strcmp(license, "Dual MIT/GPL") == 0
>-		|| strcmp(license, "Dual MPL/GPL") == 0);
>+	static char *gpl_compatible[] = {

static const char *const gpl_compatible[];

>+	    "GPL",
>+		"GPL v2",
>+		"GPL and additional rights",
>+		"Dual BSD/GPL",
>+		"Dual MIT/GPL",
>+		"Dual MPL/GPL",

If we allowed multiple MODULE_LICENSE()s, all the Dual XYZ/GPL
combinations and so can go, since it would be possible to have
module loader code.

>+extern void do_get_next_modinfo_len(struct pstring_len *ret,
>+                                    char * start,
>+                                    unsigned long size,
>+                                    const char *tag);

"char * t" vs "char *t", also elsewhere.

>+	/* We'll consider the kernel to be tainted by ndiswrapper
>+	 * & co., since they'll usurally load proprietary code */



  parent reply	other threads:[~2007-02-03 11:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-03  2:08 Bodo Eggert
2007-02-03  8:14 ` Russell King
2007-02-03 11:38   ` Jan Engelhardt
2007-02-03 19:56   ` Alan
2007-02-03 20:12     ` Randy Dunlap
2007-02-03 11:32 ` Jan Engelhardt [this message]
2007-02-03 11:54   ` Theodore Tso
2007-02-03 14:04   ` Bodo Eggert
2007-02-03 19:47     ` Alan
2007-02-03 20:02 ` Alan
2007-02-05 13:08   ` Bodo Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.61.0702031213220.27840@yvahk01.tjqt.qr \ \ \ \ \ \ \
    --subject='Re: [PATCH/RFC] alternative aproach to: Ban module license tag string termination trick' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).