>> > > 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]
