Weekly Edition
Return to the Kernel pageRecent Features
| |||||||||||||
Loading NDIS drivers into the kernel
Hardware manufacturers which refuse to release programming information are a
constant source of frustration for Linux users. Without that information,
writing a Linux driver is nearly impossible. As a result, Linux users are
unable to use the hardware in question, and the vendor loses potential
sales.
A company called Linuxant has been offering a product called DriverLoader which is intended to relieve some of this frustration, at least for network devices. It is a kernel module that serves as a wrapper for Windows NDIS drivers. Using DriverLoader, a network device with a Windows driver can be made to function under Linux. There are, needless to say, a few objections that one could make to this product, one of which being that DriverLoader, itself, is not free software. If the non-free nature of DriverLoader is your only objection, however, there is an alternative called ndiswrapper, which is licensed under the GPL. ndiswrapper is clearly in a very early stage of development, but, as its author (Pontus Fuchs) notes, "it works for me." With a bit of work, it could probably be made to work for a lot of other users as well. The ndiswrapper module, when loaded, starts by registering a special purpose "misc" device; its only real reason for existing is to export an ioctl() call which can be invoked to load an NDIS driver. This call accepts the driver code from user space, performs the necessary relocation, and sets it up as Linux network device. In the modern world, using the register_firmware() interface might have been preferable to creating another ioctl() call, but that can always be done in the next revision. Once the driver is loaded, ndiswrapper provides two separate glue layers to make the NDIS driver actually work. The first provides a set of net_device operations which can be invoked by the networking subsystem; these translate the requested operations into the calls that the NDIS driver will be expecting. At the other end, the wrapper code must provide emulation functions for a few dozen Windows routines that the NDIS driver will call. These map the requested operation (allocate an interrupt, remap I/O memory, feed a received packet into the kernel, etc.) back to their Linux equivalents. All told, it is not a huge amount of code. The NDIS API is well enough documented that the requisite glue code could be written without a great deal of guesswork. The wrapper approach to device support is far from optimal. Performance and reliability cannot be improved through the addition of glue layers, and many users will be unenthusiastic about shoving proprietary code - Windows code, even - into their Linux kernels. There is also the risk that hardware vendors might conclude that the existence of wrapper code frees them from the need to worry about Linux driver support at all. Against these disadvantages one can point out that the wrapper will enable Linux to be used on systems that would otherwise be inaccessible to it. This sort of wrapper module could also, with little effort, be turned into an ideal platform for the reverse engineering of unsupported hardware. A module like ndiswrapper may be a hard sell for the mainline kernel, but some users will certainly be glad that it is available. (Log in to post comments)
Loading NDIS drivers on non x86?! Posted Nov 6, 2003 2:12 UTC (Thu) by stuart (subscriber, #623) [Link] These are windows driver so presumably they are compiled for x86. That makes them pretty useless, with or without wrapper, on non-x86 architectures.Another very good reason to not encourage this sort of band-aid.
Loading NDIS drivers into the kernel-another problem? Posted Nov 6, 2003 2:21 UTC (Thu) by flewellyn (subscriber, #5047) [Link] We all know how wonderfully secure Windows drivers can be *cough*. Do we want to place foreign code with a reputation for security vulnerabilities into the Linux kernel? Especially if we have no means of analysing their code?I can see a couple of problems that this might cause even if the driver code itself is not so insecure, on its own. We have no way of knowing what assumptions the writers of these binary drivers made about the environment they have to work with: what memory is accessible, what resources can be used, how the system will react to various changes in state. Even with a glue layer, we don't know what these drivers will try to do. They could try to access real-mode BIOS functions, play with the interrupt vector table, or other nasty things that, in kernel-space, would mean a potential crash or security hole. Plus, there's the whole tainting the kernel with non-free code thing, and I care about that, but it's already been mentioned.
Loading NDIS drivers into the kernel-another problem? Posted Nov 6, 2003 20:18 UTC (Thu) by proski (subscriber, #104) [Link] Do you have any specific information about security problems in Windows network drivers? I don't remember any driver-related security alerts for Windows. Most exploits are on higher levels (TCP/IP, application).
Loading NDIS drivers into the kernel-another problem? Posted Nov 13, 2003 23:18 UTC (Thu) by huaz (guest, #10168) [Link] I am not an M$ fan and I love Linux, but I think you are just doing exactly what we usually accuse M$ of doing: spreading FUD.NDIS driver interface is clearly documented (at M$ website). I don't see what is not clear about what assumptions the drivers can or cannot make.
Loading NDIS drivers into the kernel Posted Nov 6, 2003 5:19 UTC (Thu) by ncm (subscriber, #165) [Link] The comments above are good reasons to steer future development on the ndis layer toward helping those who are reverse-engineering undocumented hardware.
Loading NDIS drivers into the kernel Posted Nov 6, 2003 20:22 UTC (Thu) by proski (subscriber, #104) [Link] It should be helpful already. Developers can compare the Windows driver and the driver they are writing on the same machine, with exactly the same hardware, without reboot.
Bad, bad, bad Posted Nov 6, 2003 9:41 UTC (Thu) by rwmj (subscriber, #5474) [Link] Bad for three reasons:(1) As the article points out, it might discourage manufacturers from releasing Linux-native drivers. When OS/2 came out it was advertised as running Windows programs "better than Windows". Software companies obliged by reasoning that they only needed to write a Windows version of their software, since that would run on OS/2 just fine. Later Microsoft changed the API to Win32, didn't license that to IBM, and OS/2 was scuppered. (2) What about non-x86 architectures? (3) Binary drivers, even Linux-native ones, are a BAD idea for many reasons. Don't forget that the reason that Linux is so rock solid stable and fast is because many people examine and modify the source to the kernel and drivers. Rich.
Yes, bad, but... Posted Nov 6, 2003 13:31 UTC (Thu) by melo@simplicidade.org (guest, #4380) [Link] I read the comments above and I do understand why binary drivers are bad.But I think that linux is also about choice. I'm free to choose what I put in my kernel. In that sense, I applaud these type of developments. They give users the choice to move to a Juse my .02
Yes, bad, but... Posted Nov 6, 2003 17:41 UTC (Thu) by emkey (guest, #144) [Link] Agreed. I'm not too interested in the "religious" aspects of the Linux community or any other community for that matter. I like Linux because it is inexpensive, featurful and flexible. This approach may be a bit of a bandaid but if enables a few more computers to run Linux then I don't see any reason for people to complain.In particular this could be a big boost to the short to mid term prospects for Linux on the desktop.
Loading NDIS drivers into the kernel Posted Nov 7, 2003 15:35 UTC (Fri) by Xman (guest, #10620) [Link] A coworker tried using the Linuxant solution the other day, and his experiences demonstrated both the strengths and the weaknesses of the NDIS emulation approach.He used it to get Centrino wireless working. The driver works great through Linuxant. He was able to use the network quite well. However, when it came time to do LEAP authentication (something he can do no problem in Windows) he was dealt crashing kernels. Sadly, there is no obvious way to configure those drivers through the Linuxant interface. In sumary, beyond the points already made, there are additional problems with using a Windows driver in emulation.
Loading NDIS drivers into the kernel Posted Nov 13, 2003 23:22 UTC (Thu) by mmarq (guest, #2332) [Link] The "political" very correct point of view!But why cant we have a SPLIT kernel "driver interface(s)",ala I2O, that cuts tangential to the hardware:- any code that dosent touch hardware isnt "allowed" to be binary only;... and that harden the kernel to spit off those driver parts, binary only or not, that breack like in the example that you mention !??... I'm far from advocating proprietary drivers, but i still belive that there is a "TECHNICAL" solution for the problem.
Use wrappers as leverage! Posted Nov 13, 2003 14:24 UTC (Thu) by mik (guest, #87) [Link] Come on - this is great! All you need is one vendor in a particular space to release real linux drivers, and you can then demonstrate to the laggards how poorly their products perform. A public combined benchmark and status page, with a "vote for your favorite hardware" function should provide some pressure.Frankly, if we cannot show the native drivers are better, faster and more powerful, then maybe wrappers are, in fact, just fine.
|
|||||||||||||