From: Dave Jones <davej@redhat.com>
To: "linux-os (Dick Johnson)" <linux-os@analogic.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Add tainting for proprietary helper modules.
Date: Mon, 5 Dec 2005 12:30:41 -0500 [thread overview]
Message-ID: <20051205173041.GE12664@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0512050832290.27133@chaos.analogic.com>
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
next prev parent reply other threads:[~2005-12-05 17:30 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 [this message]
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
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=20051205173041.GE12664@redhat.com \
--to=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-os@analogic.com \
/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