Binary blob
From Wikipedia, the free encyclopedia
An object file to be loaded into the kernel space of an open source operating system is called a binary blob if its source code is not publicly available.
This term should not be applied to code running outside the kernel, for example BIOS code, firmware images, or userland programs.
Contents |
[edit] Reasons for using binary blobs
When computer hardware vendors provide complete technical documentation for their products, operating system developers are able to write open source hardware device drivers to be included in the operating system kernels. In this case, there is no need for any binary blobs.
But some vendors, such as ATI and NVIDIA, fail to provide complete documentation for some of their products. Providing binary blobs instead is most common for accelerated graphics drivers, networking devices and RAID controllers.
When they can neither get hardware documentation nor device driver source code from a hardware vendor, some operating system projects, including NetBSD, FreeBSD, DragonFly BSD, and the Ubuntu Linux distribution, accept binary blobs as a fast route to the missing or enhanced functionality these blobs provide.[1]
In order to make use of binary blob drivers available for other operating systems, some projects include software wrappers: examples include NdisWrapper for Linux and Project Evil for FreeBSD and NetBSD, both of which implement Microsoft's NDIS API to allow Windows drivers to be used.
[edit] Reasons against using binary blobs
There are several reasons why binary blobs can cause problems:
- Correctness of the driver code cannot be checked.
- The code is often unnecessarily large and complicated.
- The code cannot be audited for security; security flaws may go unnoticed for long times.
- Users are forced to trust vendors not to put backdoors and spyware into the blob.
- In case of bugs or vulnerabilities, the driver cannot be repaired by the operating system authors, even though it will compromise system integrity, usually at the Superuser level.
- The hardware vendor can decide not to support some operation systems.
- The hardware vendor can decide to abandon driver maintenance at any time, thus effectively rendering the hardware device useless.
- The driver cannot be modified and adopted to special needs.
[edit] Projects actively opposing binary blobs
The OpenBSD project has a notable policy of not accepting any binary blobs into its source tree, citing not only the potential for undetectable or irreparable security flaws but also its encroachment onto the openness and freedom of their software.[2]
The Free Software Foundation (FSF) is actively campaigning against binary blobs, even though some Linux distributions do include them.[3]
[edit] Famous examples of binary blob vulnerabilties
This stance has been somewhat validated by information released during the August 2, 2006 Black Hat USA convention where an exploit within the binary driver for the Atheros wireless network cards used in MacBook Pros and elsewhere was claimed,[4] although it was later revealed that the exploit used third-party hardware and drivers.[5]
The NVIDIA Binary Graphics Driver for Linux had a vulnerability that allowed privilege escalation to root.[6]
[edit] Firmware issues
Firmware, the operating software required by a device's onboard microcontroller that accompanies some hardware, is generally not considered to be a binary blob. However, the FSF has begun campaigning for free BIOS firmware.[7] Often firmware is stored in onboard flash memory, but to decrease costs and ease upgrading, some manufacturers now use external firmware uploaded by the operating system. Although the firmware is present in the operating system, it is merely copied to the device and not executed, lessening concerns about hidden security flaws. The OpenBSD project accepts binary firmware images and will redistribute the images if the license permits.[8]
[edit] See also
[edit] Notes and references
- ^ Matzan, Jem (15 June 2005). BSD cognoscenti on Linux. NewsForge. Retrieved on 2006-07-07. See Christos Zoulas's response to "Is sharing between Free/Open/NetBSD and the Linux kernel a common occurrence? And if so, does it go both ways?"
- ^ Music composed by Ty Semaka and Jonathan Lewis. Recorded, mixed and mastered by Jonathan Lewis of Moxam Studios (1-403-233-0350). Vocals and Lyrics by Ty Semaka & Theo de Raadt. Bass guitar, organ and bubbles by Jonathan Lewis. Guitar by Tom Bagley. Drums by Jim Buick. 3.9: "Blob!". OpenBSD. Retrieved on 2006-06-22.
- ^ Protest against ATI nearly led to the arrest of RMS. Free Software Foundation (27 April 2006). Retrieved on 2006-10-10.
- ^ Martin, Kelly (August 3, 2006). WiFi makes waves at Blackhat. SecurityFocus. Retrieved on 2006-08-25.
- ^ Dalrymple, Jim (August 17, 2006). MacBook Wi-Fi hack didn't use Apple drivers.
- ^ Abdine, Derek (Oct 17, 2006). NVIDIA Binary Blob Driver Advisory. Rapid7.
- ^ Campaign for Free BIOS. Free Software Foundation (2006-11-29). Retrieved on 2007-01-02.
- ^ OpenBSD Works To Open Wireless Chipsets. KernelTrap (November 2, 2004). Retrieved on 2006-06-23.
[edit] External links
- McMillan, Robert (June 21, 2006). Researchers hack Wi-Fi driver to breach laptop. InfoWorld. Retrieved on 2006-06-23.
- KernelTrap article on Damien Bergamini's wpi(4) driver, a blobless ipw3945 alternative for OpenBSD
- KernelTrap interview with Jonathan Gray and Damien Bergamini regarding binary blobs
- The Black Hat Wireless Exploit Interview, Verbatim by Brian Krebs on the Washington Post's website, http://washingtonpost.com