In the context offree and open-source software,proprietary software only available as abinary executable is referred to as ablob orbinary blob. The term usually refers to adevice drivermoduleloaded into thekernel of an open-sourceoperating system, and is sometimes also applied to code running outside the kernel, such as systemfirmware images,microcode updates, oruserland programs.[1][2][3][4][5][6] The termblob was first used indatabase management systems to describe a collection ofbinary data stored as a single entity.
Whencomputer 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 asNvidia, do not provide complete documentation for some of their products and instead provide binary-only drivers. This practice is most common foraccelerated graphics drivers,wireless networking devices, and hardwareRAID controllers.[7] Most notably, closed-source drivers are very uncommon for non-wirelessnetwork interface controllers, which can almost always be configured via standard utilities (likeifconfig) out of the box;Theo de Raadt ofOpenBSD attributes this to the work done by a singleFreeBSD developer.[8][9]
SomeFSF-approved projects strive to provide afree operating system and will remove all binary blobs when no documentation for hardware orsource code for device drivers and all applicable firmware is available; such projects includeLinux-libre kernel packaging fromFSFLA,Parabola,Devuan,Trisquel, andLibreCMC.[10] However, the vast majority of open-source projects make a distinction between binary-only device drivers (blobs) and binary-only firmware (not considered blobs[11]: ... ), allowing for certain proprietary firmware to be freely distributed as part of their kernels, and, to the disagreement of some core contributors, also support the use of proprietary device drivers that are distributed externally, providing internal compatibility interfaces for such proprietary drivers and userspace components to work with their system.[12][13] Projects following this policy include theLinux kernel itself,NetBSD,FreeBSD,DragonFly BSD, and mostLinux distributions.[14] Some of these projects do provide options for building the system without proprietary firmware, thus excluding sourceless microcode on demand.[15]
TheOpenBSD project has a notable policy of not only not accepting any binary device drivers into its source tree, but also officially not supporting any third-party proprietary device driver components on its platform, either;[16]: 38... citing not only the potential for undetectable or irreparable security flaws, but also the encroachment onto the openness and freedom of its software.[17] TheFree Software Foundation (FSF) is actively campaigning against binary blobs.[18] FSF also considers OpenBSD's policy confusingly worded, as "blobs" in the BSD community refer only to what it considers non-free drivers, and does not apply to proprietary firmware and sourceless microcode.[19]: BSD TheDebian project included both free and non-free binary firmware from theLinux kernel, clearly marking and separating the non-free packages[20] according to theDebian Social Contract. As of Debian 6.0 those blobs were removed.[19]: Debian
For OpenBSD, project leaderTheo de Raadt defends the policy of asking for distribution rights only for microcode firmware. "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.[17]
In theLinux kernel development community,Linus Torvalds has made strong statements on the issue of binary-only modules, asserting: "Irefuse 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."[21] In 2008, 176 Linux kernel developers signed aPosition 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."[22] The Linux kernel maintainerGreg Kroah-Hartman has stated that it is illegal to redistribute closed source modules for theGNU General Public License-licensed Linux kernel.[23]
However, the Linux kernel contains closed-source firmware required by various device drivers.[24][19] Alexandre Oliva, the maintainer ofLinux-libre, a version of the Linux kernel that attempts to remove all binary blobs, including sourceless microcode, wrote in 2011: "Linux hasn't been Free Software since 1996, when Mr Torvalds accepted the first pieces of non-Free Software in the distributions of Linux he has published since 1991. Over these years, while this kernel grew by a factor of 14, the amount of non-Free firmware required by Linux drivers grew by an alarming factor of 83."[25]
Most of the drivers formobile devices running theAndroid operating system are shipped in binary and are linked against a specific version of the Linux kernel. This makes it very hard to upgrade a kernel version because it may requirereverse engineering, reimplementing the proprietary device drivers as free software, creating and debugging wrappers,binary patching, or a combination of these steps, all of which implies that legacy devices will never get the latest Android version.[citation needed]
 | This sectionis written like apersonal reflection, personal essay, or argumentative essay that states a Wikipedia editor's personal feelings or presents an original argument about a topic. Pleasehelp improve it by rewriting it in anencyclopedic style.(March 2021) (Learn how and when to remove this message) |
There are a number of reasons why executable binary blobs can be problematic.[11]
Firstly, their precise operation cannot be known and bugs cannot be detected by auditing source code; bugs are frequently only diagnosed by painstaking investigation 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 easy way to fix it.
Secondly, as thesource code is not available, the driver cannot be readily improved by its users, cannot be ported to architectures not originally supported, nor adapted to operate for slight variants of the hardware or updated it to be workable in new kernels having the changed API and architecture.[citation needed]
Thirdly, using this software would force users to trust vendors or third parties not to put backdoors, spyware or malicious code into the blob. As well, the hardware vendor can decide not to support a given operating system, abandon driver maintenance at any time, or, in the event the company goes out of business, leave the driver completely unsupported.
Finally, binary blobs can be seen as drawing a line between the portion of the community that believes in free software ideals, rejecting proprietary software, and the portion that sees open source as desirable for purely technical reasons, often lacking a strong opposition to binary blobs "as long as they work". This fragmentation, and the acceptance of a growing number of proprietary components into Linux, is seen as weakening the ability of the community to resist the trend of manufacturers to increasingly refuse to provide documentation for their binaries.[citation needed]
Awrapper is software which allows one operating system to use a binary proprietary device driver written for another operating system. Examples of wrappers areNDISwrapper forLinux, andProject Evil forFreeBSD andNetBSD. These wrappers allow these operating systems to use network drivers written forMicrosoft Windows by implementingMicrosoft'sNDISAPI.
Another example is providing compatibility layers so that foreign utilities could be used to service the hardware. Examples include someRAID controller drivers inFreeBSD, where thesystem administrator would have to enableLinux compatibility layer in FreeBSD and independently procure Linux-specific binary blobs directly from the hardware manufacturer in order to monitor and service the hardware.[12][13][26]Circa 2005, this state of affairs promptedOpenBSD to create and popularise itsbio(4),bioctl andsensor drive concepts as an alternative solution forRAID monitoring,[27][16] both of which concepts have subsequently found its way intoNetBSD as well.
Firmware is the software required by the onboardcontrollers that accompanied by some hardware, is generally not considered to be a binary blob.[28][19]: BSD [11]: ... In many devices, firmware is stored innon-volatile onboardflash memory, but to decrease costs and ease to fix bugs, some devices contain onlystatic RAM and require the host operating system to upload firmware / microcode each time they are powered on. Although the firmware is thus present in the operating system driver, it is merely copied to the device and not executed by the CPU, removing concerns about extra security flaws compared to what's already possible with aDMA attack even if the firmware was already stored within the device at all times. The OpenBSD project accepts binary firmware/microcode images and will redistribute these images if the license permits;[28][29] if free and unconditional redistribution is not permitted by the vendor, the machine instructions on fetching these images may be provided in theports tree (which precludes some encumbered wireless devices (e.g., Intel Wireless) from being available during the initial install).[30] On Microsoft Windows implementations, the microcode binary may be embedded in the SYS / DLL / VXD device driver directly, as opposed to separated microcode file.
TheBIOS, which functions as abootloader and supports legacyreal mode applications, is a crucial component of manyIBM-compatible computers. In the late 1990s work started on EFI (Extensible Firmware Interface) with the objective to move legacy BIOS to a modern interface with a modular driver model. EFI is closed source and was eventually adopted by many industry leading hardware manufacturers asUEFI (Unified Extensible Firmware Interface). The EDK (EFI Development Kit) was developed to assist EFI firmware development projects.[31]
Also in the late 1990s, thecoreboot project was started to create an open source alternative to legacy BIOS from scratch.[31] The coreboot developer community organises aroundStefan Reinauer and is led by firmware developers with commit rights.[32] Despite closed source binary firmware having been at the heart of thex86 architecture coreboot only incorporates the few proprietary binaries that are necessary to provide users with a base level hardware support.[33] A completely open source alternative to BIOS and UEFI islibreboot, which was promoted by theFree Software Foundation (FSF).[34]
Blobs are vendor-compiled binary drivers without any source code.
Only a few recalcitrant vendors remain closed. / ethernet 95% documented 99% working / Open documentation largely due to the effort of one man: Bill Paul
If the kernel is compiled with the COMPAT_LINUX option, or the aac_linux.ko and linux.ko modules are loaded...
If the kernel is compiled with the COMPAT_LINUX option, or the aacraid_linux.ko and linux.ko modules are loaded...
drivers designed for binary only Linux RAID management tools
| General | |||
|---|---|---|---|
| Software packages | |||
| Community | |||
| Organisations | |||
| Licenses |
| ||
| Challenges | |||
| Related topics | |||
