| 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 11, 2005 21:07 UTC (Fri) by dlang (subscriber, #313)In reply to: On binary drivers and stable interfaces by N0NB
Parent article: On binary drivers and stable interfaces
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.
(Log in to post comments)
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.