| |||||||||||||
On binary drivers and stable interfacesOn binary drivers and stable interfacesPosted Nov 10, 2005 10:50 UTC (Thu) by Quazatron (guest, #4368)Parent article: On binary drivers and stable interfaces
I think that the OSS community does not need the vendors to provide GPL drivers.
If the vendors want to protect their "valuable intellectual property", all they have to do is to publish the specifications of the product, how to interface with it. The OSS community can then write the GPL driver.
That way, both sides win. Users get solid drivers, vendors get happy costumers and don't need to spend a cent to suport OSS OSes.
Of there's that other problem of the drivers that have to load firmware into the devices before working, but I think that could be solved with a combination of userspace firmware loading tools and GLP drivers. That would also require the vendors to allow distribution of the (closed) firmware binaries.
(Log in to post comments)
On binary drivers and stable interfaces Posted Nov 10, 2005 11:33 UTC (Thu) by drag (subscriber, #31333) [Link] The thing about firmware (also known as microcode, which is more familar to some people) is that it's not 'software' so much. It's code alright, but it's not designed to actually do anything except run on hardware's proccessor/dsp/whatever.
It's completely independant from the OS and any hardware platform. For all practical purposes it is part of the actual hardware on whatever card it's used for. That's why Linux is able to have firmware images in it's source code tree and not violate the GPL, even though if you look at it a certain way the firmware is 'closed source'.
This is why firmware is different from a 'binary blob' that is used by stuff like madwifi and nvidia drivers. This 'binary blob' is system specific, written in a regular programming language, runs on the regular cpu and is platform specific. For instance I can't run nvidia drivers or madwifi drivers on my powerpc computer, but with firmware it will work fine.
Realy though... manufacturers should have the firmware on the actual device on non-volitile ram or rom or whatever instead of having the OS load it via the drivers. It's a bit of a hack to save a bit of money, but it makes things more inconvienent for their customers.
On binary drivers and stable interfaces Posted Nov 10, 2005 18:33 UTC (Thu) by arafel (subscriber, #18557) [Link] Leaving aside the rest of it, I think you'll find it's not usually to save memory so much as it is to allow firmware updates to work around bugs, add new features etc. Harder to do that in ROM; they could use flash, I guess...
On binary drivers and stable interfaces Posted Nov 11, 2005 4:30 UTC (Fri) by Ross (subscriber, #4065) [Link] Microcode is actually something different -- it is the glue on top of the lowest levels of hardware to create the "native" machine language instruction set. Some firmware is microcode and some is not. In many cases, microcode can't be "uploaded" at all (though that isn't the case with Intel CPUs). Also, nothing actually limits firmware to "just" driving the hardware. Entire Linux distributions are loaded as firmware in some cases.
what is microcode? Posted Nov 11, 2005 19:33 UTC (Fri) by giraffedata (subscriber, #1954) [Link] Thanks for making a point that needed to be made.We should clarify though, that people (IBM engineers are the only ones I've heard do it) do often use the term "microcode" to refer to any software built into a device. They're all wrong. Also for the sake of precision, microcode isn't just for CPUs. Any machine can be driven by microcode -- it's really just a style of software; a class of instruction set. In days when CPUs were expensive, many machines were implemented with microcode. I don't know how much microcode is in use today, but I imagine communication processors (e.g. inside a network switch or TCP Offload Engine) get some use out of it go faster than any conventional CPU could go. I found a pretty good definition at http://www.webopedia.com/TERM/M/microcode.html . "firmware," unfortunately, isn't the right word either. That just means instructions that are somewhat permanent, as in a ROM chip. The permanence isn't really what we're talking about here; in fact, I think we're specifically talking about software that has to be loaded every time the device powers up. I'd just call it "the device control program."
On binary drivers and stable interfaces Posted Nov 11, 2005 14:22 UTC (Fri) by N0NB (guest, #3407) [Link] As I understand it, not all firmware or binary blobs exist solely because a hardware manufacturer is unwilling to release specs for the interface. As I understand it, in the USA at least, the FCC mandates that wireless devices be tamper proof. A user is prohibited by law from tweaking such things as RF power, carrier frequency, or the coding protocol. To get a device certified for sale by the FCC the control interface must be restricted to only those the FCC allows.
So here we have the Free Software philosophy and US law at odds with each other (not for the first or only time). How can this be resolved?
I have two laptops with Atheros based 802.11b/g adapters. Madwifi works very well even though I must build the package manually on my Debian systems. The kernel complains of "tainting" when loading the modules and otherwise works flawlessly.
Do I understand correctly that the binary blob of Madwifi is code the CPU executes? Yet it still is controlling the Atheros chipset. I guess the only difference is that it occupies the main memory of my computer rather than being loaded into RAM on the device, correct? Still, I don't see how the blob affects the kernel directly as it doesn't seem to be a part of it. The wrapper is definitely connected to the kernel and it talks to the blob.
It seems the real issue is the location of the firmware code. Why is it bad if the proprietary blob happens to occupy main memory and is executed by the CPU, but things are just fine if that same blob were encoded onto the firmware and the kernel is controlling the hardware in the same way?
I'm not trolling. I genuinely want to know the difference. With Madwifi it appears we have a manufacturer working as well as they can with the kernel while adhering to USA law. I don't think they are necessarily "tainting" the kernel.
On binary drivers and stable interfaces Posted Nov 11, 2005 21:07 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link] no, the firmware blob is what in older devices would be in the ROM soldered to the device (which nobody object to useing)
it's not just a simple matter of getting specs of the device to recreate this, and it's definantly not something that is likly to run on any other device (even a nre revision of a card will frequently require a different version of the firmware)
vendors do this for a couple reasons.
1. it's cheaper to leave the ROM/Flash off of the card.
2. it's more flexible as it allows for updates and bugfixes
as long as the API to talk to the device once the firmware is loaded is documented people should not have much grounds to fuss about it.
On binary drivers and stable interfaces Posted Nov 16, 2005 13:33 UTC (Wed) by zblaxell (subscriber, #26385) [Link] "no, the firmware blob is what in older devices would be in the ROM soldered to the device (which nobody object to useing)"
Actually, I object (although in practical terms my objection is mostly meaningless since I use them anyway ;-).
Let's assume for example that I wanted to conduct covert surveillance of someone else's machine, and I don't want to get caught. I'd want to be able to bypass any software they might have on the machine that might detect such surveillance, or worse, put a stop to it. So viruses, worms, and trojans targeted at the main OS won't work--they'll all be caught by the usual rootkit detection methods.
Solution? Attack some software that is running in the machine, but not in the OS. Even better if that software can transparently access some sort of communication device, so I can receive data from it. Best of all if I don't have to physically modify the target machine to do it.
What better place to find such software than in a network device? A wireless card would be even better--with a wired network card, my victim could plug their machine into a LAN where I don't control all of the network devices, and see a bunch of data unexpectedly flowing somewhere with traceroute. A wireless card could quietly radiate data that I could pick up with a suitable long-range antenna.
A bus-mastering card has routine access to the entire system RAM through DMA, since Intel CPU's don't have an IOMMU--although in practice I don't see why even having an IOMMU would necessarily be a barrier unless the user also uses a fully virtualized OS. From a bus-mastering card under my control, I can remotely browse through my victim's RAM and retrieve encryption keys, cleartext, and other goodies.
Some other devices, like video outputs connected to a CRT, can do a similar function--modulate the hsync signal slightly, and a CRT will broadcast a fairly powerful signal (although it may be so powerful that it resonates audibly in nearby bits of metal). Disk device drivers can squirrel away data in the HPA or other parts of the disk, then pretend that the disk has failed so the drive can be captured on its way to warranty replacement (even better if the disk itself can participate in the pretense--that way all of the diagnostic utilities--free or proprietary--will present a consistent view of disk failure, until I get the disk and send it my covert-data-retrieval key). ACPI BIOSes can do some *very* interesting things with proprietary PCI bridge interfaces and various OS callbacks. The threat is not just from network device firmware.
On binary drivers and stable interfaces Posted Nov 11, 2005 1:57 UTC (Fri) by giraffedata (subscriber, #1954) [Link] If the vendors want to protect their "valuable intellectual property", all they have to do is to publish the specifications of the product, how to interface with it. The OSS community can then write the GPL driver. So you're assuming the valuable intellectual property is the driver software (copyright)? It's not. The company doesn't sell drivers. The valuable intellectual property is the trade secrets about how the device works. Publishing specs would be worse than shipping source code in that respect.
On binary drivers and stable interfaces Posted Nov 12, 2005 19:38 UTC (Sat) by Ross (subscriber, #4065) [Link] Revealing the programming interface for their device is not the same as publicly documenting how their device works. The more compliated the device the less similar that information is.
The only plausible excuse I've heard is that it allows other companies to make work-alikes without having to write their own drivers or have them certified by Microsoft.
On binary drivers and stable interfaces Posted Nov 12, 2005 20:26 UTC (Sat) by giraffedata (subscriber, #1954) [Link] Good point. I was vague when I said the trade secret in question is "how the device works." The trade secret is the programming interface, and your explanation is the best I've heard for why the company perceives that secret as valuable.
|
|||||||||||||