Binary blob

This is an old revision of this page, as edited by 65.94.100.225 (talk) at 17:56, 25 August 2006. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

A binary blob is a term used by some open source developers to describe an opaque binary object for which no source code is available. In some operating system communities, such as those of Ubuntu and OpenBSD, the term refers to partial or complete drivers provided by companies such as ATI and NVIDIA to provide support for their hardware. Such blobs can be a point of conflict between open source and free software advocates and developers and regular users of the operating system, as binary blobs can provide convenient support for popular hardware at the cost of the ability to read and modify, and thus control, the operating system.

In order to make use of some binary blobs which are not directly provided for an operating system, projects use software wrappers such as the NdisWrapper on Linux, or Project Evil on FreeBSD and NetBSD in order to run Windows drivers, which make use of Microsoft's NDIS API.

The OpenBSD project has a notable policy of not accepting 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.[1] 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 revealed[2]

Other operating system projects, including NetBSD, FreeBSD, DragonFly BSD, and the Ubuntu and Fedora Linux distributions, take a pragmatic view and accept binary blobs as a fast route to the missing or enhanced functionality they provide.[3] They include binary blobs for varied purposes, ranging from RAID, to networking and accelerated graphics drivers. It is worth noting that the Free software foundation is actively campaigning against binary blobs, even though many Linux distributions include them.[citation needed]

A binary blob is generally not considered the same as a firmware package that accompanies a particular device as the firmware is the operating software required by the device's onboard microcontroller. Normally, it is stored in Flash EPROM, but some manufacturers use RAM based firmware stores for cost and upgradeability reasons. This means that while the code for a firmware image may be closed, the code itself does not run within the operating system's kernel space. Firmware images are acceptable to OpenBSD because they do not operate within the kernel space - as a binary driver does - and will redistribute said images as long as the manufacturers allow them to without restriction.[4]

See also

Notes and references

  1. ^ 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 2006-06-22.{{cite web}}: CS1 maint: multiple names: authors list (link) CS1 maint: numeric names: authors list (link)
  2. ^ An article by Kelly Martin of SecurityFocus regarding the hacking of a Wi-Fi binary blob driver - August 3, 2006. "WiFi makes waves at Blackhat". Retrieved 2006-08-25.{{cite web}}: CS1 maint: numeric names: authors list (link)
  3. ^ Matzan, Jem (2005-06-15). "BSD cognoscenti on Linux". NewsForge. Retrieved 2006-07-07. {{cite web}}: Check date values in: |date= (help) 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?"
  4. ^ "OpenBSD Works To Open Wireless Chipsets - November 2, 2004". Retrieved 2006-06-23.