| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
On binary drivers and stable interfaces
On binary drivers and stable interfaces
Posted Nov 10, 2005 11:33 UTC (Thu) by drag (subscriber, #31333)In reply to: On binary drivers and stable interfaces by Quazatron
Parent article: On binary drivers and stable interfaces
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.
(Log in to post comments)
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 (subscriber, #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 (subscriber, #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.