| |||||||||||||
On binary drivers and stable interfacesOn binary drivers and stable interfacesPosted Nov 11, 2005 14:22 UTC (Fri) by N0NB (guest, #3407)In reply to: On binary drivers and stable interfaces by drag Parent article: On binary drivers and stable interfaces
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.
(Log in to post comments)
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.
|
|||||||||||||