[PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Pavel Roskin]

A change after 2.6.24 broke ndiswrapper by accidentally removing its
access to GPL-only symbols.  Revert that change and add comments about
the reasons why ndiswrapper and driverloader are treated in a special
way.

Signed-off-by: Pavel Roskin <proski@gnu.org>
---

 kernel/module.c |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)


diff --git a/kernel/module.c b/kernel/module.c
index 901cd6a..a11f523 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1933,8 +1933,15 @@ static struct module *load_module(void __user *umod,
 	/* Set up license info based on the info section */
 	set_license(mod, get_modinfo(sechdrs, infoindex, "license"));
 
+	/*
+	 * ndiswrapper is under GPL by itself, but loads proprietary modules.
+	 * Don't use add_taint_module(), as it would prevent ndiswrapper from
+	 * using GPL-only symbols it needs.
+	 */
 	if (strcmp(mod->name, "ndiswrapper") == 0)
-		add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
+		add_taint(TAINT_PROPRIETARY_MODULE);
+
+	/* driverloader was caught wrongly pretending to be under GPL */
 	if (strcmp(mod->name, "driverloader") == 0)
 		add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
 

-- 
Regards,
Pavel Roskin

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Linus Torvalds]

On Thu, 28 Feb 2008, Pavel Roskin wrote:
>
> A change after 2.6.24 broke ndiswrapper by accidentally removing its
> access to GPL-only symbols.  Revert that change and add comments about
> the reasons why ndiswrapper and driverloader are treated in a special
> way.

I'm not seeing why ndiswrapper should be treated separately.

If it loads non-GPL modules, it shouldn't be able to use GPLONLY symbols.

So if ndiswrapper needs GPL-only symbols, you'd better ask the people who 
made those symbols GPL-only whether they could be made available to 
ndiswrapper.

ndiswrapper itself is *not* compatible with the GPL. Trying to claim that 
ndiswrapper somehow itself is GPL'd even though it then loads modules that 
aren't is stupid and pointless. Clearly it just re-exports those GPLONLY 
functions to code that is *not* GPL'd.

		Linus

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Pavel Roskin]

Quoting Linus Torvalds <torvalds@linux-foundation.org>:

> On Thu, 28 Feb 2008, Pavel Roskin wrote:
>>
>> A change after 2.6.24 broke ndiswrapper by accidentally removing its
>> access to GPL-only symbols.  Revert that change and add comments about
>> the reasons why ndiswrapper and driverloader are treated in a special
>> way.
>
> I'm not seeing why ndiswrapper should be treated separately.

It is already treated separately, and has been for a long time.  Since  
ndiswrapper taints itself when it loads a proprietary NDIS module, I  
don't think any special treatment is needed anymore, but that's beyond  
my point.

All I'm trying to do it to revert a patch that, as its author  
admitted, had unexpected consequences:
http://kerneltrap.org/mailarchive/linux-kernel/2008/1/30/648044

> If it loads non-GPL modules, it shouldn't be able to use GPLONLY symbols.

This is not the original intention of GPLONLY.  GPLONLY exists to  
prevent loading of modules that are proprietary, but can be considered  
to be Linux derivatives due to their use of Linux specific API.

In case of ndiswrapper, there is no question that ndiswrapper is a  
Linux derivative, but it's under GPL.  Yet the proprietary modules are  
not Linux derivatives because they don't use Linux API.  In fact, they  
were never intended to run on Linux.

By using GPLONLY to exclude ndiswrapper, you would give GPLONLY an  
additional meaning, namely functions that are not available to  
ndiswrapper.

> So if ndiswrapper needs GPL-only symbols, you'd better ask the people who
> made those symbols GPL-only whether they could be made available to
> ndiswrapper.

That would mean that I would have to ask those symbols to be opened to  
proprietary Linux kernel modules as well, which is not my intention.

> ndiswrapper itself is *not* compatible with the GPL. Trying to claim that
> ndiswrapper somehow itself is GPL'd even though it then loads modules that
> aren't is stupid and pointless. Clearly it just re-exports those GPLONLY
> functions to code that is *not* GPL'd.

Simple re-exporting would be useless.  It's a wrapper that isolates  
NDIS API from Linux API.  Anything Linux specific is in ndiswrapper  
itself.  The proprietary modules call only NDIS functions.

I believe, the license is a choice of the copyright holders.  Apart  
from that, I don't feel qualified to discuss any legal matters.

-- 
Regards,
Pavel Roskin

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Linus Torvalds]

On Fri, 29 Feb 2008, Pavel Roskin wrote:
> > 
> > I'm not seeing why ndiswrapper should be treated separately.
> 
> It is already treated separately, and has been for a long time.

No, I mean "separately from the thing it loads".

It loads non-GPL code, it is non-GPL.

> > If it loads non-GPL modules, it shouldn't be able to use GPLONLY symbols.
> 
> This is not the original intention of GPLONLY.  GPLONLY exists to prevent
> loading of modules that are proprietary, but can be considered to be Linux
> derivatives due to their use of Linux specific API.

Exactly. And ndiswrapper loads proprietary modules.

You're not following the argument. There was a reason ndiswrapper was 
marked for tainting. 

			Linus

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Chris Friesen]

Linus Torvalds wrote:
> 
> On Fri, 29 Feb 2008, Pavel Roskin wrote:
> 
>>>I'm not seeing why ndiswrapper should be treated separately.
>>
>>It is already treated separately, and has been for a long time.
> 
> 
> No, I mean "separately from the thing it loads".
> 
> It loads non-GPL code, it is non-GPL.

But the GPL only applies to derivative works.  Given that ndiswrapper 
loads binaries designed for another OS, doesn't that mean that it is 
unlikely that the binaries would be impacted by the GPL?

So the portion that is a derivative work (ndiswrapper itself) is GPL, 
and it loads something that is clearly not a derivative work.  From a 
licensing standpoint how is this different than an open-source driver 
loading a proprietary firmware?

Once ndiswrapper loads the binary blob the kernel should be considered 
tainted from a debuggability standpoint, but I have some sympathy for an 
argument suggesting that ndiswrapper should be able to use GPLONLY symbols.

Chris

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Linus Torvalds]

On Fri, 29 Feb 2008, Chris Friesen wrote:
>
> But the GPL only applies to derivative works.  Given that ndiswrapper loads
> binaries designed for another OS, doesn't that mean that it is unlikely that
> the binaries would be impacted by the GPL?

But that's what GPLONLY means.

What's so hard to understand? The driver may not be a derivative work, but 
it sure as hell isn't GPL'd. 

So stop blathering. ndiswrapper has one purpose, and one purpose only: to 
load non-GPL'd code. So OF COURSE it shouldn't touch GPLONLY functions.

		Linus

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Chris Friesen]

Linus Torvalds wrote:
> 
> On Fri, 29 Feb 2008, Chris Friesen wrote:
> 
>>But the GPL only applies to derivative works.  Given that ndiswrapper loads
>>binaries designed for another OS, doesn't that mean that it is unlikely that
>>the binaries would be impacted by the GPL?
> 
> 
> But that's what GPLONLY means.
> 
> What's so hard to understand? The driver may not be a derivative work, but 
> it sure as hell isn't GPL'd. 

I hope this won't dump me into the flamers filter....but here goes:

If the intent of the GPLONLY export is really to keep the symbol from 
being used by non-GPL code then I agree that ndiswrapper shouldn't be 
able to use them.

However, you yourself wrote something stating otherwise: 
(http://groups.google.ca/group/linux.kernel/msg/0066655bb1be1e4c):

'I think we _can_ do things where we give clear hints to people that "we
think this is such an internal Linux thing that you simply cannot use 
this without being considered a derived work".....So I personally don't 
see EXPORT_SYMBOL_GPL() to be a "technical measure", I see it as being 
"documentation".'

Under that interpretation, ndiswrapper should be able to make use of 
GPLONLY symbols because the binary blobs are clearly not derivative works.

Chris

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[David Woodhouse]

On Fri, 2008-02-29 at 10:54 -0600, Chris Friesen wrote:
> But the GPL only applies to derivative works. 

Not entirely true -- or at least somewhat misleading as phrased.

There are cases where the GPL clearly states that it _does_ apply to
sections of code which are "independent and separate works in
themselves".

-- 
dwmw2

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Zan Lynx]

[-- Attachment #1: Type: text/plain, Size: 551 bytes --]


On Fri, 2008-02-29 at 08:08 -0800, Linus Torvalds wrote:
[cut]
> It loads non-GPL code, it is non-GPL.
[cut]
> Exactly. And ndiswrapper loads proprietary modules.

The Linux kernel itself will load proprietary modules.  It does not as a
general rule, but it will.

Is the Linux kernel then not GPL?  No.  This argument doesn't work,
Linus.

There exists at least one GPL NDIS driver[1].  How about if everyone
involved piously promises to load it at least once?

[1] http://cipe-win32.sourceforge.net/
-- 
Zan Lynx <zlynx@acm.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Linus Torvalds]

On Fri, 29 Feb 2008, Zan Lynx wrote:
> 
> The Linux kernel itself will load proprietary modules.  It does not as a
> general rule, but it will.

.. and it doesn't export GPLONLY modules to them.

How stupid do you have to be to not understand that?

		Linus

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Pavel Roskin]

On Fri, 2008-02-29 at 09:07 -0800, Linus Torvalds wrote:
> 
> On Fri, 29 Feb 2008, Zan Lynx wrote:
> > 
> > The Linux kernel itself will load proprietary modules.  It does not as a
> > general rule, but it will.
> 
> .. and it doesn't export GPLONLY modules to them.
> 
> How stupid do you have to be to not understand that?

Actually, it's a flawed comparison.  The only thing ndiswrapper exports
to NDIS modules is NDIS API.  GPLONLY symbols are only used to implement
that API in the code that's under GPL.  That's the code you can fork,
change and redistribute.

-- 
Regards,
Pavel Roskin

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Linus Torvalds]

On Fri, 29 Feb 2008, Pavel Roskin wrote:
> 
> Actually, it's a flawed comparison.  The only thing ndiswrapper exports
> to NDIS modules is NDIS API.  GPLONLY symbols are only used to implement
> that API in the code that's under GPL.  That's the code you can fork,
> change and redistribute.

.. and it's stuill just a wrapper.

A fairly thick one, but still...

More importantly, none of the people arguing against this at all even 
reacted to my suggestion for how to fix things *properly* in my original 
email. Which just means that you're apparently not interested in actually 
fixing this, you're just trying to disagree about some interpretation of 
GPLONLY.

In other words: the next person who can't even be bothered to tell what 
symbols are involved and why they haven't asked whether those symbols 
could instead be relaxed, automaticaly will go into my "flamers" filter, 
and just stay there. Then you can complain as much as you like, and I'll 
never see it.

		Linus

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Pavel Roskin]

On Fri, 2008-02-29 at 09:33 -0800, Linus Torvalds wrote:
> 
> On Fri, 29 Feb 2008, Pavel Roskin wrote:
> > 
> > Actually, it's a flawed comparison.  The only thing ndiswrapper exports
> > to NDIS modules is NDIS API.  GPLONLY symbols are only used to implement
> > that API in the code that's under GPL.  That's the code you can fork,
> > change and redistribute.
> 
> .. and it's stuill just a wrapper.
> 
> A fairly thick one, but still...

So it the Linux syscall interface.  It's a wrapper around the kernel
internals, including GPLONLY symbols.  Yet some userspace programs are
proprietary.

> More importantly, none of the people arguing against this at all even 
> reacted to my suggestion for how to fix things *properly* in my original 
> email. Which just means that you're apparently not interested in actually 
> fixing this, you're just trying to disagree about some interpretation of 
> GPLONLY.

I'm actually interested in fixing this, or I would not have sent a
patch.

> In other words: the next person who can't even be bothered to tell what 
> symbols are involved and why they haven't asked whether those symbols 
> could instead be relaxed, automaticaly will go into my "flamers" filter, 
> and just stay there. Then you can complain as much as you like, and I'll 
> never see it.

Well, here's the list

__create_workqueue_key
destroy_workqueue
flush_workqueue
queue_work
task_nice
usb_alloc_urb
usb_buffer_alloc
usb_buffer_free
usb_clear_halt
usb_control_msg
usb_deregister
usb_free_urb
usb_get_current_frame_number
usb_get_descriptor
usb_get_status
usb_ifnum_to_if
usb_init_urb
usb_kill_urb
usb_lock_device_for_reset
usb_register_driver
usb_reset_configuration
usb_reset_device
usb_set_interface
usb_submit_urb
usb_unlink_urb

I already know what USB folks will say.  They want proprietary drivers
to be in the userspace.  I doubt ndiswrapper will ever be ported to the
userspace.  It's much more likely that some other approach will be used.

-- 
Regards,
Pavel Roskin

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Linus Torvalds]

On Fri, 29 Feb 2008, Pavel Roskin wrote:
> 
> I already know what USB folks will say.  They want proprietary drivers
> to be in the userspace.  I doubt ndiswrapper will ever be ported to the
> userspace.  It's much more likely that some other approach will be used.

If that's the case, then talk to the USB people. Maybe they are ok with 
wrapping them in GPL wrappers. But it sounds like they would prefer the 
stricter GPLONLY meaning (ie no ndiswrapper), and it's their code.

			Linus

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Pavel Roskin]

On Fri, 2008-02-29 at 11:53 -0800, Linus Torvalds wrote:
> 
> On Fri, 29 Feb 2008, Pavel Roskin wrote:
> > 
> > I already know what USB folks will say.  They want proprietary drivers
> > to be in the userspace.  I doubt ndiswrapper will ever be ported to the
> > userspace.  It's much more likely that some other approach will be used.
> 
> If that's the case, then talk to the USB people. Maybe they are ok with 
> wrapping them in GPL wrappers. But it sounds like they would prefer the 
> stricter GPLONLY meaning (ie no ndiswrapper), and it's their code.

This still leaves us with the workqueue interface:

__create_workqueue_key
destroy_workqueue
flush_workqueue
queue_work

ndiswrapper has its own workqueue implementation, but it would be great
to avoid code duplication.

As for task_nice(), it's strange that task_nice() is GPLONLY, but
set_user_nice() is not.  Anyway, it can probably be worked around.

-- 
Regards,
Pavel Roskin

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Linus Torvalds]

On Fri, 29 Feb 2008, Pavel Roskin wrote:
> 
> This still leaves us with the workqueue interface:
> 
> __create_workqueue_key
> destroy_workqueue
> flush_workqueue
> queue_work

Hmm. Personally, I don't see those as being a big issue, but they've been 
marked GPL-only for a long while. 

The thing is, I personally don't mind, and I think "derived code" is what 
matters, but others disagree, and quite frankly, I'm not going to force 
them - I have my _personal_ beliefs, but hey, others have theirs.

So you really need to talk to not me, but to the people who actually wrote 
and maintain that code. When they come back and say "yeah, we think 
ndiswrapper is a special case and we're ok with it", I'll happily either 
mark those things non-GPL or just mark ndiswrapper special in the module 
loader again.

Quite frankly, I don't care about ndiswrapper enough (at all) to push this 
along in the least. 

		Linus

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Pavel Roskin]

On Fri, 2008-02-29 at 12:28 -0800, Linus Torvalds wrote:
> 
> On Fri, 29 Feb 2008, Pavel Roskin wrote:
> > 
> > This still leaves us with the workqueue interface:
> > 
> > __create_workqueue_key
> > destroy_workqueue
> > flush_workqueue
> > queue_work
> 
> Hmm. Personally, I don't see those as being a big issue, but they've been 
> marked GPL-only for a long while. 
> 
> The thing is, I personally don't mind, and I think "derived code" is what 
> matters, but others disagree, and quite frankly, I'm not going to force 
> them - I have my _personal_ beliefs, but hey, others have theirs.
>
> So you really need to talk to not me, but to the people who actually wrote 
> and maintain that code.

As far as I can tell, those people have never tried to prevent
ndiswrapper from using their code.  Both times ndiswrapper was prevented
from using GPLONLY symbols, it was done unintentionally.

> When they come back and say "yeah, we think 
> ndiswrapper is a special case and we're ok with it", I'll happily either 
> mark those things non-GPL or just mark ndiswrapper special in the module 
> loader again.

OK, I'll keep it in mind in case such approach actually becomes
necessary.

-- 
Regards,
Pavel Roskin

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[John W. Linville]

On Fri, Feb 29, 2008 at 02:39:38PM -0500, Pavel Roskin wrote:

> I doubt ndiswrapper will ever be ported to the
> userspace.  It's much more likely that some other approach will be used.

Maybe it should be -- that might solve a lot of problems.

-- 
John W. Linville
linville@tuxdriver.com

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[David Newall]

John W. Linville wrote:
> On Fri, Feb 29, 2008 at 02:39:38PM -0500, Pavel Roskin wrote:
>   
>> I doubt ndiswrapper will ever be ported to the
>> userspace.  It's much more likely that some other approach will be used.
>>     
>
> Maybe it should be -- that might solve a lot of problems

Maybe it's time to rename it from "ndiswrapper" to "NdisWrapper".

How stupid do you have to be to not see that it will be fixed in any way
necessary.

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Pavel Roskin]

On Sat, 2008-03-01 at 07:10 +1030, David Newall wrote:
> John W. Linville wrote:
> > On Fri, Feb 29, 2008 at 02:39:38PM -0500, Pavel Roskin wrote:
> >   
> >> I doubt ndiswrapper will ever be ported to the
> >> userspace.  It's much more likely that some other approach will be used.
> >>     
> >
> > Maybe it should be -- that might solve a lot of problems
> 
> Maybe it's time to rename it from "ndiswrapper" to "NdisWrapper".
> 
> How stupid do you have to be to not see that it will be fixed in any way
> necessary.

I'm quite sure that something like that is going to be the short term
fix.  Still, it would be nice to have a more long term solution, the one
that tries to resolve the tensions rather than hide them.  I'm not sure
it's possible, but just trying to negotiate could help find
understanding.

-- 
Regards,
Pavel Roskin

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[David Newall]

Pavel Roskin wrote:
> On Sat, 2008-03-01 at 07:10 +1030, David Newall wrote:
>   
>> John W. Linville wrote:
>>     
>>> On Fri, Feb 29, 2008 at 02:39:38PM -0500, Pavel Roskin wrote:
>>>   
>>>       
>>>> I doubt ndiswrapper will ever be ported to the
>>>> userspace.  It's much more likely that some other approach will be used.
>>>>     
>>>>         
>>> Maybe it should be -- that might solve a lot of problems
>>>       
>> Maybe it's time to rename it from "ndiswrapper" to "NdisWrapper".
>>
>> How stupid do you have to be to not see that it will be fixed in any way
>> necessary.
>>     
>
> I'm quite sure that something like that is going to be the short term
> fix.  Still, it would be nice to have a more long term solution, the one
> that tries to resolve the tensions rather than hide them.  I'm not sure
> it's possible, but just trying to negotiate could help find
> understanding

I think there's a political agenda, and that's something that nobody can
solve.  The simplest solution is to change the name it uses on a regular
basis, and that something relatively  unimportant.  People will still
call it ndiswrapper, but it will identify itself to the kernel as
wrappythingy, and then ndisthingy, and then wrapndis.  Heck, make it
purely random.  Solve the problem for all time.

It's a stupid problem promulgated by stupid people, and I use the word
"stupid" in it's most pejorative sense.

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Pavel Roskin]

On Sat, 2008-03-01 at 07:38 +1030, David Newall wrote:

> I think there's a political agenda, and that's something that nobody can
> solve.  The simplest solution is to change the name it uses on a regular
> basis, and that something relatively  unimportant.  People will still
> call it ndiswrapper, but it will identify itself to the kernel as
> wrappythingy, and then ndisthingy, and then wrapndis.  Heck, make it
> purely random.  Solve the problem for all time.

If there is a political agenda, then LKML is the worst place to discuss
the details.

> It's a stupid problem promulgated by stupid people, and I use the word
> "stupid" in it's most pejorative sense.

It would be more useful if you counter specific arguments rather than
employ ad hominem attacks.

-- 
Regards,
Pavel Roskin

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[David Newall]

Pavel Roskin wrote:
> On Sat, 2008-03-01 at 07:38 +1030, David Newall wrote:
>   
>> It's a stupid problem promulgated by stupid people, and I use the word
>> "stupid" in it's most pejorative sense.
>>     
>
> It would be more useful if you counter specific arguments rather than
> employ ad hominem attacks.

True.  Somebody had just said something quite similar, which undoubtedly
is what brought the thought to mind.  However, it is a stupid problem,
and all of the arguments have already been done to death.  Nothing
remains to be said, and the sensible strategy now is just to work around
the stupid blocks and ignore any fools who care to howl.  Also, working
around the blocks serves as a useful object lesson to everybody who has
forgotten that the point of the GPL is to provide freedom to innovate
and change, not to restrict it.

Just do it.

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Pavel Roskin]

On Fri, 2008-02-29 at 15:17 -0500, John W. Linville wrote:
> On Fri, Feb 29, 2008 at 02:39:38PM -0500, Pavel Roskin wrote:
> 
> > I doubt ndiswrapper will ever be ported to the
> > userspace.  It's much more likely that some other approach will be used.
> 
> Maybe it should be -- that might solve a lot of problems.

I doubt it can be done for PCI due to DMA use by some of the drivers.

Perhaps it could be done for USB, but I doubt anyone will bother.

-- 
Regards,
Pavel Roskin

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Ingo Molnar]

* Pavel Roskin <proski@gnu.org> wrote:

> I already know what USB folks will say.  They want proprietary drivers 
> to be in the userspace.  I doubt ndiswrapper will ever be ported to 
> the userspace.  It's much more likely that some other approach will be 
> used.

btw., what are the technical reasons why ndiswrapper cannot be done in 
userspace, much like the (wildly successful) FUSE concept?

what's the main hardware access method of ndiswrapper - only PIO, or 
mmio as well? In the former case, ioperm() should work, in the latter 
case, mmap()ing the device aperture should work.

Frankly, it would be a great approach for the following reason: it would 
be _far_ easier for people to write a proper free driver, if the NDIS 
driver was in user-space, in a nicely debuggable, traceable, observable 
environment. I dont really see what the technical difficulties there are 
here.

	Ingo

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Pavel Roskin]

On Fri, 2008-02-29 at 22:15 +0100, Ingo Molnar wrote:
> * Pavel Roskin <proski@gnu.org> wrote:
> 
> > I already know what USB folks will say.  They want proprietary drivers 
> > to be in the userspace.  I doubt ndiswrapper will ever be ported to 
> > the userspace.  It's much more likely that some other approach will be 
> > used.
> 
> btw., what are the technical reasons why ndiswrapper cannot be done in 
> userspace, much like the (wildly successful) FUSE concept?

ndiswrapper contains essentially two drivers in one - PCI and USB.  The
PCI driver uses DMA, which should be a strong argument for keeping it in
the kernel.

As for the USB driver, it may be possible, but some infrastructure may
still be missing.

ndiswrapper needs to register network devices.  For wireless devices, it
needs to be a device with wireless extension support.  I don't think
it's currently possible from the userspace.

> what's the main hardware access method of ndiswrapper - only PIO, or 
> mmio as well? In the former case, ioperm() should work, in the latter 
> case, mmap()ing the device aperture should work.

Both.  I'm afraid DMA is the real problem here.

> Frankly, it would be a great approach for the following reason: it would 
> be _far_ easier for people to write a proper free driver, if the NDIS 
> driver was in user-space, in a nicely debuggable, traceable, observable 
> environment. I dont really see what the technical difficulties there are 
> here.

I agree that it would be great, but it's quite a lot of work.

-- 
Regards,
Pavel Roskin

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Ingo Molnar]

* Pavel Roskin <proski@gnu.org> wrote:

> > btw., what are the technical reasons why ndiswrapper cannot be done 
> > in userspace, much like the (wildly successful) FUSE concept?
> 
> ndiswrapper contains essentially two drivers in one - PCI and USB.  
> The PCI driver uses DMA, which should be a strong argument for keeping 
> it in the kernel.

how exactly does it use DMA - how does it allocate the memory it later 
on DMAs into, and how does it typically program that DMA target - is 
there any control over that in the NDIS protocol - or will NDIS drivers 
just write random addresses to the mmio space and then the hardware does 
DMA to/from those addresses? [without the NDIS framework having any 
knowledge about the encoding of those bits?]

on modern hardware it might even be possible to jail an ndiswrapper 
driver to its own pages via the IOMMU.

	Ingo

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Pavel Roskin]

Quoting Ingo Molnar <mingo@elte.hu>:

>
> * Pavel Roskin <proski@gnu.org> wrote:
>
>> > btw., what are the technical reasons why ndiswrapper cannot be done
>> > in userspace, much like the (wildly successful) FUSE concept?
>>
>> ndiswrapper contains essentially two drivers in one - PCI and USB.
>> The PCI driver uses DMA, which should be a strong argument for keeping
>> it in the kernel.
>
> how exactly does it use DMA - how does it allocate the memory it later
> on DMAs into, and how does it typically program that DMA target - is
> there any control over that in the NDIS protocol - or will NDIS drivers
> just write random addresses to the mmio space and then the hardware does
> DMA to/from those addresses? [without the NDIS framework having any
> knowledge about the encoding of those bits?]

Sorry for delay.  I'm really not sure.  The maintainer of ndiswrapper  
is currently offline, and I'm just trying to take care of the basic  
stuff.

All I can say is NdisMAllocateSharedMemory maps to  
dma_alloc_coherent(), and there are some references to scatter-gather  
lists.  There is a call to dma_map_single(), which is ultimately  
called by the Tx function net_dev->hard_start_xmit.

I understand there is some control from NDIS.  At least it can request  
memory available for DMA.

> on modern hardware it might even be possible to jail an ndiswrapper
> driver to its own pages via the IOMMU.

It's possible that ndiswrapper would support Vista drivers only on  
x86_64, which should always have IOMMU, if I understand correctly.   
But it would be nice to have proper support for older XP drivers on x86.

-- 
Regards,
Pavel Roskin

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Ingo Molnar]

* Pavel Roskin <proski@gnu.org> wrote:

>>> ndiswrapper contains essentially two drivers in one - PCI and USB. 
>>> The PCI driver uses DMA, which should be a strong argument for 
>>> keeping it in the kernel.
>>
>> how exactly does it use DMA - how does it allocate the memory it 
>> later on DMAs into, and how does it typically program that DMA target 
>> - is there any control over that in the NDIS protocol - or will NDIS 
>> drivers just write random addresses to the mmio space and then the 
>> hardware does DMA to/from those addresses? [without the NDIS 
>> framework having any knowledge about the encoding of those bits?]
>
> Sorry for delay.  I'm really not sure.  The maintainer of ndiswrapper 
> is currently offline, and I'm just trying to take care of the basic 
> stuff.
>
> All I can say is NdisMAllocateSharedMemory maps to 
> dma_alloc_coherent(), and there are some references to scatter-gather 
> lists.  There is a call to dma_map_single(), which is ultimately 
> called by the Tx function net_dev->hard_start_xmit.
>
> I understand there is some control from NDIS.  At least it can request 
> memory available for DMA.

so ... i suspect the requirement would be for 
NdisMAllocateSharedMemory() to return a linear address that is DMA-able, 
and to properly map it to a physical address via dma_map_single(). I can 
see only one complication in pushing this to user-space: physical 
fragmentation of allocations. What are the typical buffer sizes that 
NDIS drivers request from the kernel? Is it frequently above 4K?

you could try to create a syscall-ish API towards the kernel that allows 
DMA, it would have the following functionality:

- allocate a piece of continuous memory and return its physical address
  plus its linear address as well and map the linear address into the
  user-space pagetables. This memory would be unfragmented on the 
  physical side.

you probably could even use/hack hugetlbfs right now to achieve 
something very similar. (hugetlbfs pages are unfragmented 2MB 
largepages)

if the NDIS API is done halfways right, then there's no need for any of 
these buffers to be in kernel-space and for the driver to run in kernel 
space.

i think someone should really try to push a known-well-behaving NDIS 
driver (for which a Linux driver exists too) down to user-space. NDIS 
has been around since Netware so it's a pretty well-understood driver 
model. And with an iommu it could all be made a safe sandbox as well (an 
NDIS device could never exit its sandbox).

	Ingo

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Linus Torvalds]

On Tue, 4 Mar 2008, Ingo Molnar wrote:
> 
> so ... i suspect the requirement would be for 
> NdisMAllocateSharedMemory() to return a linear address that is DMA-able, 
> and to properly map it to a physical address via dma_map_single(). I can 
> see only one complication in pushing this to user-space: physical 
> fragmentation of allocations. What are the typical buffer sizes that 
> NDIS drivers request from the kernel? Is it frequently above 4K?

Ingo, i's simply not possible to put ndiswrapper in user-space sanely.

Drivers are drivers. They'll want (shared) interrupts, they want DMA, they 
want to do things like cli/sti. 

The USB drivers *may* be abstracted enough that they don't do any of that, 
but quite frankly, I doubt it.

> if the NDIS API is done halfways right, then there's no need for any of 
> these buffers to be in kernel-space and for the driver to run in kernel 
> space.

Don't be silly. When you claim this is the only way things are "halfway 
right", then none of the Linux kernel driver interfaces are even *close* 
to halfway right. Sure, the NDIS ABI has to b more abstracted than the 
Linux kernel one (because it's a binary ABI that survives over multiple 
Windows versions, not a source code API), but the fact is, NDIS is 
designed for kernel-mode, not user mode.

So asking people to make ndiswrapper be user-mode only is simply not 
realistic.

The question on the table is not whether we can make it user-mode 
(especially since no major kernel contributor is likely to even care 
enough to really help code anyway), but whether we should let ndiswrapper 
continue using GPLONLY symbols.

Quite frankly, my position on this has always been that the GPLv2 
explicitly covers _derived_ works only, and that very obviously a Windows 
driver isn't a derived work of the kernel. So as far as I'm concerned, 
ndiswrapper may be distasteful froma technical and support angle, but not 
against the license.

So I'm personally perfectly happy to say that we should revert that commit 
0aa5bd52d0c49ca56d24584c646e6544ccbb3dc9, but what I've wanted to hear 
from the very beginning was simply to get a list of symbols that currently 
clash, and hear from the people who maintain the symbols whether they 
really meant for that commit to be valid.

That's the only issue here. Not whether ndiswrapper could do a part of its 
job in user space (because the answer to that latter question is: no. 
Everything is "possible", of course, but realistically, that's simply not 
going to happen).

It sounds like there aren't that many symbols affected at the core: the 
workqueue stuff certainly isn't worth bothering about. The USB things that 
ndiswrapper wants is much more involved, and more likely to have issues, 
but I'm cc'ing Greg here to see.

IOW: I _personally_ don't think there are any license issues, but I do 
want to have the situation clear to people involved.

		Linus

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Greg KH]

On Tue, Mar 04, 2008 at 09:19:36AM -0800, Linus Torvalds wrote:
> Quite frankly, my position on this has always been that the GPLv2 
> explicitly covers _derived_ works only, and that very obviously a Windows 
> driver isn't a derived work of the kernel. So as far as I'm concerned, 
> ndiswrapper may be distasteful froma technical and support angle, but not 
> against the license.

I think ndiswrapper is a great hack from a technical point-of-view.  But
yes, I also do not think it is a violation of the GPLv2 for the same
reasons you do.

> So I'm personally perfectly happy to say that we should revert that commit 
> 0aa5bd52d0c49ca56d24584c646e6544ccbb3dc9, but what I've wanted to hear 
> from the very beginning was simply to get a list of symbols that currently 
> clash, and hear from the people who maintain the symbols whether they 
> really meant for that commit to be valid.
> 
> That's the only issue here. Not whether ndiswrapper could do a part of its 
> job in user space (because the answer to that latter question is: no. 
> Everything is "possible", of course, but realistically, that's simply not 
> going to happen).
> 
> It sounds like there aren't that many symbols affected at the core: the 
> workqueue stuff certainly isn't worth bothering about. The USB things that 
> ndiswrapper wants is much more involved, and more likely to have issues, 
> but I'm cc'ing Greg here to see.

I have no objection to reverting that patch to have nidiswrapper access
to those symbols, especially as that is really the only way they will be
able to control USB devices (as you state, doing a network driver in
userspace doesn't really make sense.)

thanks,

greg k-h

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Pavel Roskin]

On Tue, 2008-03-04 at 09:19 -0800, Linus Torvalds wrote:

> Ingo, i's simply not possible to put ndiswrapper in user-space sanely.
> 
> Drivers are drivers. They'll want (shared) interrupts, they want DMA, they 
> want to do things like cli/sti. 

Agreed.

> The USB drivers *may* be abstracted enough that they don't do any of that, 
> but quite frankly, I doubt it.

And even then, we need a network interface in the kernel, which would
possibly support wireless extensions.

And most importantly, I don't think anyone will bother rewriting
ndiswrapper.  It's a popular project amongst users, but it suffers from
little attention of developers.

> So asking people to make ndiswrapper be user-mode only is simply not 
> realistic.

Agreed.

> The question on the table is not whether we can make it user-mode 
> (especially since no major kernel contributor is likely to even care 
> enough to really help code anyway), but whether we should let ndiswrapper 
> continue using GPLONLY symbols.

Yes.

> Quite frankly, my position on this has always been that the GPLv2 
> explicitly covers _derived_ works only, and that very obviously a Windows 
> driver isn't a derived work of the kernel. So as far as I'm concerned, 
> ndiswrapper may be distasteful froma technical and support angle, but not 
> against the license.

Nice to hear that.

> So I'm personally perfectly happy to say that we should revert that commit 
> 0aa5bd52d0c49ca56d24584c646e6544ccbb3dc9, but what I've wanted to hear 
> from the very beginning was simply to get a list of symbols that currently 
> clash, and hear from the people who maintain the symbols whether they 
> really meant for that commit to be valid.

To recap:

1) USB API
2) Workqueue API (there is a hackish replacement in ndiswrapper)
3) task_nice(), but I have a trivial workaround for that.

> That's the only issue here. Not whether ndiswrapper could do a part of its 
> job in user space (because the answer to that latter question is: no. 
> Everything is "possible", of course, but realistically, that's simply not 
> going to happen).
> 
> It sounds like there aren't that many symbols affected at the core: the 
> workqueue stuff certainly isn't worth bothering about. The USB things that 
> ndiswrapper wants is much more involved, and more likely to have issues, 
> but I'm cc'ing Greg here to see.
> 
> IOW: I _personally_ don't think there are any license issues, but I do 
> want to have the situation clear to people involved.

Let me explain my position.  Using of GPL-only symbols by ndiswrapper
has been tolerated for years.  The change was not even intended to stop
it.  It was a side effect.

As it stands now, I don't want to be in the position to ask anyone to
add extra support to recognize ndiswrapper or to have some ugly
EXPORT_SYMBOL_GPL_OR_NDISWRAPPER.

Believe me, I don't want to be uncooperative.  But I think I'll be in
the position to ask for exceptions for ndiswrapper only if somebody is
actively and _intentionally_ looking to prevent it from using GPL-only
symbols.  That's why if nothing changes in the kernel, ndiswrapper will
be renamed.  This way we'll see if anyone actually cares enough to block
ndiswrapper again.  And in this situation, I'll be in a better position
to ask authors of the workqueue API and USB for an explicit exception.

-- 
Regards,
Pavel Roskin

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Ingo Molnar]

* Pavel Roskin <proski@gnu.org> wrote:

> To recap:
> 
> 1) USB API
> 2) Workqueue API (there is a hackish replacement in ndiswrapper)
> 3) task_nice(), but I have a trivial workaround for that.

task_nice() - it's trivial so feel free to send a patch that turns it 
into EXPORT_SYMBOL().

	Ingo

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Pavel Roskin]

On Tue, 2008-03-04 at 22:20 +0100, Ingo Molnar wrote:
> * Pavel Roskin <proski@gnu.org> wrote:
> 
> > To recap:
> > 
> > 1) USB API
> > 2) Workqueue API (there is a hackish replacement in ndiswrapper)
> > 3) task_nice(), but I have a trivial workaround for that.
> 
> task_nice() - it's trivial so feel free to send a patch that turns it 
> into EXPORT_SYMBOL().

The recent discussion makes me nervous about sending any patches of such
kind.  Instead of getting access task_nice(), ndiswrapper could lose
access to set_user_nice() or something else.

It's bad already that a mistaken commit has turned into a permanent
restriction for ndiswrapper after my intervention :-(

-- 
Regards,
Pavel Roskin

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Tue, 4 Mar 2008, Ingo Molnar wrote:
> > 
> > so ... i suspect the requirement would be for 
> > NdisMAllocateSharedMemory() to return a linear address that is 
> > DMA-able, and to properly map it to a physical address via 
> > dma_map_single(). I can see only one complication in pushing this to 
> > user-space: physical fragmentation of allocations. What are the 
> > typical buffer sizes that NDIS drivers request from the kernel? Is 
> > it frequently above 4K?
> 
> Ingo, i's simply not possible to put ndiswrapper in user-space sanely.
> 
> Drivers are drivers. They'll want (shared) interrupts, they want DMA, 
> they want to do things like cli/sti.
> 
> The USB drivers *may* be abstracted enough that they don't do any of
> that, but quite frankly, I doubt it.

yeah, i agree that putting it into userspace is quite insane.

it might possible to do it halfways sanely via existing arch/x86/kvm/ 
infrastructure though. VMX/SVM context will properly emulate the IRQ 
flag so cli/sti will work fine, and as long as DMA is properly 
quarantined via an iommu it might even not corrupt the rest of the 
system. Right now KVM is tailored for full system emulation but there's 
no strong reason why it couldnt emulate just a single hardware domain, 
with an NDIS driver sitting in that domain - talking to the rest of the 
system via hypercalls.

> It sounds like there aren't that many symbols affected at the core: 
> the workqueue stuff certainly isn't worth bothering about. The USB 
> things that ndiswrapper wants is much more involved, and more likely 
> to have issues, but I'm cc'ing Greg here to see.
> 
> IOW: I _personally_ don't think there are any license issues, but I do 
> want to have the situation clear to people involved.

the ugliest technical aspect of them being in the Linux host kernel is 
that NDIS drivers are used to a larger kernel stack, so they very 
frequently overflow the Linux kernel stack. Not sure whether recent 
versions of ndiswrapper have solved this problem.

	Ingo

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Jiri Kosina]

On Tue, 4 Mar 2008, Ingo Molnar wrote:

> > Ingo, i's simply not possible to put ndiswrapper in user-space sanely.
> > Drivers are drivers. They'll want (shared) interrupts, they want DMA, 
> > they want to do things like cli/sti.
> yeah, i agree that putting it into userspace is quite insane.
> it might possible to do it halfways sanely via existing arch/x86/kvm/ 
> infrastructure though. VMX/SVM context will properly emulate the IRQ 
> flag so cli/sti will work fine, and as long as DMA is properly 
> quarantined via an iommu it might even not corrupt the rest of the 
> system. 

This definitely could be a [hackish] way to go. The remarkable drawback 
is that it will not work on CPUs without virtualization extensions.

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Ingo Molnar]

* Jiri Kosina <jkosina@suse.cz> wrote:

> On Tue, 4 Mar 2008, Ingo Molnar wrote:
> 
> > > Ingo, i's simply not possible to put ndiswrapper in user-space sanely.
> > > Drivers are drivers. They'll want (shared) interrupts, they want DMA, 
> > > they want to do things like cli/sti.
> > yeah, i agree that putting it into userspace is quite insane.
> > it might possible to do it halfways sanely via existing arch/x86/kvm/ 
> > infrastructure though. VMX/SVM context will properly emulate the IRQ 
> > flag so cli/sti will work fine, and as long as DMA is properly 
> > quarantined via an iommu it might even not corrupt the rest of the 
> > system. 
> 
> This definitely could be a [hackish] way to go. The remarkable 
> drawback is that it will not work on CPUs without virtualization 
> extensions.

by the time it's implemented and trickles into distributions the 
majority of PCs will have virtualization extensions.

	Ingo

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Jon Masters]

On Fri, 2008-02-29 at 09:59 -0700, Zan Lynx wrote:
> On Fri, 2008-02-29 at 08:08 -0800, Linus Torvalds wrote:
> [cut]
> > It loads non-GPL code, it is non-GPL.
> [cut]
> > Exactly. And ndiswrapper loads proprietary modules.
> 
> The Linux kernel itself will load proprietary modules.  It does not as a
> general rule, but it will.

And when that happens, the same taint flag will be set. Your argument is
a non-argument :)

But anyway...

FWIW, I wasn't actually trying to start this debate with the patch I
sent before - I was simply correcting what seemed to be "obviously"
broken logic in module.c for handling ndiswrapper[0]. I was auditing the
taint flags for a backport to another kernel, and noticed this. Having
said that, there would seem to be two directions this can now go in:

*). Back out this patch, go back to previous situation. But then there's
still special case logic for ndiswrapper, and it's not really doing what
people would likely consider the "right" thing with its tainting then. I
again suggest that ndiswrapper would need to be sure to set the taint
flags itself, which would be an alternative to "policing" it.

*). Keep this patch. And potentially add some more for other similar
shim layers - I can think of a certain graphics driver that might
qualify for similar treatment, if one wants to go there. But I might
need to find a tailor specializing in *really* fire retardant pants
before I think of being the one who submits that patch.

I've no idea what "the right thing" is here, but many seem to think it
involves backing out this patch (the most compelling argument given so
far is that it might force ndiswrapper simply to change its name, and
that there's no clear idea if the kernel should be enforcing ideology).
Since we've brought it up, one good thing I would like to see come of
this perhaps is a clearer understanding of what the kernel should and
should not be doing in terms of "license compliance enforcement". We
have had lots of talk, but perhaps a "policy" document is worthwhile.

Jon.

[0] If this is reverted, please do stick in a reference to:
http://lwn.net/Articles/205644/ to avoid repeats.

Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

[Adrian Bunk]

On Fri, Feb 29, 2008 at 12:18:12PM -0500, Jon Masters wrote:
>...
> *). Keep this patch. And potentially add some more for other similar
> shim layers - I can think of a certain graphics driver that might
> qualify for similar treatment, if one wants to go there. But I might
> need to find a tailor specializing in *really* fire retardant pants
> before I think of being the one who submits that patch.
>...

If all that's missing for getting such a patch included is submitting it 
I would even do it with my normal pants on. [1]

I would leave the *really* fire retardant pants for the case that 
someone will ever try some "are binary modules legal" case at court by 
suing people operating ftp mirrors of Debian non-free and similar
repositories of other distributions... [2,3]

> Jon.
>...

cu
Adrian

[1] no matter whether in the British or the American meaning of "pants"
[2] realistically, if these things will ever go to court, the person 
    suing might not want to choose some billion Dollar US company
    but some local private person or university as defendant
[3] like e.g. Caldera turning into SCO and a Linux developer fired by 
    Novell yesterday being hired by Microsoft tomorrow life changes 
    fast, and one of the many copyright holders of the kernel might some 
    day find some reason why he wants to do this

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed