Binary blob: Difference between revisions

Revision as of 19:11, 30 January 2023

Latest revision as of 23:37, 2 December 2024

(12 intermediate revisions by 7 users not shown)

Line 2:

{{distinguish|Binary large object{{!}}Binary large object (BLOB)}}

In the context of [[free and open-source software]], [[proprietary software]] only available as a [[executable|binary executable]] is referred to as a '''blob''' or '''binary blob'''. The term usually refers to a [[device driver]] [[Loadable kernel module|module]] [[Linker (computing)|loaded]] into the [[Kernel (computeroperating sciencesystem)|kernel]] of an open-source [[operating system]], and is sometimes also applied to code running outside the kernel, such as system [[firmware]] images, [[microcode]] updates, or [[User space and kernel space|userland]] programs.<ref>{{cite web

| url = https://www.phoronix.com/scan.php?page=news_item&px=MTE1NDc

| title = Coreboot: Replacing Intel's Binary Video BIOS Blob

Line 34:

}}</ref> The term ''[[Binary large object|blob]]'' was first used in [[database management system]]s 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#Open-source software support|Nvidia]], do not provide complete documentation for some of their products and instead provide binary-only drivers. This practice is most common for [[GPUGraphics processing unit|accelerated graphics]] drivers, [[Wireless network interface controller|wireless networking device]]s, and hardware [[RAIDDisk array controller|RAID controllers]]s.<ref>{{cite web | url = https://packages.debian.org/source/sid/firmware-nonfree | title = Debian packages built from the source package 'firmware-nonfree' - Binary firmware for various drivers in the Linux kernel | year = 2010 | access-date = 2010-03-25}}</ref> Most notably, binaryclosed-source blobsdrivers are very uncommon for non-wireless [[network interface controller]]s, which can almost always be configured via standard utilities (like [[ifconfig]]) out of the box; [[Theo de Raadt]] of [[OpenBSD]] attributes this to the work done by a single [[FreeBSD]] developer.<ref name=lor-opencon06>{{cite web

|author= Constantine A. Murenin |date= 2006-12-10

|url= https://www.linux.org.ru/news/hardware/1690470

Line 74:

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."<ref>{{cite web|url=https://lwn.net/1999/0211/a/lt-binary.html|title=a/lt-binary|work=lwn.net}}</ref> 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."<ref>{{cite web|url=https://lwn.net/Articles/287056/|title=A position statement on Linux Kernel Modules|date=June 2008|author=Greg Kroah-Hartman|author-link=Greg Kroah-Hartman|publisher=[[The Linux Foundation]]}}</ref> The Linux kernel maintainer [[Greg Kroah-Hartman]] has stated that it is illegal to redistribute closed source modules for the [[GNU General Public License|GNU General Public License-licensed]] Linux kernel.<ref>{{cite web|url=http://www.kroah.com/log/linux/ols_2006_keynote.html|author=Greg Kroah-Hartman|author-link=Greg Kroah-Hartman|publisher=[[Linux Symposium]]|title=Myths, Lies, and Truths about the Linux kernel|year=2006}}</ref>

However, the Linux kernel contains closed-source firmware required by various device drivers.{{r|gnu/free-sys-d-g--nonfree-fw|q1=Nonfree Firmware|gnu/common-d}} [[Alexandre Oliva]], the maintainer of [[Linux-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."<ref>{{cite web|url=https://www.fsfla.org/ikiwiki/anuncio/2010-03-Linux-2.6.33-libre.en|title=::[FSFLA]:: Take your freedom back, with Linux-2.6.33-libre|work=fsfla.org}}</ref>

Most of the drivers for [[mobile device]]s running the [[Android (OSoperating system)|Android 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 require [[reverse- engineering]], reimplementing the proprietary device drivers as free software, creating and debugging wrappers, [[binary patch]]ing, or a combination of these steps, all of which implies that legacy devices will never get the latest Android version.{{citation needed|date=March 2019}}

== Problems ==

Line 91:

== Use via wrappers ==

A [[Driver wrapper|wrapper]] is software which allows one operating system to use a binary proprietary device driver written for another operating system. Examples of wrappers are [[NdisWrapperNDISwrapper]] 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 [[Network Driver Interface Specification|NDIS]] [[Application programming interface|API]].

Another example is providing compatibility layers so that foreign utilities could be used to service the hardware. Examples include some [[Disk array controller|RAID controller]] drivers in [[FreeBSD]], where the [[system administrator]] would have to enable [[FreeBSD#OS compatibility layers|Linux compatibility layer in FreeBSD]] and independently procure Linux-specific binary blobs directly from the hardware manufacturer in order to monitor and service the hardware.<ref name=f-aac>{{cite web

|url= http://bxr.su/f/share/man/man4/aac.4

|title= aac(4) — Adaptec AdvancedRAID Controller driver

Line 119:

|quote= drivers designed for binary only Linux RAID management tools

}}</ref>

Circa 2005, this state of affairs prompted [[OpenBSD]] to create and popularise its [[bioctl|bio(4)]], [[bioctl]] and [[sensor drive]] concepts as an alternative solution for [[RAID]] monitoring,<ref name=theo-misc-38>{{cite mailing list

|url= //marc.info/?l=openbsd-misc&m=112630095818062

|author= Theo de Raadt

Line 134:

== Device firmware ==

{{main|Firmware|Microcode}}

[[Firmware]] is the software required by the onboard [[microcontroller]]s that accompanyaccompanied by some hardware, is generally not considered to be a binary blob.{{r|kerneltrap/4118|gnu/common-d|p2=BSD|kerneltrap/6497|p3=...|q3=Firmwares are not considered blobs}} In many devices, firmware is stored in [[non-volatile]] onboard [[flash memory]], but to decrease costs and ease upgradesto fix bugs, some devices contain only [[static RAM]] and require the host operating system to upload firmware / microcode each time they are connectedpowered (especially [[USB]] devices)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 a [[DMA 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;<ref name="kerneltrap/4118">{{cite web |title=OpenBSD Works To Open Wireless Chipsets |date=November 2, 2004 |publisher=KernelTrap |url=http://kerneltrap.org/node/4118 |access-date=2006-06-23 |url-status=dead |archive-url=https://web.archive.org/web/20060620051155/http://kerneltrap.org/node/4118 |archive-date=2006-06-20 }}</ref><ref>{{cite web |url= http://openbsd.su/src/sys/dev/microcode/ |title=/sys/dev/microcode/ |work= [[OpenBSD]] }}</ref> if free and unconditional redistribution is not permitted by the vendor, the machine instructions on fetching these images may be provided in the [[OpenBSD ports|ports]] tree (which precludes some encumbered wireless devices (e.g., Intel Wireless) from being available during the initial install).<ref name=o-ports>{{cite web |url= http://openbsd.su/ports/sysutils/firmware |title=sysutils/firmware |work= [[OpenBSD ports]]}}</ref> On Microsoft Windows implementations, the microcode binary may be embedded in the SYS / DLL / VXD device driver directly, as opposed to separated microcode file.

== BIOS and UEFI==

Line 194:

[[Category:Free software culture and documents]]

[[Category:Pejorative terms related to technology]]

[[Category:Firmware]]

[[Category:Device drivers]]

[[Category:Booting]]