From: Coywolf Qi Hunt <qiyong@fc-cn.com>
To: Jan Engelhardt <jengelh@linux01.gwdg.de>
Cc: Dave Jones <davej@redhat.com>,
"linux-os (Dick Johnson)" <linux-os@analogic.com>,
linux-kernel@vger.kernel.org, rms@gnu.org, torvalds@osdl.org
Subject: Re: Add tainting for proprietary helper modules.
Date: Fri, 6 Jan 2006 19:41:43 +0800 [thread overview]
Message-ID: <20060106114143.GA9046@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.61.0601061139560.30781@yvahk01.tjqt.qr>
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
prev parent reply other threads:[~2006-01-06 11:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-03 0:41 Add tainting for proprietary helper modules Dave Jones
2005-12-03 0:58 ` Zan Lynx
2005-12-03 1:11 ` Dave Jones
2005-12-05 13:41 ` linux-os (Dick Johnson)
2005-12-05 17:30 ` Dave Jones
2005-12-05 17:34 ` Stephen Hemminger
2005-12-05 17:54 ` Mark Lord
2005-12-06 20:06 ` Alan Cox
2005-12-06 20:12 ` Brian Gerst
2005-12-06 20:28 ` Alan Cox
2005-12-06 21:34 ` Randy.Dunlap
2006-01-06 9:49 ` Coywolf Qi Hunt
2006-01-06 10:06 ` Xavier Bestel
2006-01-06 10:46 ` Jan Engelhardt
2006-01-06 11:41 ` Coywolf Qi Hunt [this message]
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060106114143.GA9046@localhost.localdomain \
--to=qiyong@fc-cn.com \
--cc=davej@redhat.com \
--cc=jengelh@linux01.gwdg.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-os@analogic.com \
--cc=rms@gnu.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox