| Revision as of 00:57, 26 June 2017 editArzg (talk | contribs)Extended confirmed users508 edits Attempt to disambiguate blobs →Acceptance← Previous edit | Latest revision as of 23:37, 2 December 2024 edit undoBeeblebrox (talk | contribs)Autopatrolled, Administrators113,726 editsm Removing link(s) Misplaced Pages:Articles for deletion/Alexandre Oliva closed as delete (XFDcloser) | ||
| (97 intermediate revisions by 46 users not shown) | |||
| Line 1: | Line 1: | ||
| {{short description|Software published only in binary code}} | |||
| {{About|drivers|the database data type|binary large object}} | |||
| {{distinguish|Binary large object{{!}}Binary large object (BLOB)}} | |||
| {{Cleanup rewrite|the article's POV and style is not neutral. It contains contradictory and confusing content|date=April 2012}} | |||
| In the context of ], |
In the context of ], ] only available as a ] is referred to as a '''blob''' or '''binary blob'''. The term usually refers to a ] ] ] into the ] of an open-source ], and is sometimes also applied to code running outside the kernel, such as system ] images, ] updates, or ] programs.<ref>{{cite web | ||
| | url = https://www.phoronix.com/scan.php?page=news_item&px=MTE1NDc | | url = https://www.phoronix.com/scan.php?page=news_item&px=MTE1NDc | ||
| | title = Coreboot: Replacing Intel's Binary Video BIOS Blob | | title = Coreboot: Replacing Intel's Binary Video BIOS Blob | ||
| | date = 2012-08-06 | |
| date = 2012-08-06 | access-date = 2015-06-23 | ||
| | author = Michael Larabel | publisher = ] | | author = Michael Larabel | publisher = ] | ||
| }}</ref><ref>{{cite web | }}</ref><ref>{{cite web | ||
| | url = http://www.pcworld.com/article/2883903/how-intel-and-pc-makers-prevent-you-from-modifying-your-pcs-firmware.html | | url = http://www.pcworld.com/article/2883903/how-intel-and-pc-makers-prevent-you-from-modifying-your-pcs-firmware.html | ||
| | title = How Intel and PC makers prevent you from modifying your laptop's firmware | | title = How Intel and PC makers prevent you from modifying your laptop's firmware | ||
| | date = 2015-02-13 | |
| date = 2015-02-13 | access-date = 2015-06-23 | ||
| | author = Chris Hoffmann | website = pcworld.com | | author = Chris Hoffmann | website = pcworld.com | ||
| }}</ref><ref>{{cite web | }}</ref><ref>{{cite web | ||
| | url = https://puri.sm/posts/bios-freedom-status/ | | url = https://puri.sm/posts/bios-freedom-status/ | ||
| | title = BIOS Freedom Status | | title = BIOS Freedom Status | ||
| | date = 2014-11-12 | |
| date = 2014-11-12 | access-date = 2015-06-23 | ||
| | website = puri.sm | | website = puri.sm | ||
| }}</ref><ref>{{cite web | }}</ref><ref>{{cite web | ||
| | url = https://www.phoronix.com/scan.php?page=news_item&px=MTIxNDk | | url = https://www.phoronix.com/scan.php?page=news_item&px=MTIxNDk | ||
| | title = Raspberry Pi GPU Driver Turns Out To Be Crap | | title = Raspberry Pi GPU Driver Turns Out To Be Crap | ||
| | date = 2012-10-24 | |
| date = 2012-10-24 | access-date = 2015-06-23 | ||
| | author = Michael Larabel | publisher = ] | | author = Michael Larabel | publisher = ] | ||
| }}</ref><ref>{{cite web | }}</ref><ref>{{cite web | ||
| | url = https://lwn.net/Articles/648392/ | | url = https://lwn.net/Articles/648392/ | ||
| | title = Chromium suddenly starts downloading a binary blob | | title = Chromium suddenly starts downloading a binary blob | ||
| | date = 2015-06-17 | |
| date = 2015-06-17 | access-date = 2015-06-23 | ||
| | author = Jake Edge | publisher = ] | | author = Jake Edge | publisher = ] | ||
| }}</ref><ref name=lyrics-39>{{cite web | |||
| |url= http://www.openbsd.org/lyrics.html#39 | |||
| |title= 3.9: "Blob!" | |||
| |work= OpenBSD Release Songs |publisher= ] |date= 2006-05-01 | |||
| |quote= Blobs are vendor-compiled binary drivers without any source code. | |||
| }}</ref> The term '']'' was first used in ]s to describe a collection of ] stored as a single entity. | }}</ref> The term '']'' was first used in ]s to describe a collection of ] stored as a single entity. | ||
| When ] 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, |
When ] 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 ], do not provide complete documentation for some of their products and instead provide binary-only drivers. This practice is most common for ] drivers, ]s, and hardware ].<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, closed-source drivers are very uncommon for non-wireless ]s, which can almost always be configured via standard utilities (like ]) out of the box; ] of ] attributes this to the work done by a single ] developer.<ref name=lor-opencon06>{{cite web | ||
| |author= Constantine A. Murenin |date= 2006-12-10 | |||
| |url= https://www.linux.org.ru/news/hardware/1690470 | |||
| |language= ru |title= Почему так важно иметь документацию по программированию железа | |||
| |website= Linux.org.ru | |||
| }}</ref><ref name=wpaul-rocks>{{cite conference | |||
| |author= Theo de Raadt | |||
| |author-link= Theo de Raadt | |||
| |date= 2016-12-03 | |||
| |section-url= //www.openbsd.org/papers/opencon06-docs/mgp00011.html | |||
| |section= Page 11: The hardware: ethernet | |||
| |url= //www.openbsd.org/papers/opencon06-docs/ | |||
| |title= Open Documentation for Hardware | |||
| |conference-url= //web.archive.org/web/20070109032258/http://www.opencon.org/program.php | |||
| |conference= OpenCON 2006, 2–3 December 2006 | |||
| |location= Courtyard Venice Airport, Venice/Tessera, Italy | |||
| |quote= Only a few recalcitrant vendors remain closed. / ethernet 95% documented 99% working / Open documentation largely due to the effort of one man: Bill Paul | |||
| }}</ref> | |||
| == |
== Policy by project == | ||
| Some projects |
Some ]-approved projects strive to provide a ] operating system and will remove all binary blobs when no documentation for hardware or ] for device drivers and all applicable firmware is available; such projects include ] kernel packaging from ], ], ], ], and ].{{r|gnu/free-distros}} However, the vast majority of open-source projects make a distinction between binary-only device drivers (blobs) and binary-only firmware (not considered blobs{{r|kerneltrap/6497|p=...|q=Firmwares are not considered blobs}}), 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.{{r|f-aac|f-aacraid}} Projects following this policy include the ] itself, ], ], ], and most ]s.<ref name="bsdinterview">{{cite web | url = http://os.newsforge.com/os/05/06/09/2132233.shtml?tid=8&tid=2 | title = BSD cognoscenti on Linux | access-date = 2006-07-07 | last = Matzan | first = Jem | date = 15 June 2005 | publisher = NewsForge | url-status = dead | archive-url = https://web.archive.org/web/20060323022626/http://os.newsforge.com/os/05/06/09/2132233.shtml?tid=8&tid=2 | archive-date = 23 March 2006 }} 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?"</ref> Some of these projects do provide options for building the system without proprietary firmware, thus excluding sourceless microcode on demand.<ref name=f-sourceless-ucode>{{cite web |url= http://bxr.su/f/tools/build/options/WITHOUT_SOURCELESS_UCODE |title= build/options/WITHOUT_SOURCELESS_UCODE |website= BSD Cross Reference |publisher= ] |date= 2012-02-04}}</ref> | ||
| The ] project has a notable policy of not accepting any binary device drivers into its source tree |
The ] 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;{{r|lyrics-38|p=38...|q=we refuse to accept our users being forced into depending on vendor binaries}} citing not only the potential for undetectable or irreparable security flaws, but also the encroachment onto the openness and freedom of its software.<ref name="deraadt_interview_200605">{{citation | ||
| |url=http://kerneltrap.org/node/6550 | |url=http://kerneltrap.org/node/6550 | ||
| |title=Interview: Theo de Raadt | |title=Interview: Theo de Raadt | ||
| Line 42: | Line 64: | ||
| |publisher=Jeremy Andrews | |publisher=Jeremy Andrews | ||
| |date=2006-05-02 | |date=2006-05-02 | ||
| | |
|archive-url=https://web.archive.org/web/20060603230017/http://kerneltrap.org/node/6550 | ||
| | |
|archive-date=2006-06-03 | ||
| | |
|url-status=dead | ||
| }}</ref> The ] (FSF) is actively campaigning against binary blobs.<ref>{{cite web|url=https://www.fsf.org/blogs/community/rms-ati-protest.html|title=Protest against ATI nearly led to the arrest of RMS|date=27 April 2006|access-date=2006-10-10|publisher=Free Software Foundation}}</ref> 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.{{r|gnu/common-d|p=BSD}} The ] project included both free and non-free binary firmware from the ], clearly marking and separating the non-free packages<ref>{{cite web | url = https://packages.debian.org/firmware-linux | title = Debian firmware-linux packages | year = 2010 | access-date = 2010-03-25}}</ref> according to the ]. As of Debian 6.0 those blobs were removed.{{r|gnu/common-d|p=Debian}} | |||
| |df= | |||
| }}</ref> The ] (FSF) is actively campaigning against binary blobs.<ref>{{cite web|url=https://www.fsf.org/blogs/community/rms-ati-protest.html|title=Protest against ATI nearly led to the arrest of RMS|date=27 April 2006|accessdate=2006-10-10|publisher=Free Software Foundation}}</ref> It also considers OpenBSD's policy confusingly worded, as "blobs" in the BSD community refer to what it considers non-free drivers, and not non-free firmware.<ref>{{cite web|url=https://www.gnu.org/distros/common-distros.html#BSD|title=Explaining Why We Don't Endorse Other Systems|date=July 13, 2011|accessdate=2011-09-10|publisher=GNU Project}}</ref> The ] project included both free and non-free binary firmware blobs from the ], clearly marking and separating the non-free packages<ref>{{cite web | url = https://packages.debian.org/firmware-linux | title = Debian firmware-linux packages | year = 2010 | accessdate = 2010-03-25}}</ref> according to the ]. As of Debian 6.0 those blobs were removed.<ref>{{cite web | url =https://www.gnu.org/distros/common-distros.en.html#Debian | title = Explaining Why We Don't Endorse Other Systems # Debian | year = 2013 | accessdate = 2013-03-29}}</ref> | |||
| For OpenBSD, project leader Theo de Raadt defends the policy of |
For OpenBSD, project leader ] 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.<ref name="deraadt_interview_200605" /> | ||
| ]}}, will share the same ] infrastructure with ]. As there is no stable in-kernel ], AMD had to constantly adapt the former binary blob used by Catalyst.]] | |||
| In the ] development community, ] 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=]|publisher=]}}</ref> | |||
| In the ] development community, ] 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=]}}</ref> The Linux kernel maintainer ] has stated that it is illegal to redistribute closed source modules for the ] 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=]|title=Myths, Lies, and Truths about the Linux kernel|year=2006}}</ref> | |||
| However, the Linux kernel contains |
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 ], 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=:::: Take your freedom back, with Linux-2.6.33-libre|work=fsfla.org}}</ref> | ||
| Most of the drivers for ]s running the ] 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 ], reimplementing the proprietary device drivers as free software, creating and debugging wrappers, ]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}} | |||
| == Legality == | |||
| Prominent Linux kernel developer ] has stated that it is illegal to redistribute closed source modules for the GPL-licensed Linux kernel.<ref>{{cite web|url=http://www.kroah.com/log/linux/ols_2006_keynote.html|author=]|publisher=]|title=Myths, Lies, and Truths about the Linux kernel|year=2006|quote=So, here's the simple answer to this issue: Closed source Linux kernel modules are illegal. That's it, it is very simple. I've had the misfortune of talking to a lot of different IP lawyers over the years about this topic, and every one that I've talked to all agree that there is no way that anyone can create a Linux kernel module, today, that can be closed source. It just violates the GPL due to fun things like derivative works and linking and other stuff. Again, it's very simple. Now no lawyer will ever come out in public and say this, as lawyer really aren't allowed to make public statements like this at all. But if you hire one, and talk to them in the client/lawyer setting, they will advise you of this issue.}}</ref> | |||
| == Problems == | == Problems == | ||
| {{ |
{{Essay-like|section|date=March 2021}} | ||
| There are a number of reasons why binary blobs can be problematic.<ref>{{cite web|url=http://kerneltrap.org/node/6497 |first=Jeremy |last=Andrews |title=Interview with Jonathan Gray and Damien Bergamini | |
There are a number of reasons why binary blobs can be problematic.<ref name="kerneltrap/6497">{{cite web |url=http://kerneltrap.org/node/6497 |first=Jeremy |last=Andrews |title=Interview with Jonathan Gray and Damien Bergamini |access-date=2008-01-06 |date=2006-04-19 |publisher=kerneltrap.org |url-status=dead |archive-url=https://web.archive.org/web/20071211025952/http://kerneltrap.org/node/6497 |archive-date=2007-12-11 }}</ref> | ||
| 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. | 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 the ] 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. | Secondly, as the ] 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. | ||
| 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. | 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. | ||
| Line 70: | Line 91: | ||
| == Use via wrappers == | == Use via wrappers == | ||
| A ] is software which allows one operating system to use a binary |
A ] is software which allows one operating system to use a binary proprietary device driver written for another operating system. Examples of wrappers are ] for ], and ] for ] and ]. These wrappers allow these operating systems to use network drivers written for ] by implementing ]'s ] ]. | ||
| Another example is providing compatibility layers so that foreign utilities could be used to service the hardware. Examples include some ] drivers in ], where the ] would have to enable ] 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 | |||
| |website= BSD Cross Reference |publisher= ] | |||
| |author1= Scott Long |author2= Adaptec, Inc |author2-link= Adaptec |date= 2000 | |||
| |quote= If the kernel is compiled with the COMPAT_LINUX option, or the aac_linux.ko and linux.ko modules are loaded... | |||
| }} | |||
| *{{cite book |section=aac -- Adaptec AdvancedRAID Controller driver |title=FreeBSD Manual Pages |url= http://mdoc.su/f/aac.4}}</ref><ref name=f-aacraid>{{cite web | |||
| |url= http://bxr.su/f/share/man/man4/aacraid.4 | |||
| |title= aacraid(4) — Adaptec AACRAID Controller driver | |||
| |website= BSD Cross Reference |publisher= ] | |||
| |author1= Achim Leubner |date= 2013 | |||
| |quote= If the kernel is compiled with the COMPAT_LINUX option, or the aacraid_linux.ko and linux.ko modules are loaded... | |||
| }} | |||
| *{{cite book |section=aacraid -- Adaptec AACRAID Controller driver |title=FreeBSD Manual Pages |url=http://mdoc.su/f/aacraid.4}}</ref><ref name=opencon06-drivers-f>{{Cite conference | |||
| |author= Jonathan Gray |date= 2006-12-02 | |||
| |section-url= http://www.openbsd.org/papers/opencon06-drivers/mgp00026.html | |||
| |section= Page 26: Only open for business: FreeBSD | |||
| |url= http://www.openbsd.org/papers/opencon06-drivers/index.html | |||
| |title= Driver Architecture and Implementation in OpenBSD | |||
| |conference-url= https://web.archive.org/web/20070109032258/http://www.opencon.org/program.php | |||
| |conference= OpenCON 2006, 2–3 December 2006 | |||
| |location= Courtyard Venice Airport, Venice/Tessera, Italy | |||
| |access-date= 2019-03-27 | |||
| |quote= drivers designed for binary only Linux RAID management tools | |||
| }}</ref> | |||
| Circa 2005, this state of affairs prompted ] to create and popularise its ], ] and ] concepts as an alternative solution for ] monitoring,<ref name=theo-misc-38>{{cite mailing list | |||
| |url= //marc.info/?l=openbsd-misc&m=112630095818062 | |||
| |author= Theo de Raadt | |||
| |author-link= Theo de Raadt | |||
| |date= 2005-09-09 | |||
| |title= RAID management support coming in OpenBSD 3.8 | |||
| |mailing-list= misc@ |publisher= ] | |||
| }}</ref><ref name=lyrics-38>{{cite web | |||
| |url= http://www.openbsd.org/lyrics.html#38 | |||
| |title= 3.8: "Hackers of the Lost RAID" | |||
| |work= OpenBSD Release Songs |publisher= ] |date= 2005-11-01 | |||
| }}</ref> both of which concepts have subsequently found its way into ] as well. | |||
| == Device firmware == | == Device firmware == | ||
| {{main|Firmware|Microcode}} | |||
| ], the software required by the onboard ]s that accompany some hardware, is generally not considered to be a binary blob{{Citation needed|date=September 2013}}. In many devices, firmware is stored in ] onboard ], but to decrease costs and ease upgrades, some devices contain only ] and require the host operating system to upload firmware each time they are connected (especially ] 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{{Citation needed|date=October 2014}}. The OpenBSD project accepts binary firmware images and will redistribute these images if the license permits.<ref>{{cite web|title=OpenBSD Works To Open Wireless Chipsets |date=November 2, 2004 |publisher=KernelTrap |url=http://kerneltrap.org/node/4118 |accessdate=2006-06-23 |deadurl=yes |archiveurl=https://web.archive.org/web/20060620051155/http://kerneltrap.org:80/node/4118 |archivedate=2006-06-20 |df= }}</ref> | |||
| ] is the software required by the onboard ]s that accompanied 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 ] onboard ], but to decrease costs and ease to fix bugs, some devices contain only ] 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 a ] even if the firmware was already stored within the device at all times. The OpenBSD project accepts binary firmware/] 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= ] }}</ref> if free and unconditional redistribution is not permitted by the vendor, the machine instructions on fetching these images may be provided in the ] 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= ]}}</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 == | == BIOS and UEFI== | ||
| ], an open-source implementation of BIOS, running as coreboot payload on a Lenovo ] X60]] | |||
| The ], which functions as a ] and supports legacy ] applications, is a crucial component of many ] computers. The BIOS is always 16-bit, often has networking functions, and can be a security ] (sometimes deliberate,<ref>{{cite web|url=http://www.intel.com/content/www/us/en/architecture-and-technology/vpro/vpro-technology-general.html |title=Intel vPro Technology |publisher=Intel.com |date=2012-05-14 |accessdate=2014-04-10}}</ref><ref>{{cite web|url=https://www.absolute.com/en/partners/bios-compatibility.aspx |title=BIOS & Firmware Compatibility |publisher=Absolute.com |date= |accessdate=2014-04-10}}</ref>{{failed verification|date=April 2014}} and the operating system has no control over this backdoor).<ref>as per IBM PC specs</ref> The FSF promotes ] in its campaign for free BIOS firmware.<ref>{{cite web|url=https://www.fsf.org/campaigns/free-bios.html|title=Campaign for Free BIOS|publisher=Free Software Foundation|date=2006-11-29|accessdate=2007-01-02}}</ref> | |||
| The ], which functions as a ] and supports legacy ] applications, is a crucial component of many ] 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 as ] (Unified Extensible Firmware Interface). The EDK (EFI Development Kit) was developed to assist EFI firmware development projects.<ref name="Apress">{{cite book |author=Vincent Zimmer |author2=Jiming Sun |author3=Marc Jones |author4=Stefan Reinauer |date= 2015 |title= Embedded Firmware Solutions: Development Best Practices for the Internet of Things |publisher= Apress |isbn= 9781484200704 | page = 121}}</ref> | |||
| Also in the late 1990s, the ] project was started to create an open source alternative to legacy BIOS from scratch.<ref name="Apress"/> The coreboot developer community organises around ] and is led by firmware developers with commit rights.<ref>{{cite book |author=Vincent Zimmer |author2=Jiming Sun |author3=Marc Jones |author4=Stefan Reinauer |date= 2015 |title= Embedded Firmware Solutions: Development Best Practices for the Internet of Things |publisher= Apress |isbn= 9781484200704 | page = 61}}</ref> Despite closed source binary firmware having been at the heart of the ] architecture coreboot only incorporates the few proprietary binaries that are necessary to provide users with a base level hardware support.<ref>{{cite book |author=Vincent Zimmer |author2=Jiming Sun |author3=Marc Jones |author4=Stefan Reinauer |date= 2015 |title= Embedded Firmware Solutions: Development Best Practices for the Internet of Things |publisher= Apress |isbn= 9781484200704 | page = 65}}</ref> A completely open source alternative to BIOS and UEFI is ], which was promoted by the ] (FSF).<ref>{{cite web|url=https://www.fsf.org/campaigns/free-bios.html|title=Campaign for Free BIOS|publisher=Free Software Foundation|date=2006-11-29|access-date=2007-01-02}}</ref> | |||
| == See also == | == See also == | ||
| {{Portal|Free software}} | {{Portal|Free and open-source software}} | ||
| {{Div col| |
{{Div col|colwidth=22em}} | ||
| * ] | * ] | ||
| * ] | |||
| * ] | |||
| * ] | |||
| * ] | * ] | ||
| * ] | |||
| * ] | |||
| * ] | |||
| * ] | |||
| * ] | * ] | ||
| * ] | * ] | ||
| * ] | |||
| * ] | * ] | ||
| * ] NSA Binary blob backdoor | * ] NSA Binary blob backdoor | ||
| * ] | |||
| {{Div col end}} | |||
| {{div col end}} | |||
| == References == | == References == | ||
| {{reflist|refs= | |||
| {{Reflist|30em}} | |||
| <ref name="gnu/free-distros">{{cite web | |||
| |url= https://www.gnu.org/distros/free-distros.html | |||
| |title= List of Free GNU/Linux Distributions | |||
| |work= ] |publisher= ] | |||
| }}</ref> | |||
| <ref name="gnu/free-sys-d-g--nonfree-fw">{{cite web | |||
| |url= https://www.gnu.org/distros/free-system-distribution-guidelines.html#nonfree-firmware | |||
| |title= Nonfree Firmware | |||
| |work= {{Section link|GNU Project|Free System Distribution Guidelines (GNU FSDG)}} | |||
| |publisher= ] | |||
| }}</ref> | |||
| <ref name="gnu/common-d">{{cite web | |||
| |url= https://www.gnu.org/distros/common-distros.html | |||
| |title= Explaining Why We Don't Endorse Other Systems | |||
| |work= ] |publisher= ] | |||
| }}</ref> | |||
| }} | |||
| == External links == | == External links == | ||
| {{Wiktionary|blob}} | {{Wiktionary|blob}} | ||
| * {{cite web|last = McMillan|first = Robert|date = June 21, 2006|url = http://www.infoworld.com/article/06/06/21/79536_HNwifibreach_1.html|title = Researchers hack Wi-Fi driver to breach laptop|publisher = InfoWorld| |
* {{cite web|last = McMillan|first = Robert|date = June 21, 2006|url = http://www.infoworld.com/article/06/06/21/79536_HNwifibreach_1.html|title = Researchers hack Wi-Fi driver to breach laptop|publisher = InfoWorld|access-date = 2006-06-23|url-status = dead|archive-url = https://web.archive.org/web/20060702163150/http://www.infoworld.com/article/06/06/21/79536_HNwifibreach_1.html|archive-date = July 2, 2006}} | ||
| * on Damien Bergamini's wpi(4) driver, a blobless ipw3945 alternative for OpenBSD | * on Damien Bergamini's wpi(4) driver, a blobless ipw3945 alternative for OpenBSD | ||
| * with Jonathan Gray and Damien Bergamini regarding binary blobs | * with Jonathan Gray and Damien Bergamini regarding binary blobs | ||
| * by Brian Krebs on the Washington Post's website, archived on May 5, 2012 | * by Brian Krebs on the Washington Post's website, archived on May 5, 2012 | ||
| * , LWN.net | * , LWN.net | ||
| Line 109: | Line 193: | ||
| ] | ] | ||
| ] | ] | ||
| ] | |||
| ] | |||
| ] | |||
Latest revision as of 23:37, 2 December 2024
Software published only in binary code Not to be confused with Binary large object (BLOB).In the context of free and open-source software, proprietary software only available as a binary executable is referred to as a blob or binary blob. The term usually refers to a device driver module loaded into the 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 userland programs. The term blob was first used in database management systems 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. This practice is most common for accelerated graphics drivers, wireless networking devices, and hardware RAID controllers. Most notably, closed-source drivers are very uncommon for non-wireless network interface controllers, 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.
Policy by project
Some FSF-approved projects strive to provide a free operating system and will remove all binary blobs when no documentation for hardware or source code for device drivers and all applicable firmware is available; such projects include Linux-libre kernel packaging from FSFLA, Parabola, Devuan, Trisquel, and LibreCMC. However, the vast majority of open-source projects make a distinction between binary-only device drivers (blobs) and binary-only firmware (not considered blobs), 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. Projects following this policy include the Linux kernel itself, NetBSD, FreeBSD, DragonFly BSD, and most Linux distributions. Some of these projects do provide options for building the system without proprietary firmware, thus excluding sourceless microcode on demand.
The OpenBSD 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; citing not only the potential for undetectable or irreparable security flaws, but also the encroachment onto the openness and freedom of its software. The Free Software Foundation (FSF) is actively campaigning against binary blobs. 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. The Debian project included both free and non-free binary firmware from the Linux kernel, clearly marking and separating the non-free packages according to the Debian Social Contract. As of Debian 6.0 those blobs were removed.
For OpenBSD, project leader Theo 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.
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." 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." The Linux kernel maintainer Greg Kroah-Hartman has stated that it is illegal to redistribute closed source modules for the GNU General Public License-licensed Linux kernel.
However, the Linux kernel contains closed-source firmware required by various device drivers. 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."
Most of the drivers for mobile devices running the 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 patching, or a combination of these steps, all of which implies that legacy devices will never get the latest Android version.
Problems
 | This section is written like a personal reflection, personal essay, or argumentative essay that states a Misplaced Pages editor's personal feelings or presents an original argument about a topic. Please help improve it by rewriting it in an encyclopedic style. (March 2021) (Learn how and when to remove this message) |
There are a number of reasons why binary blobs can be problematic.
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 the source 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.
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.
Use via wrappers
A wrapper is software which allows one operating system to use a binary proprietary device 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.
Another example is providing compatibility layers so that foreign utilities could be used to service the hardware. Examples include some RAID controller drivers in FreeBSD, where the system administrator would have to enable 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. Circa 2005, this state of affairs prompted OpenBSD to create and popularise its bio(4), bioctl and sensor drive concepts as an alternative solution for RAID monitoring, both of which concepts have subsequently found its way into NetBSD as well.
Device firmware
Main articles: Firmware and MicrocodeFirmware is the software required by the onboard microcontrollers that accompanied by 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 to fix bugs, some devices contain only static 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 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; if free and unconditional redistribution is not permitted by the vendor, the machine instructions on fetching these images may be provided in the ports tree (which precludes some encumbered wireless devices (e.g., Intel Wireless) from being available during the initial install). 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
The BIOS, which functions as a bootloader and supports legacy real mode applications, is a crucial component of many IBM-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 as UEFI (Unified Extensible Firmware Interface). The EDK (EFI Development Kit) was developed to assist EFI firmware development projects.
Also in the late 1990s, the coreboot project was started to create an open source alternative to legacy BIOS from scratch. The coreboot developer community organises around Stefan Reinauer and is led by firmware developers with commit rights. Despite closed source binary firmware having been at the heart of the x86 architecture coreboot only incorporates the few proprietary binaries that are necessary to provide users with a base level hardware support. A completely open source alternative to BIOS and UEFI is libreboot, which was promoted by the Free Software Foundation (FSF).
See also
- Character large object
- Firmware
- Graphics hardware and FOSS
- LinuxBoot
- Loadable kernel module
- Opaque binary blob
- Proprietary firmware
- Proprietary software
- NSA ANT catalog
- ScreenOS NSA Binary blob backdoor
- Wireless security
References
- Michael Larabel (2012-08-06). "Coreboot: Replacing Intel's Binary Video BIOS Blob". Phoronix. Retrieved 2015-06-23.
- Chris Hoffmann (2015-02-13). "How Intel and PC makers prevent you from modifying your laptop's firmware". pcworld.com. Retrieved 2015-06-23.
- "BIOS Freedom Status". puri.sm. 2014-11-12. Retrieved 2015-06-23.
- Michael Larabel (2012-10-24). "Raspberry Pi GPU Driver Turns Out To Be Crap". Phoronix. Retrieved 2015-06-23.
- Jake Edge (2015-06-17). "Chromium suddenly starts downloading a binary blob". LWN.net. Retrieved 2015-06-23.
- "3.9: "Blob!"". OpenBSD Release Songs. OpenBSD. 2006-05-01.
Blobs are vendor-compiled binary drivers without any source code.
- "Debian packages built from the source package 'firmware-nonfree' - Binary firmware for various drivers in the Linux kernel". 2010. Retrieved 2010-03-25.
- Constantine A. Murenin (2006-12-10). "Почему так важно иметь документацию по программированию железа". Linux.org.ru (in Russian).
- Theo de Raadt (2016-12-03). "Page 11: The hardware: ethernet". Open Documentation for Hardware. OpenCON 2006, 2–3 December 2006. Courtyard Venice Airport, Venice/Tessera, Italy.
Only a few recalcitrant vendors remain closed. / ethernet 95% documented 99% working / Open documentation largely due to the effort of one man: Bill Paul
- "List of Free GNU/Linux Distributions". GNU Project. Free Software Foundation.
- ^ Andrews, Jeremy (2006-04-19). "Interview with Jonathan Gray and Damien Bergamini". kerneltrap.org. Archived from the original on 2007-12-11. Retrieved 2008-01-06.
- ^ Scott Long; Adaptec, Inc (2000). "aac(4) — Adaptec AdvancedRAID Controller driver". BSD Cross Reference. FreeBSD.
If the kernel is compiled with the COMPAT_LINUX option, or the aac_linux.ko and linux.ko modules are loaded...
- "aac -- Adaptec AdvancedRAID Controller driver". FreeBSD Manual Pages.
- ^ Achim Leubner (2013). "aacraid(4) — Adaptec AACRAID Controller driver". BSD Cross Reference. FreeBSD.
If the kernel is compiled with the COMPAT_LINUX option, or the aacraid_linux.ko and linux.ko modules are loaded...
- "aacraid -- Adaptec AACRAID Controller driver". FreeBSD Manual Pages.
- Matzan, Jem (15 June 2005). "BSD cognoscenti on Linux". NewsForge. Archived from the original on 23 March 2006. Retrieved 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?"
- "build/options/WITHOUT_SOURCELESS_UCODE". BSD Cross Reference. FreeBSD. 2012-02-04.
- ^ "3.8: "Hackers of the Lost RAID"". OpenBSD Release Songs. OpenBSD. 2005-11-01.
- ^ Andrews, Jeremy (2006-05-02), "Interview: Theo de Raadt", KernelTrap, Jeremy Andrews, archived from the original on 2006-06-03
- "Protest against ATI nearly led to the arrest of RMS". Free Software Foundation. 27 April 2006. Retrieved 2006-10-10.
- ^ "Explaining Why We Don't Endorse Other Systems". GNU Project. Free Software Foundation.
- "Debian firmware-linux packages". 2010. Retrieved 2010-03-25.
- "a/lt-binary". lwn.net.
- Greg Kroah-Hartman (June 2008). "A position statement on Linux Kernel Modules". The Linux Foundation.
- Greg Kroah-Hartman (2006). "Myths, Lies, and Truths about the Linux kernel". Linux Symposium.
- "Nonfree Firmware". GNU Project § Free System Distribution Guidelines (GNU FSDG). Free Software Foundation.
- "::[FSFLA]:: Take your freedom back, with Linux-2.6.33-libre". fsfla.org.
- Jonathan Gray (2006-12-02). "Page 26: Only open for business: FreeBSD". Driver Architecture and Implementation in OpenBSD. OpenCON 2006, 2–3 December 2006. Courtyard Venice Airport, Venice/Tessera, Italy. Retrieved 2019-03-27.
drivers designed for binary only Linux RAID management tools
- Theo de Raadt (2005-09-09). "RAID management support coming in OpenBSD 3.8". misc@ (Mailing list). OpenBSD.
- ^ "OpenBSD Works To Open Wireless Chipsets". KernelTrap. November 2, 2004. Archived from the original on 2006-06-20. Retrieved 2006-06-23.
- "/sys/dev/microcode/". OpenBSD.
- "sysutils/firmware". OpenBSD ports.
- ^ Vincent Zimmer; Jiming Sun; Marc Jones; Stefan Reinauer (2015). Embedded Firmware Solutions: Development Best Practices for the Internet of Things. Apress. p. 121. ISBN 9781484200704.
- Vincent Zimmer; Jiming Sun; Marc Jones; Stefan Reinauer (2015). Embedded Firmware Solutions: Development Best Practices for the Internet of Things. Apress. p. 61. ISBN 9781484200704.
- Vincent Zimmer; Jiming Sun; Marc Jones; Stefan Reinauer (2015). Embedded Firmware Solutions: Development Best Practices for the Internet of Things. Apress. p. 65. ISBN 9781484200704.
- "Campaign for Free BIOS". Free Software Foundation. 2006-11-29. Retrieved 2007-01-02.
External links
- McMillan, Robert (June 21, 2006). "Researchers hack Wi-Fi driver to breach laptop". InfoWorld. Archived from the original on July 2, 2006. Retrieved 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, archived on May 5, 2012
- A creative example of the value of free drivers, LWN.net
| Free and open-source software | |||
|---|---|---|---|
| General | |||
| Software packages | |||
| Community | |||
| Organisations | |||
| Licenses |
| ||
| Challenges | |||
| Related topics | |||
