Binary blobs

This article is about drivers. For the database data type, see binary large object.

In the context of open source software, a binary blob is a closed source binary-only driver without publicly available source code. The term usually refers to closed-source kernel module loaded into the kernel of an open source operating system, and is usually not applied to code running outside the kernel, such as BIOS code, firmware images, or userland programs. The term blob was first used in database management system to describe a collection of binary data stored as a single entity.

When computer hardware vendors provide complete technical documentation for their products, operating system developers are able to write hardware device drivers to be included in the operating system kernels. However, some vendors, such as NVIDIA, do not provide complete documentation for some of their products and instead provide binary-only drivers (binary blobs); this practice is most common for accelerated graphics drivers, networking devices and RAID controllers.[1]


Some projects try to create a free operating system, and will not accept binary blobs if they cannot get documentation for hardware or source code for device drivers. Such projects include NetBSD, FreeBSD, DragonFly BSD, and some GNU/Linux distributions.[2]

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 the encroachment onto the openness and freedom of its software.[3]

The Free Software Foundation (FSF) is actively campaigning against binary blobs.[4] It also considers OpenBSD's policy flawed, as 'blobs' in the BSD community refer to what it considers non-free drivers, and not non-free firmware.[5]

The Debian project included both free and non-free binary firmware blobs from the Linux kernel, clearly marking and separating the non-free packages[6] according to the Debian Social Contract. As of Debian 6.0 those blobs were removed. [7]

For OpenBSD, project leader Theo de Raadt defends the policy of only asking for distribution rights for microcode firmware blobs. "Once they are distributed... at least the device works." Implying that the alternative would be for the members of his small project to code free firmware themselves in the assembly language of many chipsets, he pleads "don't load us up with more tasks." Despite this he favours chipsets that run without firmware and speaks warmly of Asian designs which he describes as slower to market but more mature.[3]

In the Linux kernel development community, Linus Torvalds has made strong statements on the issue of binary-only modules, asserting: "I refuse to even consider tying my hands over some binary-only module", and continuing: "I want people to know that when they use binary-only modules, it's THEIR problem".[8] In 2008, 176 Linux kernel developers signed a Position Statement on Linux Kernel Modules that stated "We, the undersigned Linux kernel developers, consider any closed-source Linux kernel module or driver to be harmful and undesirable... We have repeatedly found them to be detrimental to Linux users, businesses, and the greater Linux ecosystem."[9]


Prominent Linux kernel developer Greg Kroah-Hartman has stated that it is illegal to redistribute closed source modules for the GPL-licensed Linux kernel.[10]


There are a number of reasons why binary blobs can cause problems.[11]

Firstly, their precise operation is not known and bugs cannot be detected by auditing source code, but are frequently only diagnosed by painstaking detective work when a system begins to behave unexpectedly. Such undetected bugs may also silently expose users and systems to security hazards. The fitness for purpose of the driver thus cannot be checked, and even if a bug is found there is no way to fix it.

Secondly because the source code is not available the driver cannot be improved by its users, nor ported from one architecture to another not originally supported, nor adapted to operate slight variants of the hardware.

Finally, users are forced to trust vendors or malicious third parties not to put backdoors and spyware into the blob. Again on the theme of trust, the hardware vendor can decide not to support some operating systems, or to abandon driver maintenance at any time, or simply go out of business leaving the driver in limbo.

Use via wrappers

A wrapper is software which allows one operating system to use a binary blob driver written for another operating system. Examples of wrappers are NdisWrapper for Linux, and Project Evil for FreeBSD and NetBSD. These wrappers allow these operating systems to use network drivers written for Microsoft Windows by implementing Microsoft's NDIS API.

Device firmware

Firmware, the software required by the onboard microcontrollers that accompany some hardware, is generally not considered to be a binary blob. In many devices, firmware is stored in non-volatile onboard flash memory, but to decrease costs and ease upgrades, some devices contain only static RAM and require the host operating system to upload firmware each time they are connected (especially USB devices). Although the firmware is thus present in the operating system driver, it is merely copied to the device and not executed by the CPU, lessening concerns about hidden security flaws. The OpenBSD project accepts binary firmware images and will redistribute these images if the license permits.[12]


The BIOS, which functions as a bootloader and supports legacy real mode applications, is a crucial component of many IBM-compatible computers. The BIOS is always 16-bit, often has networking functions, and can be a security backdoor (sometimes deliberate,[13][14] and the operating system has no control over this backdoor).[15] The FSF promotes coreboot in its campaign for free BIOS firmware.[16]

See also

Free software portal


External links

  • 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
This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.