A proprietary device driver is a closed-source device driver published only in binary code. In the context of free and open-source software, a closed-source device driver is referred to as a blob or binary blob. The term usually refers to a closed-source kernel 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. [1] [2] [3] [4] [5] [6] 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. [7] Most notably, binary blobs 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. [8] [9]
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. [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 the Linux kernel itself, NetBSD, FreeBSD, DragonFly BSD, and most Linux distributions. [14] Some of these projects do provide options for building the system without proprietary firmware, thus excluding sourceless microcode on demand. [15]
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; [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] The Free 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 The Debian project included both free and non-free binary firmware from the Linux kernel, clearly marking and separating the non-free packages [20] according to the Debian Social Contract. As of Debian 6.0 those blobs were removed. [19] : Debian
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. [17]
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." [21] 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." [22] 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. [23]
However, the Linux kernel contains closed-source firmware required by various device drivers. [24] [19] 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." [25]
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.[ citation needed ]
This section is written like a personal reflection, personal essay, or argumentative essay that states a Wikipedia editor's personal feelings or presents an original argument about a topic.(March 2021) |
There are a number of reasons why 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 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.
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. [12] [13] [26] 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, [27] [16] both of which concepts have subsequently found its way into NetBSD as well.
Firmware is the software required by the onboard microcontrollers that accompany some hardware, is generally not considered to be a binary blob. [28] [19] : BSD [11] : ... 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, 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; [28] [29] 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). [30]
The BIOS, which functions as a bootloader and supports legacy real mode applications, is a crucial component of many IBM-compatible computers. The BIOS can be a security backdoor. [31] [32] [ failed verification ] 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. [33]
Also in the late 1990s, the coreboot project was started to create an open source alternative to legacy BIOS from scratch. [33] The coreboot developer community organises around Stefan Reinauer and is led by firmware developers with commit rights. [34] 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. [35] A completely open source alternative to BIOS and UEFI is libreboot, which was promoted by the Free Software Foundation (FSF). [36]
Free software is computer software distributed under terms that allow users to run the software for any purpose as well as to study, change, and distribute it and any adapted versions. Free software is a matter of liberty, not price; all users are legally free to do what they want with their copies of a free software regardless of how much is paid to obtain the program. Computer programs are deemed "free" if they give end-users ultimate control over the software and, subsequently, over their devices.
In computing, firmware is a specific class of computer software that provides the low-level control for a device's specific hardware. Firmware, such as the BIOS of a personal computer, may contain basic functions of a device, and may provide hardware abstraction services to higher-level software such as operating systems. For less complex devices, firmware may act as the device's complete operating system, performing all control, monitoring and data manipulation functions. Typical examples of devices containing firmware are embedded systems, home and personal-use appliances, computers, and computer peripherals.
Theo de Raadt is a South African-born software engineer who lives in Calgary, Alberta, Canada. He is the founder and leader of the OpenBSD and OpenSSH projects and was also a founding member of NetBSD. In 2004, De Raadt won the Free Software Award for his work on OpenBSD and OpenSSH.
A disk array controller is a device that manages the physical disk drives and presents them to the computer as logical units. It almost always implements hardware RAID, thus it is sometimes referred to as RAID controller. It also often provides additional disk cache.
The Unified Extensible Firmware Interface (UEFI) is a publicly available specification that defines a software interface between an operating system and platform firmware. UEFI replaces the legacy Basic Input/Output System (BIOS) firmware interface originally present in all IBM PC-compatible personal computers, with most UEFI firmware implementations providing support for legacy BIOS services. UEFI can support remote diagnostics and repair of computers, even with no operating system installed.
The software project coreboot, formerly known as LinuxBIOS, is aimed at replacing proprietary firmware found in most computers with a lightweight firmware designed to perform only the minimum number of tasks necessary to load and run a modern 32-bit or 64-bit operating system.
A free and open-source graphics device driver is a software stack which controls computer-graphics hardware and supports graphics-rendering application programming interfaces (APIs) and is released under a free and open-source software license. Graphics device drivers are written for specific hardware to work within a specific operating system kernel and to support a range of APIs used by applications to access the graphics hardware. They may also control output to the display if the display driver is part of the graphics hardware. Most free and open-source graphics device drivers are developed by the Mesa project. The driver is made up of a compiler, a rendering API, and software which manages access to the graphics hardware.
In a computer, the Advanced Configuration and Power Interface (ACPI) provides an open standard that operating systems can use to discover and configure computer hardware components, to perform power management, to perform auto configuration, and to perform status monitoring. First released in December 1996, ACPI aims to replace Advanced Power Management (APM), the MultiProcessor Specification, and the Plug and Play BIOS (PnP) Specification. ACPI brings power management under the control of the operating system, as opposed to the previous BIOS-centric system that relied on platform-specific firmware to determine power management and configuration policies. The specification is central to the Operating System-directed configuration and Power Management (OSPM) system. ACPI defines hardware abstraction interfaces between the devices firmware, the computer hardware components, and the operating systems.
Wireless network cards for computers require control software to make them function. This is a list of the status of some open-source drivers for 802.11 wireless network cards.
These tables compare free software / open-source operating systems. Where not all of the versions support a feature, the first version which supports it is listed.
Linux is a family of open-source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991, by Linus Torvalds. Linux is typically packaged in a Linux distribution.
Kernel-based Virtual Machine (KVM) is a virtualization module in the Linux kernel that allows the kernel to function as a hypervisor. It was merged into the mainline Linux kernel in version 2.6.20, which was released on February 5, 2007. KVM requires a processor with hardware virtualization extensions, such as Intel VT or AMD-V. KVM has also been ported to other operating systems such as FreeBSD and illumos in the form of loadable kernel modules.
License compatibility is a legal framework that allows for pieces of software with different software licenses to be distributed together. The need for such a framework arises because the different licenses can contain contradictory requirements, rendering it impossible to legally combine source code from separately-licensed software in order to create and publish a new program. Proprietary licenses are generally program-specific and incompatible; authors must negotiate to combine code. Copyleft licenses are deliberately incompatible with proprietary licenses, in order to prevent copyleft software from being re-licensed under a proprietary license, turning it into proprietary software. Many copyleft licenses explicitly allow relicensing under some other copyleft licenses. Permissive licenses are compatible with everything, including proprietary licenses; there is thus no guarantee that all derived works will remain under a permissive license.
The following outline is provided as an overview of and topical guide to free software and the free software movement:
Proprietary firmware is any firmware on which is not free (libre). Examples of proprietary works include ones upon which the author has placed restrictions on use, private modification, copying, or republishing.
OpenBSD is a security-focused, free and open-source, Unix-like operating system based on the Berkeley Software Distribution (BSD). Theo de Raadt created OpenBSD in 1995 by forking NetBSD. According to the website, the OpenBSD project emphasizes "portability, standardization, correctness, proactive security and integrated cryptography."
Linux-libre is a modified version of the Linux kernel that contains no binary blobs, obfuscated code, or code released under proprietary licenses. In the Linux kernel, they are mostly used for proprietary firmware images. While generally redistributable, binary blobs do not give the user the freedom to audit, modify, or, consequently, redistribute their modified versions. The GNU Project keeps Linux-libre in synchronization with the mainline Linux kernel.
SeaBIOS is an open-source implementation of an x86 BIOS, serving as a freely available firmware for x86 systems. Aiming for compatibility, it supports standard BIOS features and calling interfaces that are implemented by a typical proprietary x86 BIOS. SeaBIOS can either run on bare hardware as a coreboot payload, or can be used directly in emulators such as QEMU and Bochs.
The bio(4) pseudo-device driver and the bioctl(8) utility implement a generic RAID volume management interface in OpenBSD and NetBSD. The idea behind this software is similar to ifconfig, where a single utility from the operating system can be used to control any RAID controller using a generic interface, instead of having to rely on many proprietary and custom RAID management utilities specific for each given hardware RAID manufacturer. Features include monitoring of the health status of the arrays, controlling identification through blinking the LEDs and managing of sound alarms, and specifying hot spare disks. Additionally, the softraid
configuration in OpenBSD is delegated to bioctl as well; whereas the initial creation of volumes and configuration of hardware RAID is left to card BIOS as non-essential after the operating system has already been booted. Interfacing between the kernel and userland is performed through the ioctl
system call through the /dev/bio
pseudo-device.
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
Look up blob in Wiktionary, the free dictionary. |