Add tainting for proprietary helper modules.

Add tainting for proprietary helper modules.

[Dave Jones]

Kernels that have had Windows drivers loaded into them are undebuggable.
I've wasted a number of hours chasing bugs filed in Fedora bugzilla
only to find out much later that the user had used such 'helpers',
and their problems were unreproducable without them loaded.

Acked-by: Arjan van de Ven <arjan@infradead.org>
Signed-off-by: Dave Jones <davej@redhat.com>

--- linux-2.6.14/kernel/module.c~	2005-11-29 16:44:00.000000000 -0500
+++ linux-2.6.14/kernel/module.c	2005-11-29 17:03:55.000000000 -0500
@@ -1723,6 +1723,11 @@ static struct module *load_module(void _
 	/* Set up license info based on the info section */
 	set_license(mod, get_modinfo(sechdrs, infoindex, "license"));
 
+	if (strcmp(mod->name, "ndiswrapper") == 0)
+		add_taint(TAINT_PROPRIETARY_MODULE);
+	if (strcmp(mod->name, "driverloader") == 0)
+		add_taint(TAINT_PROPRIETARY_MODULE);
+
 #ifdef CONFIG_MODULE_UNLOAD
 	/* Set up MODINFO_ATTR fields */
 	setup_modinfo(mod, sechdrs, infoindex);

Re: Add tainting for proprietary helper modules.

[Zan Lynx]

[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]

On Fri, 2005-12-02 at 19:41 -0500, Dave Jones wrote:
> Kernels that have had Windows drivers loaded into them are undebuggable.
> I've wasted a number of hours chasing bugs filed in Fedora bugzilla
> only to find out much later that the user had used such 'helpers',
> and their problems were unreproducable without them loaded.
> 
> Acked-by: Arjan van de Ven <arjan@infradead.org>
> Signed-off-by: Dave Jones <davej@redhat.com>
> 
> --- linux-2.6.14/kernel/module.c~	2005-11-29 16:44:00.000000000 -0500
> +++ linux-2.6.14/kernel/module.c	2005-11-29 17:03:55.000000000 -0500
> @@ -1723,6 +1723,11 @@ static struct module *load_module(void _
>  	/* Set up license info based on the info section */
>  	set_license(mod, get_modinfo(sechdrs, infoindex, "license"));
>  
> +	if (strcmp(mod->name, "ndiswrapper") == 0)
> +		add_taint(TAINT_PROPRIETARY_MODULE);
> +	if (strcmp(mod->name, "driverloader") == 0)
> +		add_taint(TAINT_PROPRIETARY_MODULE);
> +
>  #ifdef CONFIG_MODULE_UNLOAD
>  	/* Set up MODINFO_ATTR fields */
>  	setup_modinfo(mod, sechdrs, infoindex);

ndiswrapper adds taint already, in load_ndis_driver().
-- 
Zan Lynx <zlynx@acm.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Add tainting for proprietary helper modules.

[Dave Jones]

On Fri, Dec 02, 2005 at 05:58:36PM -0700, Zan Lynx wrote:
 > On Fri, 2005-12-02 at 19:41 -0500, Dave Jones wrote:
 > > Kernels that have had Windows drivers loaded into them are undebuggable.
 > > I've wasted a number of hours chasing bugs filed in Fedora bugzilla
 > > only to find out much later that the user had used such 'helpers',
 > > and their problems were unreproducable without them loaded.
 > > 
 > > Acked-by: Arjan van de Ven <arjan@infradead.org>
 > > Signed-off-by: Dave Jones <davej@redhat.com>
 > > 
 > > --- linux-2.6.14/kernel/module.c~	2005-11-29 16:44:00.000000000 -0500
 > > +++ linux-2.6.14/kernel/module.c	2005-11-29 17:03:55.000000000 -0500
 > > @@ -1723,6 +1723,11 @@ static struct module *load_module(void _
 > >  	/* Set up license info based on the info section */
 > >  	set_license(mod, get_modinfo(sechdrs, infoindex, "license"));
 > >  
 > > +	if (strcmp(mod->name, "ndiswrapper") == 0)
 > > +		add_taint(TAINT_PROPRIETARY_MODULE);
 > > +	if (strcmp(mod->name, "driverloader") == 0)
 > > +		add_taint(TAINT_PROPRIETARY_MODULE);
 > > +
 > >  #ifdef CONFIG_MODULE_UNLOAD
 > >  	/* Set up MODINFO_ATTR fields */
 > >  	setup_modinfo(mod, sechdrs, infoindex);
 > 
 > ndiswrapper adds taint already, in load_ndis_driver().

That's good to hear.  Although I've definitly seen some
reports which have come through untainted. My guesses are
that the users were using an older ndiswrapper that didn't do this,
or they were using a < 2.6.10 kernel at the time
(for which ndiswrapper doesn't do this).

		Dave

Re: Add tainting for proprietary helper modules.

[linux-os (Dick Johnson)]

On Fri, 2 Dec 2005, Dave Jones wrote:

> Kernels that have had Windows drivers loaded into them are undebuggable.
> I've wasted a number of hours chasing bugs filed in Fedora bugzilla
> only to find out much later that the user had used such 'helpers',
> and their problems were unreproducable without them loaded.
>
> Acked-by: Arjan van de Ven <arjan@infradead.org>
> Signed-off-by: Dave Jones <davej@redhat.com>
>
> --- linux-2.6.14/kernel/module.c~	2005-11-29 16:44:00.000000000 -0500
> +++ linux-2.6.14/kernel/module.c	2005-11-29 17:03:55.000000000 -0500
> @@ -1723,6 +1723,11 @@ static struct module *load_module(void _
> 	/* Set up license info based on the info section */
> 	set_license(mod, get_modinfo(sechdrs, infoindex, "license"));
>
> +	if (strcmp(mod->name, "ndiswrapper") == 0)
> +		add_taint(TAINT_PROPRIETARY_MODULE);
> +	if (strcmp(mod->name, "driverloader") == 0)
> +		add_taint(TAINT_PROPRIETARY_MODULE);
> +
> #ifdef CONFIG_MODULE_UNLOAD
> 	/* Set up MODINFO_ATTR fields */
> 	setup_modinfo(mod, sechdrs, infoindex);

So your are blacklisting certain drivers? If so, you probably
should have an array containing their names plus a header-file
into which the hundreds, perhaps thousands, of future module-
names can be added.

... Not meant as a joke or an affront. User's should be able to
know what hardware to NOT purchase because of the proprietary
nature of their drivers. Putting a couple "exceptions" into
code as above is not good coding practice. If you need to
exclude stuff, there should be an exclusion procedure that
treats all that stuff equally, no?

Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.44 BogoMips).
Warning : 98.36% of all statistics are fiction.
.

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: Add tainting for proprietary helper modules.

[Dave Jones]

On Mon, Dec 05, 2005 at 08:41:57AM -0500, linux-os (Dick Johnson) wrote:
 > 
 > On Fri, 2 Dec 2005, Dave Jones wrote:
 > 
 > > Kernels that have had Windows drivers loaded into them are undebuggable.
 > > I've wasted a number of hours chasing bugs filed in Fedora bugzilla
 > > only to find out much later that the user had used such 'helpers',
 > > and their problems were unreproducable without them loaded.
 > >
 > > Acked-by: Arjan van de Ven <arjan@infradead.org>
 > > Signed-off-by: Dave Jones <davej@redhat.com>
 > >
 > > --- linux-2.6.14/kernel/module.c~	2005-11-29 16:44:00.000000000 -0500
 > > +++ linux-2.6.14/kernel/module.c	2005-11-29 17:03:55.000000000 -0500
 > > @@ -1723,6 +1723,11 @@ static struct module *load_module(void _
 > > 	/* Set up license info based on the info section */
 > > 	set_license(mod, get_modinfo(sechdrs, infoindex, "license"));
 > >
 > > +	if (strcmp(mod->name, "ndiswrapper") == 0)
 > > +		add_taint(TAINT_PROPRIETARY_MODULE);
 > > +	if (strcmp(mod->name, "driverloader") == 0)
 > > +		add_taint(TAINT_PROPRIETARY_MODULE);
 > > +
 > > #ifdef CONFIG_MODULE_UNLOAD
 > > 	/* Set up MODINFO_ATTR fields */
 > > 	setup_modinfo(mod, sechdrs, infoindex);
 > 
 > So your are blacklisting certain drivers? If so, you probably
 > should have an array containing their names plus a header-file
 > into which the hundreds, perhaps thousands, of future module-
 > names can be added.
 > 
 > ... Not meant as a joke or an affront. User's should be able to
 > know what hardware to NOT purchase because of the proprietary
 > nature of their drivers. Putting a couple "exceptions" into
 > code as above is not good coding practice. If you need to
 > exclude stuff, there should be an exclusion procedure that
 > treats all that stuff equally, no?

There's a point where the effort of creating an array, and
loops to parse it isn't worth it. For two entries, this
seemed a lot simpler.

Though if there more additions, I'd agree.

		Dave

Re: Add tainting for proprietary helper modules.

[Stephen Hemminger]

IMHO ndiswrapper can't claim legitimately to be GPL, so just
patch that. 

-- 
Stephen Hemminger <shemminger@osdl.org>
OSDL http://developer.osdl.org/~shemminger

Re: Add tainting for proprietary helper modules.

[Mark Lord]

Stephen Hemminger wrote:
> IMHO ndiswrapper can't claim legitimately to be GPL

Sure it is.

The applications it loads and runs may not be GPL,
same as for Linux in general, but ndiswrapper is just fine.

There's no GPL non-conformance unless somebody is distributing
code that extends GPL functionality without GPLing that code.

And NDIS does not violate that.  Sure, it runs binary-only
drivers developed for another O/S, but it is NOT distributing those.

Cheers

Re: Add tainting for proprietary helper modules.

[Alan Cox]

On Llu, 2005-12-05 at 09:34 -0800, Stephen Hemminger wrote:
> IMHO ndiswrapper can't claim legitimately to be GPL, so just
> patch that. 

Actually it isnt so simple. Load ndiswrapper. Now load a GPL windows
driver binary. I don't know if ndiswrapper itself could dig licenses out
of windows modules but if so it could even conditionally taint.

Alan

Re: Add tainting for proprietary helper modules.

[Brian Gerst]

Alan Cox wrote:
> On Llu, 2005-12-05 at 09:34 -0800, Stephen Hemminger wrote:
> 
>>IMHO ndiswrapper can't claim legitimately to be GPL, so just
>>patch that. 
> 
> 
> Actually it isnt so simple. Load ndiswrapper. Now load a GPL windows
> driver binary. I don't know if ndiswrapper itself could dig licenses out
> of windows modules but if so it could even conditionally taint.
> 
> Alan

On the other hand, if the windows driver were GPL then there wouldn't be 
any barrier to writing a native driver.

--
				Brian Gerst

Re: Add tainting for proprietary helper modules.

[Alan Cox]

On Maw, 2005-12-06 at 15:12 -0500, Brian Gerst wrote:
> Alan Cox wrote:
> > On Llu, 2005-12-05 at 09:34 -0800, Stephen Hemminger wrote:
> > 
> >>IMHO ndiswrapper can't claim legitimately to be GPL, so just
> >>patch that. 
> > 
> > 
> > Actually it isnt so simple. Load ndiswrapper. Now load a GPL windows
> > driver binary. I don't know if ndiswrapper itself could dig licenses out
> > of windows modules but if so it could even conditionally taint.
> > 
> > Alan
> 
> On the other hand, if the windows driver were GPL then there wouldn't be 
> any barrier to writing a native driver.

Sure, but the point was to demonstrate in a clear and logical fashion
that ndiswrapper could be GPL.

Re: Add tainting for proprietary helper modules.

[Randy.Dunlap]

On Tue, 6 Dec 2005, Alan Cox wrote:

> On Maw, 2005-12-06 at 15:12 -0500, Brian Gerst wrote:
> > Alan Cox wrote:
> > > On Llu, 2005-12-05 at 09:34 -0800, Stephen Hemminger wrote:
> > >
> > >>IMHO ndiswrapper can't claim legitimately to be GPL, so just
> > >>patch that.
> > >
> > >
> > > Actually it isnt so simple. Load ndiswrapper. Now load a GPL windows
> > > driver binary. I don't know if ndiswrapper itself could dig licenses out
> > > of windows modules but if so it could even conditionally taint.
> > >
> > > Alan
> >
> > On the other hand, if the windows driver were GPL then there wouldn't be
> > any barrier to writing a native driver.
>
> Sure, but the point was to demonstrate in a clear and logical fashion
> that ndiswrapper could be GPL.
> -

so it would be OK to run a windows NDIS driver on Linux,
by using ndiswrapper, as long as the windows NDIS driver is GPL?

Never mind its possible stack needs or who knows what else.

-- 
~Randy

Re: Add tainting for proprietary helper modules.

[Coywolf Qi Hunt]

On Mon, Dec 05, 2005 at 12:30:41PM -0500, Dave Jones wrote:
> On Mon, Dec 05, 2005 at 08:41:57AM -0500, linux-os (Dick Johnson) wrote:
>  > 
>  > On Fri, 2 Dec 2005, Dave Jones wrote:
>  > 
>  > > Kernels that have had Windows drivers loaded into them are undebuggable.
>  > > I've wasted a number of hours chasing bugs filed in Fedora bugzilla
>  > > only to find out much later that the user had used such 'helpers',
>  > > and their problems were unreproducable without them loaded.
>  > >
>  > > Acked-by: Arjan van de Ven <arjan@infradead.org>
>  > > Signed-off-by: Dave Jones <davej@redhat.com>
>  > >
>  > > --- linux-2.6.14/kernel/module.c~	2005-11-29 16:44:00.000000000 -0500
>  > > +++ linux-2.6.14/kernel/module.c	2005-11-29 17:03:55.000000000 -0500
>  > > @@ -1723,6 +1723,11 @@ static struct module *load_module(void _
>  > > 	/* Set up license info based on the info section */
>  > > 	set_license(mod, get_modinfo(sechdrs, infoindex, "license"));
>  > >
>  > > +	if (strcmp(mod->name, "ndiswrapper") == 0)
>  > > +		add_taint(TAINT_PROPRIETARY_MODULE);
>  > > +	if (strcmp(mod->name, "driverloader") == 0)
>  > > +		add_taint(TAINT_PROPRIETARY_MODULE);
>  > > +
>  > > #ifdef CONFIG_MODULE_UNLOAD
>  > > 	/* Set up MODINFO_ATTR fields */
>  > > 	setup_modinfo(mod, sechdrs, infoindex);
>  > 
>  > So your are blacklisting certain drivers? If so, you probably
>  > should have an array containing their names plus a header-file
>  > into which the hundreds, perhaps thousands, of future module-
>  > names can be added.
>  > 
>  > ... Not meant as a joke or an affront. User's should be able to
>  > know what hardware to NOT purchase because of the proprietary
>  > nature of their drivers. Putting a couple "exceptions" into
>  > code as above is not good coding practice. If you need to
>  > exclude stuff, there should be an exclusion procedure that
>  > treats all that stuff equally, no?
> 
> There's a point where the effort of creating an array, and
> loops to parse it isn't worth it. For two entries, this
> seemed a lot simpler.
> 
> Though if there more additions, I'd agree.
> 
> 		Dave

Hello,

You've hard-coded some module names, that itself `taints' the
kernel source IMO.  Blacklisting in kernel is both ugly and unacceptable.

I agree that it would be convenient for you to only check if there's `Not tainted' in oops messages.  But I still suggest you to not hard-code them in the
kernel source.  Instead you could use some script to grep the problematic module
names in the `Modules linked in' field.

For the long run, we could:

1) Add some other mechanism, like MODULE_LICENSE_STRICT("GPL.strict").

   GPL.strict:  A GPL.strict module is not only itself licensed under GPL,
   but it shall not load/link any binary code (specially non-gpl binaries)
   nor any non-GPL.strict code. This definition goes recursively.

   Then we let a module without GPL.strict taints the kernel. This time we
   treat everyone equally.

2) Fix the gpl in gpl3; follow the above.

-- 
Coywolf Qi Hunt

Re: Add tainting for proprietary helper modules.

[Xavier Bestel]

On Fri, 2006-01-06 at 10:49, Coywolf Qi Hunt wrote:

> You've hard-coded some module names, that itself `taints' the
> kernel source IMO.  Blacklisting in kernel is both ugly and unacceptable.

How about that: continue to blacklist ndiswrapper until it has
capability to taint itself the kernel when loading a proprietary driver.

	Xav

Re: Add tainting for proprietary helper modules.

[Jan Engelhardt]

>>  > > Kernels that have had Windows drivers loaded into them are undebuggable.
>>  > > I've wasted a number of hours chasing bugs filed in Fedora bugzilla
>>  > > only to find out much later that the user had used such 'helpers',
>>  > > and their problems were unreproducable without them loaded.
>>  > >
>>  > > Acked-by: Arjan van de Ven <arjan@infradead.org>
>>  > > Signed-off-by: Dave Jones <davej@redhat.com>
>>  > >
>>  > > --- linux-2.6.14/kernel/module.c~	2005-11-29 16:44:00.000000000 -0500
>>  > > +++ linux-2.6.14/kernel/module.c	2005-11-29 17:03:55.000000000 -0500
>>  > > @@ -1723,6 +1723,11 @@ static struct module *load_module(void _
>>  > > 	/* Set up license info based on the info section */
>>  > > 	set_license(mod, get_modinfo(sechdrs, infoindex, "license"));
>>  > >
>>  > > +	if (strcmp(mod->name, "ndiswrapper") == 0)
>>  > > +		add_taint(TAINT_PROPRIETARY_MODULE);
>>  > > +	if (strcmp(mod->name, "driverloader") == 0)
>>  > > +		add_taint(TAINT_PROPRIETARY_MODULE);
>>  > > +
>>  > > #ifdef CONFIG_MODULE_UNLOAD
>>  > > 	/* Set up MODINFO_ATTR fields */
>>  > > 	setup_modinfo(mod, sechdrs, infoindex);

(That's like putting the PCI name device database back in.)


>You've hard-coded some module names, that itself `taints' the
>kernel source IMO.  Blacklisting in kernel is both ugly and unacceptable.
>
>I agree that it would be convenient for you to only check if there's `Not tainted' in oops messages.  But I still suggest you to not hard-code them in the
>kernel source.  Instead you could use some script to grep the problematic module
>names in the `Modules linked in' field.
>
>For the long run, we could:
>
>1) Add some other mechanism, like MODULE_LICENSE_STRICT("GPL.strict").
>
>   GPL.strict:  A GPL.strict module is not only itself licensed under GPL,
>   but it shall not load/link any binary code (specially non-gpl binaries)
>   nor any non-GPL.strict code. This definition goes recursively.
>

How are you going to verify that, how do you want to distinguish whether a
certain byte range in memory (possibly beloaded with a windows driver) is prop
or not?



Jan Engelhardt
-- 

Re: Add tainting for proprietary helper modules.

[Coywolf Qi Hunt]

On Fri, Jan 06, 2006 at 11:46:10AM +0100, Jan Engelhardt wrote:
> 
> >>  > > Kernels that have had Windows drivers loaded into them are undebuggable.
> >>  > > I've wasted a number of hours chasing bugs filed in Fedora bugzilla
> >>  > > only to find out much later that the user had used such 'helpers',
> >>  > > and their problems were unreproducable without them loaded.
> >>  > >
> >>  > > Acked-by: Arjan van de Ven <arjan@infradead.org>
> >>  > > Signed-off-by: Dave Jones <davej@redhat.com>
> >>  > >
> >>  > > --- linux-2.6.14/kernel/module.c~	2005-11-29 16:44:00.000000000 -0500
> >>  > > +++ linux-2.6.14/kernel/module.c	2005-11-29 17:03:55.000000000 -0500
> >>  > > @@ -1723,6 +1723,11 @@ static struct module *load_module(void _
> >>  > > 	/* Set up license info based on the info section */
> >>  > > 	set_license(mod, get_modinfo(sechdrs, infoindex, "license"));
> >>  > >
> >>  > > +	if (strcmp(mod->name, "ndiswrapper") == 0)
> >>  > > +		add_taint(TAINT_PROPRIETARY_MODULE);
> >>  > > +	if (strcmp(mod->name, "driverloader") == 0)
> >>  > > +		add_taint(TAINT_PROPRIETARY_MODULE);
> >>  > > +
> >>  > > #ifdef CONFIG_MODULE_UNLOAD
> >>  > > 	/* Set up MODINFO_ATTR fields */
> >>  > > 	setup_modinfo(mod, sechdrs, infoindex);
> 
> (That's like putting the PCI name device database back in.)
> 
> 
> >You've hard-coded some module names, that itself `taints' the
> >kernel source IMO.  Blacklisting in kernel is both ugly and unacceptable.
> >
> >I agree that it would be convenient for you to only check if there's `Not tainted' in oops messages.  But I still suggest you to not hard-code them in the
> >kernel source.  Instead you could use some script to grep the problematic module
> >names in the `Modules linked in' field.
> >
> >For the long run, we could:
> >
> >1) Add some other mechanism, like MODULE_LICENSE_STRICT("GPL.strict").
> >
> >   GPL.strict:  A GPL.strict module is not only itself licensed under GPL,
> >   but it shall not load/link any binary code (specially non-gpl binaries)
> >   nor any non-GPL.strict code. This definition goes recursively.
> >
> 
> How are you going to verify that, how do you want to distinguish whether a
> certain byte range in memory (possibly beloaded with a windows driver) is prop
> or not?

Simple, I don't verify that.  But I know if a program is capable to link some
binary to itself, this program is no longer gpl.strict.  Whether it loads prop
or not depends on the user.  But at the time the author writes such programs,
the risk is open.

These binary-linking programs, under a gpl disguise, may look innocent, but they
are especially dangerous to the free world.  We need gpl.strict to keep away
from them.

-- 
Coywolf Qi Hunt