# Binärblob

Ein Binärblob ist – im Kontext von freier Software – proprietäre Software, die nur in Form von Maschinencode verfügbar ist. Der Begriff bezieht sich meist auf ein Gerätetreiber-Modul, das in den Kernel eines Open-Source-Betriebssystems geladen wird.

## Begriffsklärung

Der Begriff bezieht sich meist auf quellgeschlossene Kernel-Module, die in den Kernel eines quelloffenen Betriebssystems geladen werden. Er wird aber auch verwendet, um Dinge außerhalb des Kernels zu bezeichnen, wie z. B. Firmware-Abbilder, Microcode-Aktualisierungen oder Programme, die im Userspace ausgeführt werden. Der Begriff Blob wurde erstmals im Kontext von Datenbankmanagementsystemen für große binäre Datenobjekte benutzt und steht in dem Fall für Binary Large Object.
Wenn Hardware-Hersteller ihre vollständige technische Dokumentation über ihre Produkte anbieten, sind Betriebssystementwickler in der Lage, Gerätetreiber zu schreiben, die in den Kernel des Betriebssystems eingefügt werden können. Einige Hersteller, wie z. B. Nvidia, bieten keine vollständige Dokumentation für ihre Produkte an, stattdessen sind ausschließlich binäre Treiber verfügbar. Diese Praxis ist weit verbreitet für Treiber für beschleunigte Grafik, Netzwerkgeräte und Hardware-RAID-Controller.

## Abgrenzung zu Gerätefirmware

Firmware ist die Software, die für die Onboard-Mikrocontroller zuständig ist. Firmware wird generell nicht als Binärblob angesehen. In vielen Geräten ist die Firmware in einem nichtflüchtigen Datenspeicher gespeichert, um Kosten zu verringern und Upgrades zu erleichtern. Einige Geräte beinhalten nur statischen RAM und daher muss das Betriebssystem die Firmware immer neu laden, wenn diese verbunden werden (speziell bei USB-Geräten). Obwohl die Firmware derart im Betriebssystemtreiber präsent ist, wird diese lediglich zum Gerät kopiert und nicht von der CPU ausgeführt. Damit werden Bedenken in Bezug auf Sicherheitsrisiken erheblich geschwächt.

## Akzeptanz

Einige Projekte versuchen, freie Betriebssysteme zu entwickeln und akzeptieren daher keine Binärblobs, wenn diese nicht die Dokumentation über die Hardware oder den Quelltext des Gerätetreibers mitliefern. Beispiele für solche Projekte sind Trisquel, Parabola und LibreCMC. Andere Projekte unterscheiden zwischen ausschließlicher Binärsoftware und ausschließlicher Binärfirmware und verteilen daher auch Binärblobs. Projektbeispiele hierfür wären NetBSD, FreeBSD, DragonFly BSD und einige Linux-Distributionen.
Das OpenBSD-Projekt hat zu diesem Thema einen nennenswerten Grundsatz: Das Projekt akzeptiert keine Binärblobs in seinem „Source Tree“ (allerdings sind Firmwareblobs für OpenBSD gesondert verfügbar). Es werden nicht nur das Potential für unentdeckte oder irreparable Sicherheitsfehler, sondern auch Beeinträchtigung für die Offenheit und die Freiheit seiner Software genannt.
Die Free Software Foundation (kurz FSF) setzt sich aktiv gegen Binärblobs ein. Sie betrachtet den OpenBSD-Grundsatz als verwirrend formuliert, da „Blobs“ in der BSD-Gemeinschaft unfreie Treiber bezeichnet und nicht unfreie Firmware. Das Debian-Projekt inkludierte gemäß seinem Gesellschaftsvertrag sowohl freie als auch unfreie Binärfirmware, jedoch jeweils klar gekennzeichnet und separiert von den jeweils anderen Softwarepaketen. Ab Debian 6.0 wurden diese Blobs aus den „main“-Softwarequellen entfernt und in die „non-free“-Softwarequellen verschoben und eine strikte Trennung von freier und nicht-freier Firmware auch im Linux-Kernel selbst vollzogen.
Theo de Raadt, der Projektleiter von OpenBSD, verteidigt den OpenBSD-Grundsatz, nur nach Vertriebsrechten für diese Mikrocodefirmwareblobs zu fragen.
   “Once they are distributed… at least the device works.”
   „Sobald diese verteilt wurden…funktionieren die Geräte zumindest.“
Damit impliziert er, dass die Alternative für die Mitglieder seines Projektes sei, selbst freie Firmware in Assemblersprache für viele Chipsätze zu schreiben. Dazu macht er geltend: „don't load us up with more tasks.“ z.Dt. „beladet uns nicht mit noch mehr Aufgaben.“. Ungeachtet davon favorisiert er Chipsätze, die ohne Firmware funktionieren und spricht von „asiatischem Design“, das er als schwerer zu vermarkten, aber ausreichend beschreibt.
In der Entwicklungsgemeinschaft des Linuxkernels hat Linus Torvalds Argumente zum Problem von Binärmodulen geäußert. Er macht geltend:
   “I refuse to even consider tying my hands over some binary-only module. I want people to know that when they use binary-only modules, it's THEIR problem.”
   „Ich weigere mich auch nur daran zu denken, in Bezug auf Binärmodule meine Hände zu binden. Ich will die Leute wissen lassen: wenn sie Binärmodule verwenden, dann ist das DEREN Problem.“
Im Jahr 2008 haben 176 Kernelentwickler ein Positionspapier zu Linuxkernelmodulen unterzeichnet, das angibt:
   “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.”
   „Wir, die unterzeichnenden Linuxkernelentwickler, betrachten jegliches quellgeschlossene Linuxkernelmodul oder Treiber als gefährlich und unerwünscht… Wir haben diese mehrfach als schädlich für Linuxnutzer, Firmen und größere Linuxökosysteme befunden.“
Der Linuxkernel beinhaltet allerdings eine Vielzahl an Binärblobs, die primär quellgeschlossene Firmware beinhalten, die für unterschiedliche Gerätetreiber benötigt werden. Alexandre Oliva, der Maintainer von Linux-libre – einer Version des Linuxkernels ohne Binärblobs – schrieb im Jahr 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. We, Free Software users, need to join forces to reverse this trend, and part of the solution is Linux-libre, whose release 2.6.33-libre was recently published by FSFLA, bringing with it freedom, major improvements and plans for the future.”
   „Linux ist seit 1996 keine freie Software mehr, da zu diesem Zeitpunkt Herr Torvalds die ersten nicht-freien Softwareteile in den Distributionen von Linux, die er seit 1991 publiziert, akzeptierte. Über die Jahre ist der Kernel um einen Faktor von 14 gewachsen, die Menge an unfreier Firmware, die für Linuxtreiber benötigt wird, jedoch um den alarmierenden Faktor 83. Wir, die Nutzer von freier Software, müssen uns vereinen und diesen Trend umkehren. Ein Teil der Lösung ist Linux-libre, dessen Version 2.6.33-libre gerade von der FSFLA veröffentlicht wurde und Freiheit, große Verbesserungen und Pläne für die Zukunft mit sich bringt.“

## Rechtmäßigkeit

Der prominente Linuxkernelentwickler Greg Kroah-Hartman stellte fest, dass es illegal sei, quellgeschlossene Module für den unter der GPL lizenzierten Linux-Kernel zu verteilen.

## Probleme

Es gibt einige Gründe, warum Binärblobs problematisch sein können:
* Ihre Funktionsweise ist unbekannt und Programmfehler können nicht mit Quellcodeprüfung entdeckt werden. Es werden dennoch häufig Fehler diagnostiziert, wenn ein System anfängt, sich unvorhersehbar zu verhalten. Solche unentdeckten Programmierfehler exponieren Nutzer und Systeme in Bezug auf Sicherheitslücken. Die Zweckmäßigkeit von Treibern kann nicht überprüft werden und wenn Programmfehler auftauchen, gibt es keinen Weg, diese zu beheben.
* Da der Quelltext nicht offen verfügbar ist, können Treiber von ihren Nutzern nicht verbessert oder auch nicht auf andere Architekturen portiert bzw. für leicht abgewandelte Varianten der Hardware adaptiert werden.
* Nutzer sind gezwungen, dem Hersteller des Blobs blind darauf zu vertrauen, dass dieser keine Hintertüren und Ausspähsoftware in den Blob integriert hat. Außerdem können Hersteller sich dazu entscheiden, bestimmte Betriebssysteme nicht zu unterstützen oder die Unterstützung für Treiber nach einiger Zeit einzustellen. Zudem könnte das Unternehmen insolvent werden und somit den Treiber nicht mehr weiterentwickeln.
* Binärblobs treiben einen Keil zwischen den Teil der Gemeinschaft, der an die Ideale freier Software glaubt und daher proprietäre Software zurückweist und den Teil, der Open Source aus technischen Gründen erstrebenswert findet, aber Binärblobs akzeptiert, „solange diese funktionieren“. Diese Fragmentierung und die Akzeptanz für die wachsende Zahl von proprietären Komponenten in Linux schwächen die Fähigkeit der Gemeinschaft, sich gegen den Trend der Hersteller, keine Dokumentation für deren Hardware anzubieten, zu wehren. Es könnte in der Zukunft dazu kommen, dass es unmöglich sein wird, ein vollständig freies Betriebssystem auf einem Großteil der verfügbaren Hardware ausführen zu können.

## Nutzung über Wrapper

Ein Wrapper ist eine Software, die es einem Betriebssystem erlaubt, Binärblob-Treiber, die für ein anderes Betriebssystem geschrieben wurden, zu verwenden. Beispiele für Wrapper sind NDISwrapper für Linux sowie Project Evil für FreeBSD und NetBSD. Diese Wrapper erlauben es den Systemen, die Netzwerktreiber, die für Windows geschrieben wurden, zu verwenden, indem sie die Microsofts NDIS API implementieren.

## Systemfirmware

Beim IBM PC und dazu kompatiblen Computern fungiert das proprietäre BIOS als Bootloader, unterstützt dabei allerdings nur den 16-Bit-Real Mode. Moderne Betriebssysteme setzen jedoch mindestens auf den 32-Bit-Protected Mode der 32-Bit-x86-Architektur „IA-32“ (bzw. „i386“) auf, 64-Bit-Betriebssysteme auf den Long Mode von x86-64. Doch vor allem wegen der Kompatibilität mit DOS und Windows 9x zählte das PC-BIOS bis in die 2000er Jahre zu einer der wichtigsten Komponenten für IBM-kompatible Computer. Es war bis zuletzt in 16-Bit ausgelegt, verfügt meist auch über Netzwerkfunktionen und kann daher auch eine Sicherheitsbackdoor darstellen (manchmal mit Absicht; das Problem hierbei ist, dass das Betriebssystem keine Kontrolle über diese Hintertür hat und auch nichts von dieser weiß).
Das PC-BIOS wurde ab ca. 2010 schrittweise vom Unified Extensible Firmware Interface, kurz EFI oder UEFI, abgelöst, und ist seit ca. 2020 nicht mehr in (ehemals IBM-kompatiblen) PCs zu finden. UEFI teilt jedoch die beschriebenen Probleme des BIOS.
Die FSF fördert daher das Projekt Libreboot in ihrer Kampagne für eine freie Systemfirmware.