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. Dort Christos Zoulas' Antwort auf "Is sharing between Free/Open/NetBSD and the Linux kernel a common occurrence? And if so, does it go both ways?"

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.

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:

Im Jahr 2008 haben 176 Kernelentwickler ein Positionspapier zu Linuxkernelmodulen unterzeichnet, das angibt:

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:

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-. Moderne Betriebssysteme setzen jedoch mindestens auf den 32-Bit- der 32-Bit-x86-Architektur „IA-32“ (bzw. „i386“) auf, 64-Bit-Betriebssysteme auf den 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ß).as per IBM PC specs

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.

Siehe auch

Weblinks

KernelTrap-Artikel über Damien Bergamini’s wpi(4) Driver, einem blobfreien ipw3945 Alternative für OpenBSD KernelTrap-Interview mit Jonathan Gray und Damien Bergamini zum Thema Binärblobs Das Black-Hat-Wireless-Exploit-Interview, Verbatim von Brian Krebs auf der Washington Post Website: http://washingtonpost.com/

Einzelnachweise

Kategorie:FLOSS-Kultur Kategorie:Schimpfwort