NDISwrapper dodges another bullet [LWN.net]

By Jake Edge
March 5, 2008

Hardware compatibility has long been a problem for Linux—though it has gotten much better over the years—so it will be surprising to some to see a kernel change that will make some hardware cease working. For others, who follow kernel development a bit more closely, it will come as no great surprise that NDISwrapper was disabled by a change made to the kernel back in January. NDISwrapper has never been very popular with kernel hackers, but, because it is GPL licensed and allows more hardware to be used, there are folks on both sides of the argument. For a while, it looked like NDISwrapper had lost that argument, but the 2.6.25-rc4 release restores the functionality it requires.

NDISwrapper is a kernel module that is used to load Windows-only drivers into Linux. For some hardware, notably wireless network cards, it is the only way to support them because the manufacturer provides neither specifications nor a working Linux driver. Unfortunately, many of these cards are installed in laptops where it is difficult or impossible to replace them with Linux-friendly alternatives. This is what led to implementing the Network Device Interface Specification (NDIS) for Linux. NDIS is an ancient—it was originally developed by Microsoft and 3Com for MS-DOS in the mid to late 1980s—interface for networking devices, which is still in use today.

The NDISwrapper code has been around since 2003, but always as a separate module that must be built by the user (or distribution) and loaded into the kernel. It is not part of the mainline kernel, nor will it ever be; maintaining a glue layer that allows proprietary, closed-source drivers to be linked into the kernel is not high on anyone's list. But, NDISwrapper is GPL. Its code is available for inspection or modification by all, so that is not the problem, it is the intent that matters.

When a binary-only driver—the NVidia video driver for example—is loaded into the kernel, a "taint" flag is set, indicating that the kernel is tainted by code that cannot be examined. Bug reports for tainted kernels are routinely ignored, unless they can be reproduced in an untainted kernel. Life, it seems, is too short to try and diagnose problems that could easily have been created by a buggy driver that cannot be debugged. Originally, the taint flag was just a means to detect and ignore those bug reports, but over time it has become part of a mechanism to restrict which symbols a module can access.

Some kernel symbols are considered so integral that any module using them must be a derivative work. Therefore, modules that want to use them must be GPL. Modules declare their license using the MODULE_LICENSE macro, while symbols are exported using either EXPORT_SYMBOL or EXPORT_SYMBOL_GPL. Any module that doesn't have a compatible license doesn't get access to the GPL-only symbols.

Few would argue for a GPL module which existed to re-export all of the GPL-only symbols to non-GPL modules. But that is not what NDISwrapper does; instead it implements NDIS, but in order to do that, needs access to GPL-only symbols, mostly for USB and workqueue interfaces. It would be hard to contend that NDIS drivers are derivative of the Linux kernel, they were written for an entirely different system using an interface that predates Linux. This is why NDISwrapper developers and users think that an exception should be made for it. Clearly the Windows drivers taint the kernel, but accessing a subset of the GPL-only functionality through NDISwrapper should be allowed, they argue.

Since NDISwrapper itself is GPL, the normal module loading rules would allow it to access GPL-only symbols, except that an explicit check for NDISwrapper was added to the 2.6.16 kernel. The question, then, revolves around what should be done when the kernel detects it being loaded. NDISwrapper has always been careful to mark the drivers that it loads as tainted, but the recent patch marks the module itself as tainted, disallowing access to the GPL-only symbols and breaking NDISwrapper. Absent that patch, only the kernel is marked as tainted—the module itself is not.

A similar situation occurred back in October 2006, which LWN covered on the Kernel page, when a stricter interpretation of tainting started to be enforced. At that point, NDISwrapper stopped working and it looked like it might stay that way, until Andrew Morton stepped in with objections to breaking NDISwrapper with no warning. Shortly thereafter, a patch was merged that only marked the kernel as tainted when NDISwrapper is loaded. At that point, the issue fell by the wayside, until now.

Part of the problem is that marking a symbol as GPL-only means different things to different developers. For some, it is a means to warn proprietary driver developers that they are straying into territory that makes distribution of their drivers very likely to be a violation of the GPL, while others want to use it to completely eliminate binary-only kernel drivers. There is no policy that clearly delineates which interpretation is "correct". Meanwhile, NDISwrapper has been in use by many for four years or more; breaking it now, with little or no warning, is likely to create some very unhappy users.

Linus Torvalds clearly thinks there are no licensing issues with NDISwrapper:

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 from a technical and support angle, but not against the license.

Jon Masters, the author of the patch that inadvertently made this change, had an excellent suggestion that should be pursued to try and reduce these kinds of problems in the future:

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.

Another interesting battle will be that surrounding exporting init_mm() which was removed in early versions of 2.6.25, but then restored in 2.6.25-rc4. It is fairly clearly a low-level kernel interface that is unused by any in-tree driver, so its export was removed. One rather glaring exception is that the out-of-tree NVidia binary drivers do use it. Its export has been restored for one more development cycle, but it is clearly seen as something that should not be touched by drivers. It could be quite a struggle between the developers and users of a very popular driver and the kernel hackers that don't want to see kernel API abuse.

Issues surrounding the GPL are always contentious on linux-kernel; this one is no different. While NDISwrapper is an out-of-tree driver, it has hardly been invisible, so complaints when it breaks should come as no surprise. A simple renaming will avoid the current kernel check, so breaking it that way will mostly be an annoyance to users rather than a real barrier to its use. Since there is no real consensus amongst kernel hackers on the binary driver issue, it is hard to see one emerging with regards to NDISwrapper, but that would be the best outcome. One way or another, it needs to be decided, NDISwrapper shouldn't come under a periodic threat of breaking. If it is determined to be a violation of the kernel interfaces, that should be clearly indicated and its users should be given some warning so they can find alternatives.

(Log in to post comments)

NDISwrapper dodges another bullet

Posted Mar 5, 2008 20:27 UTC (Wed) by sbergman27 (guest, #10767) [Link]

"""
You have a problem because the default driver isn't working, so you try to get NDISwrapper
working.. now you have two problems.
"""

Well, sometimes there truly is little choice. My laptop has a Broadcom 4318 chip set. B43
works now. But for the first year or so that I had it, no FOSS driver would work. I tried
and tried. I spent hours... days... to no effect. I even went to far as to order an intel
minipci card to replace the broadcom. But the bios on this machine checks the model number
and politely refuses to boot if the wireless card is not on the approved list. So I ended up
with ndiswrapper which was a piece of cake to install and get working. (Hacking the bios, and
possibly trashing my machine, was beyond the limit of what I was willing to do to run a Free
driver, much as I did want to.)

And yes, I did complain loudly to Broadcom and Compaq, but the responses I got made it pretty
clear that they didn't get many complaints, and didn't really even understand what I was
complaining about. I think the Broadcom guy thought I was some kind of kook, not running
Windows.

Linux is wireless driver deficient and has been for a long time. That is, in part, the kernel
devs fault because the old interface was so bad. And it is mostly the chip manufacturers'
fault. But I can't really see blaming the users. If it is common practice to suggest
blacklisting the OSS driver in favor of ndiswrapper, that is because of shortcomings in
*Linux*, not in the user. You can't blame people for wanting common hardware to work. Would
you rather have them running ndiswrapper on Linux? Or go back to Windows?

NDISwrapper dodges another bullet

Posted Mar 5, 2008 21:47 UTC (Wed) by drag (subscriber, #31333) [Link]

""Well, sometimes there truly is little choice. ""

If you have no choice, then you have no choice.

What I have a problem with is people, posing as experts, recommending to new users to
blacklist open source drivers to get NDIS wrapper working.

This is when I have the same exact devices and they are working perfectly well with no NDIS
wrapper!

What they should do instead is figure out what went wrong, file a bug report, and get a
working driver and try to get that stuff back into the distro, or at least provide a download,
so that they are actually helping the people they are claiming to help instead of advising
users to try to shoehorn Windows drivers into their kernel.

NDISwrapper dodges another bullet

Posted Mar 5, 2008 22:51 UTC (Wed) by proski (subscriber, #104) [Link]

Users who believe such "experts" are usually not good at bug reporting. They would forget to provide important information about their systems, they would be loaded with incorrect assumptions taken from "experts" in "helpful" forums, they would fail to read the documentation, they would trust obsolete posts they find on Google more than the current documentation. And even if they manage report a bug more or less correctly, it would be either a known issue, or something already fixed in the git repository and being on its way to the distros. But it's unlikely such users would bother testing the fix.

In any case, it's unfair to advocate blocking free software just because it has some clueless proponents. Just because, say, KDE has some idiotic fans, it doesn't mean that developers of other software (e.g. gcc, libc) should be actively looking for ways to prevent KDE from compiling or working properly, and it particular blacklist KDE modules by name, as it was done to ndiswrapper.

NDISwrapper dodges another bullet

Posted Mar 6, 2008 5:45 UTC (Thu) by allesfresser (subscriber, #216) [Link]

What I found really annoying was people (yes, on the Ubuntu forums) who told a user, as you
said, to blacklist the free driver in favor of ndiswrapper.  However, the system in question
happened to be using a *PowerPC processor*.  Obviously this will not do the user much good, to
load a Windows driver in this case...

Sauce

Posted Mar 5, 2008 19:08 UTC (Wed) by ncm (subscriber, #165) [Link]

The same arguments made earlier insisting that a release under the GPL couldn't be retracted would apply equally here: ndiswrapper has been distributed with the kernel and drivers with full awareness of the kernel maintainers, for years. I.e., to withdraw permission now would be much the same as withdrawing permission to redistribute GPLed code.

I'm not saying they couldn't withdraw permission. It's just that those whose position comes down on the wishful-thinking side of any argument would argue opposite here as for the previous issue, and even insist there was no contradiction.

The canonical reference for wishful thinking is also the Greatest Blog Post Ever.

Sauce

Posted Mar 6, 2008 3:08 UTC (Thu) by proski (subscriber, #104) [Link]

I think you are comparing two different things. One is like changing a contract unilaterarily after it was signed. That's clearly illegal. Another is like installing "no trespass" signs in wrong places. It can be forbidden too, but by another law, and there is no law specifically regulating GPL-only symbols.

However, installing "no trespass" signs in improper location would cause people stop paying attention to them, and some trespasser could even argue that the trespass wasn't willful if there were some obviously wrong signs nearby.

NDISwrapper dodges another bullet

Posted Mar 5, 2008 19:12 UTC (Wed) by and (subscriber, #2883) [Link]

> If the official kernel were to accept a patch that would prevent
> ndiswrapper from accessing some symbols, nothing would stop a 
> distributor from reverting the patch, as GPLv2 gives distributors the 
> freedom to make modifications. 

This is true from a technical point of view, but there are probably other 
tricks available to get non-GPL modules to load. The whole point of the 
EXPORT_SYMBOL_GPL thing is more legal than technical. It goes along the 
lines of "If you use this symbol in non-GPLed code we may sue you". It 
also won't help if a distributor would remove the block since if they 
where really sued over a GPL violation, they couldn't distribute the 
kernel anymore making it hard to stay a linux distributor...

The thing I was wondering about is that Linus reserves himself the right 
to remove such patches, even though he doesn't own the copyright for the 
piece of code in question in about 99% of all cases. I suppose if a 
copyright owner was to send Linus such a patch for one of the owner's 
interfaces, Linus would probably be required to accept it from a legal 
point of view. (Strictly technically this is not true, of cource, see the 
first paragraph...)

NDISwrapper dodges another bullet

Posted Mar 5, 2008 21:55 UTC (Wed) by drag (subscriber, #31333) [Link]

> The thing I was wondering about is that Linus reserves himself the right 
to remove such patches,

He doesn't.

If you go and look at the email exchange with him you'll notice that he threatened to banish
anybody arguingon any sort of the legal mumbo-jumbo to his ignore file. He was only interested
in the interfaces that ndiswrapper used and told people to contact those authors and try to
work out a exception if they care about it working.

NDISwrapper dodges another bullet

Posted Mar 5, 2008 20:08 UTC (Wed) by iabervon (subscriber, #722) [Link]

Unless people are distributing systems that are already booted, I don't think anyone could
help but have the end user load the binary driver; I don't think ndiswrapper even supports
linking the driver into it ahead of time. And selling the combination is fine with the GPL as
mere aggregation, and it's, if anything, better that the nvidia drivers situation as a whole,
because the closed code and the open code are separated by clean and generic API. If you
modify your kernel, there's no way that this could require changes to the binary driver, since
it's not even designed to work with Linux at all. If the GPL's purpose is to prevent non-GPL
code rom preventing you from modifying GPL code and then being able  to use the system, that's
not a concern here for technical reasons, even leaving aside legal ones.

NDISwrapper dodges another bullet

Posted Mar 6, 2008 0:25 UTC (Thu) by jengelh (subscriber, #33263) [Link]

>Unless people are distributing systems that are already booted, I don't think anyone could
help but have the end user load the binary driver; I don't think ndiswrapper even supports
linking the driver into it ahead of time.

Consider VMware Suspend Images (*.vmss)  it is possible to distribute booted systems, and as
such, every currently working combination of code.

Well, it may already happen that distributing the Windows driver is bound by some license
already, so you can possibly save on the time to spend about thinking about distributing
linked code.

NDISwrapper dodges another bullet

Posted Mar 6, 2008 16:07 UTC (Thu) by iabervon (subscriber, #722) [Link]

Doesn't vmware abstract access to network devices anyway? I somehow doubt that a suspend image
containing a Linux kernel using a Windows driver to talk to a physical network device would
actually have any chance of working at all. And running Linux under vmware with the Windows
driver for the vmware simulated network device instead of the Linux driver for it is just
silly.

In order for this particular issue to be relevant, you'd need to distribute a booted system
with a driver loaded for a chipset with only a Windows driver available, which only makes
sense if it's running on physical hardware.

NDISwrapper dodges another bullet

Posted Mar 6, 2008 17:10 UTC (Thu) by jengelh (subscriber, #33263) [Link]

>Doesn't vmware abstract access to network devices anyway?

This is independent of providing a linked variant of ndiswrapper IMHO.

That said, VMware provides virtual HW that behaves like AMD PCnet32 or Intel E1000; so I could
link e1000.drv with ndiswrapper  then what?

Abstraction does not relate to anything. Imagine we had have kexec from/to VMSS someday  then
what?

NDISwrapper dodges another bullet

Posted Mar 6, 2008 0:33 UTC (Thu) by rahvin (subscriber, #16953) [Link]

As I understood how the nVidia driver works, this is exactly the method. There is a GPL'd
piece that integrates into the kernel and creates the interface to the binary driver. Just
like ndiswrapper works, in fact I thought that the nVidia Linux driver was created because
ndiswrapper showed them how to integrate a closed source binary driver into the kernel.

I also thought this was one of the reasons certain developers hate ndiswrapper so much, they
started the whole trend to the binary blob in the kernel thing.

NDISwrapper dodges another bullet

Posted Mar 6, 2008 3:18 UTC (Thu) by proski (subscriber, #104) [Link]

I'm not sure about nVidia drivers, but I believe they are compiled specifically for Linux. The free and non-free parts are distributed together by the same entity. I think that's very different from ndiswrapper from the legal standpoint (but IANAL).

What I know for sure, is that a non-free driver for Lucent Orinoco cards used such trick, and it predated ndiswrapper. That's why blaming ndiswrapper that it "started the whole trend" would be misleading.

Besides, driverloader is older than ndiswrapper, and it does the same thing as ndiswrapper. It's also non-free and was caught lying about its license, something that ndiswrapper never did.

NDISwrapper dodges another bullet

Posted Mar 6, 2008 5:39 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]

Apparently, the NVIDIA adapter code sets its license to "NVIDIA", so it doesn't get access to
GPLONLY symbols.  I haven't checked this myself, but I've seen others mention it.

NDISwrapper dodges another bullet

Posted Mar 6, 2008 8:37 UTC (Thu) by Los__D (guest, #15263) [Link]

You are completely right:

$ modinfo nvidia
...
license:        NVIDIA
...

NDISwrapper dodges another bullet

Posted Mar 6, 2008 16:22 UTC (Thu) by iabervon (subscriber, #722) [Link]

It's very different in that the binary blobs that NDISwrapper loads were written without
knowledge of the Linux kernel, and the binary blob that the nVidia shim code loads were
written using knowledge of the Linux kernel as reference. This is much the same difference as
that between writing an encyclopedia without having Britannica and writing one while using
Britannica. In the latter case, you have to be a lot more careful about a lot of things in
order to avoid doing things you shouldn't.

NDISwrapper dodges another bullet

Posted Mar 6, 2008 13:05 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]

There are some recent PCI extensions for IO virtualisation (IOV) that provide for (among other
things) mapping of DMA addresses by the chipset. This could perhaps be used to constrain
user-space drivers.

NDISwrapper dodges another bullet

Posted Mar 6, 2008 14:41 UTC (Thu) by mcmanus (subscriber, #4569) [Link]

If your board has an IOMMU it can do this for you - and they are becoming more common.

As long as the proprietary Windows driver ist not DISTRIBUTED...

Posted Mar 6, 2008 11:13 UTC (Thu) by NRArnot (subscriber, #3033) [Link]

Perhaps an NDIS-lover should write a GPLed NDIS driver for some old Ethernet NIC for which
sufficient programming information is available. 

We'd then see an assemblage of code, all GPL,  being blocked, or the kernel into which it is
loaded being marked as tainted, as a result of the political goals of people controlling the
export of kernel symbols!

As long as the proprietary Windows driver ist not DISTRIBUTED...

Posted Mar 6, 2008 12:48 UTC (Thu) by morhippo (subscriber, #334) [Link]

If you read the discussion on the kernel mailing list, there is mention of such a driver
actually existing.

As long as the proprietary Windows driver ist not DISTRIBUTED...

Posted Mar 6, 2008 13:01 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]

There is a GPL'd NDIS driver - http://cipe-win32.sourceforge.net/ - though it's a port from
Linux so there's little point in using it with ndiswrapper.

Slightly different tack

Posted Mar 6, 2008 13:16 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link]

Maybe there could be broader distribution of reversing kits, making it less painful to get
into collecting packets and writing drivers for legacy hardware.
A problem with NDISwrapper is that it appeals to laziness and doesn't foster new, pure-GPL
development.
Advertizing NDISwrapper as an important infrastructure piece for writing freer drivers could
give it more street cred.
Packaged properly, it could help improve the developer base for the kernel by helping flatten
the learning curve.
And I want a pony.

NDIS drivers in mainline? NEVER

Posted Mar 6, 2008 23:35 UTC (Thu) by hmh (subscriber, #3838) [Link]

Err, it is worth noticing that refusal to merge crap in the kernel happens all the time.
There is no way any NDIS driver would ever be merged, AFAIK, and the reasons for this are
simple:

An NDIS driver would be slower, more difficult to maintain, far more complex (you have to take
into account the entire NDIS wrapper too!), and IMHO just downright nastier to look at than it
would be had it used the native APIs in the first place.

So I am afraid an NDIS-lover will have to find another way to equal himself to the people who
mark symbols GPL-only for political reasons (as opposed to technical reasons).

As long as the proprietary Windows driver ist not DISTRIBUTED...

Posted Mar 7, 2008 16:32 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

I don't understand the argument.

I believe there are multiple arguments, as there are multiple views of the purpose of GPL_ONLY symbols. But the arguments described in this article aren't arguments about what copyright law or GPL allows -- they're just arguments over how easy the kernel.org kernel should make it to use Windows drivers with Linux. And also how easy it should be to tell that Windows drivers are being used, in a bug report.

NDISwrapper dodges another bullet

Posted Mar 6, 2008 14:38 UTC (Thu) by pr1268 (subscriber, #24648) [Link]

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

I have to agree with Linus' overall philosophy here wrt NDISWrapper. Wi-fi cards are the bone of contention amongst laptop users running Linux.

I can't even count how many times I've run across someone running a (fairly late-model) laptop with Linux and having to shoe-horn in Wi-fi capability on the built-in card with NDISWrapper (or other GPL-questionable methods).

(I even have a friend with a Lenovo T61 running Ubuntu - with an Intel Wi-fi card, two relatively Linux-friendly companies. But, neither of us could figure out how to get the WPA-specific features of the card to work with the university's encrypted Wi-fi network - and believe me, we spent days on this. He still is considering NDISWrapper, despite my urgings that he avoid doing so. And this is a guy who proudly sports a "Microsoft-Free" sticker on the lid of his laptop!)

I had someone else come ask me for help getting his laptop's Wi-fi card working, even though the sound card didn't work, the X display was set to a grotesquely low resolution (i.e. a 1920x1440 display running at 800x600), the sound card didn't work (not too sure whether that was a lack of Linux driver support or misconfiguration), some keyboard shortcut keys didn't work (probably not configured yet), and the thumbprint reader didn't work. Now bear in mind that every last piece of built-in hardware on this gentleman's laptop did work in Windows, and he took great pains to remind me of that while I was attempting to ascertain the best strategy of getting the Wi-fi working, but he was still willing to give Linux a try.

I get the impression that the kernel developers were/are attempting to quietly kill support for non-GPL driver/BLOB support in the kernel. I can imagine a future where, assuming this happens, then a whole counterculture sprouts up - that of Linux users of moderate skill who use outdated versions of the kernel and equally outdated versions of "driver-enabling" software (e.g., NDISWrapper) with vulnerabilities possibly lurking about, just to ensure everything Just Works™. Or, for those willing to give Linux a try, they discover just how horribly "crippled" everything becomes when switching from Windows (or Mac OS) to Linux because they've got the latest hardware devices and no driver support, and they swear off Linux forever.

I really do appreciate the evangelism RMS and the FSF have done over the years, and I am also truly grateful for the hard work the kernel developers have done to ensure Linux users don't feel "left behind" wrt hardware support (Greg K-H's open letter to IHVs a few months ago comes to mind). And, I think that the Linux community needs to continue applying this pressure on IHVs to ensure continued hardware driver support.

But, "slamming the door shut" (either clandestinely or overtly) on many users' lone ability to use their computers without caving in to the demands of one single company (and its chair-throwing CEO) just doesn't seem like the right thing to do. I understand that there are those among the kernel devs with intense philosophical beliefs about GPL adherence, but summarily "pulling the plug" without discussion is extreme, IMHO.

I can understand why some of the "tips" on the Ubuntu forums actively encourage NDISWrapper - (1) it's essentially a guaranteed solution (even if it is, as Linus said above, a distasteful one), and (2) it's a method that can be mass-marketed easily to novice Linux users.