[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0801300129270.14907@fbirervta.pbzchgretzou.qr>
Date: Wed, 30 Jan 2008 01:35:58 +0100 (CET)
From: Jan Engelhardt <jengelh@...putergmbh.de>
To: Jon Masters <jonathan@...masters.org>
cc: Pavel Roskin <proski@....org>, linux-kernel@...r.kernel.org,
Rusty Russell <rusty@...tcorp.com.au>,
Giridhar Pemmasani <pgiri@...oo.com>
Subject: Re: ndiswrapper and GPL-only symbols redux
On Jan 29 2008 19:20, Jon Masters wrote:
>On Tue, 2008-01-29 at 16:22 -0500, Pavel Roskin wrote:
>>
>> It have come to my attention that a patch has been committed to the
>> kernel with the explicit purpose of tainting ndiswrapper - the kernel
>> module allowing Windows NDIS drivers for Ethernet and Wireless cards to
>> be used by the kernel.
>>
>> That's the commit in question:
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0aa5bd52d0c49ca56d24584c646e6544ccbb3dc9
>
>Yup. There was (what I thought was) a bug in the existing logic (an
>explicit match on "ndiswrapper", and a setting of the global kernel
>taint flags) and I corrected it to do what I thought it was actually
>intending to do, but hadn't been. Was I mistaken? What's the point of
>setting the global taint if we don't know why we set that?
ftr, as a by-stander, I perceived the past discussions as a lack of
trust from other kernel developers that Ndiswrapper will always set
the taint flags correctly. (ndiswrapper code does not go through lkml
review so the magic line might just change between tarballs.)
>> - ndiswrapper is licensed under GPL
>
>Yes it is. But I thought the existing code was intending to taint the
>kernel (that's what it does), so it would really help to identify why it
>tainted the kernel, by calling add_taint_module instead of add_taint. I
>didn't put the existing match in there...don't shoot the messenger :)
>
>> - ndiswrapper needs GPL-only symbols
>
>Another fix would be for ndiswrapper to explicitly set the taint when it
>loads a tainted driver? Or do we just want to go back to globally
>"tainting" the kernel without assigning the blame to any module?
I think the global taint flag is always needed because you never know
what the proprietary module actually did to our memory. Unloading
the driver and ndiswrapper should retain some sort of taintedness
should it oops much later.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists