Re: Add tainting for proprietary helper modules.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>  > > 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 <[email protected]>
>>  > > Signed-off-by: Dave Jones <[email protected]>
>>  > >
>>  > > --- 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
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux