GPL-only symbols and ndiswrapper

GPL-only symbols and ndiswrapper

Posted Oct 27, 2006 9:58 UTC (Fri) by NRArnot (subscriber, #3033)
Parent article: GPL-only symbols and ndiswrapper

What is the difference between a binary blob loaded by (say) a RAID controller driver, and a binary blob (aka Windows NDIS driver) loaded by NDISwrapper?

OK, the former executes in a different CPU on the controller, the latter doesn't. But if you are going to claim that because of that it can't bork your Linux, or given malicious intent subvert it, you're wrong. A disk controller has DMA access to your system's memory and, of course, access to all your data on the disk.

Come to that, there IS a binary blob that executes in your system's CPU: the Intel (or AMD) CPU microcode patch blob that gets loaded very early in system initialisation. How would you like it if Intel did to Linux what Linux is doing to NDISwrapper? (thought experiment, it's not likely to happen!)

NDISwrapper creates an interface for a class of blobs having an interface specified by the NDIS driver spec. NDISwrapper is GPL code. The blobs are by definition NOT linux-derived works and are not and may not be shipped with Linux. They taint the kernel when the end user loads them. So what is the kernel trying to accomplish by blocking NDISwrapper by name?

Incidentally, what happens if someone takes the NDIS specifications and writes a null driver and GPL's it? You can then load NDISwrapper + NDIS null driver, and you'd have the kernel preventing some all-GPL software from being used! You never know, there might even be an open NDIS driver for some odd or old bit of hardware out there already, and if so this isn't even just a thought experiment.

This is reduction to absurdity. Sorry, but the kernel guys are being absurd here.

Passing thought: why does VMware emulate an AMD PCnet network card? Is its NDIS driver source open by any chance?

---

(Log in to post comments)