Binärblob

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

Ein Binärblob ist – im Kontext von freier Software – ein Binary Large Object (BLOB), das proprietäre Software als Binärcode (Maschinencode) enthält.

Begriffsklärung[Bearbeiten | Quelltext bearbeiten]

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.[1][2][3][4][5] Der Begriff Blob wurde erstmals in Verbindung mit Datenbankmanagmentsystemen genannt, er wird dort verwendet, um eine Kollektion von Binärdaten, die in einer einzigen Entität gespeichert sind, zu bezeichnen. Blob 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 (Binärblobs) verfügbar. Diese Praxis ist weit verbreitet für Treiber für beschleunigte Grafik, Netzwerkgeräte und Hardware-RAID-Controller.[6]

Abgrenzung zu Gerätefirmware[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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.[7]

Das OpenBSD-Projekt hat zu diesem Thema einen nennenswerten Grundsatz, das Projekt akzeptiert keine Binärblobs in ihrem „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 die Beeinträchtigung für die Offenheit und die Freiheit ihrer Software genannt.[8]

Die Free Software Foundation (kurz FSF) setzt sich aktiv gegen Binärblobs ein.[9] Sie betrachten den OpenBSD Grundsatz als verwirrend formuliert, da „Blobs“ in der BSD-Gemeinschaft unfreie Treiber bezeichnet und nicht unfreie Firmware.[10] Das Debian-Projekt inkludiert beides, sowohl freie als auch nicht freie Binärfirmware vom Linux-Kernel, aber diese klar gekennzeichnet und separiert von nicht freien Softwarepaketen, gemäß deren Gesellschaftsvertrag.[11] Ab Debian 6.0 wurden diese Blobs entfernt.[12]

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.

Theo de Raadt

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.[13] 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, dass meine Hände in Bezug auf Binärmodule gebunden sind. Ich will die Leute wissen lassen, wenn diese Binärmodule verwenden, dann ist das DEREN Problem.

Linus Torvalds[14]

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, betrachen 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.

Position Statement on Linux Kernel Modules[15]

Der Linuxkernel beinhaltet allerdings eine Vielzahl an Binärblobs, die primär quellgeschlossene Firmware beinhalten, die für unterschiedliche Gerätetreiber benötigt werden.[16][17] Alexandre Oliva, der Maintainer von Linux-libre – einer Version des Linuxkernels ohne Binärblobs – schrieb im Jahre 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 diesen Zeitpunkt Herr Torvalds die ersten Teile nicht-freier Software in den Distributionen von Linux, die er seit 1991 publiziert, akzeptierte. Über die Jahre, während der Kernel um einen Faktor von 14 gewachsen ist, wuchs die Menge an unfreier Firmware bei den Linuxtreibern um den alarmierenden Faktor 83. Wir, die Nutzer von freier Software, müssen uns vereinen und diesen Trend umkehren. Ein Teil der Lösung dazu ist Linux-libre, das gerade die Version 2.6.33-libre erreicht hat und von der FSFLA veröffentlicht wurde, diese Version hat Freiheit, große Verbesserungen und Pläne für die Zukunft im Gepäck.

Alexandre Oliva[18]

Rechtmäßigkeit[Bearbeiten | Quelltext bearbeiten]

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.[19]

Probleme[Bearbeiten | Quelltext bearbeiten]

Es gibt einige Gründe, warum Binärblobs problematisch sein können:[20]

  • 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 die Firma 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 als erstrebenswert für die technischen Gründe findet, aber das Fehlen einer starken Opposition zu 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[Bearbeiten | Quelltext bearbeiten]

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 Microsoft Windows geschrieben wurden, zu verwenden indem sie die Microsofts NDIS API implementieren.

BIOS[Bearbeiten | Quelltext bearbeiten]

Das BIOS funktioniert als ein Bootloader und unterstützt Legacy-Real-Mode-Applikationen, was es zu einer wichtigen Komponente für jeden IBM-kompatiblen Computer macht. Das BIOS ist immer in 16-Bit, meist verfügt es auch über Netzwerkfunktionen und kann daher auch eine Sicherheitsbackdoor darstellen (manchmal mit Absicht;[21][22] das Problem hierbei ist, dass das Betriebssystem keine Kontrolle über diese Hintertür hat und auch nichts von dieser weiß).[23] Darum fördert die FSF das Projekt Libreboot in ihrer Kampagne für eine freie BIOS-Firmware.[24]

Siehe auch[Bearbeiten | Quelltext bearbeiten]

 Portal: Freie Software – Übersicht zu Wikipedia-Inhalten zum Thema Freie Software

Weblinks[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  1. Michael Larabel: Coreboot: Replacing Intel's Binary Video BIOS Blob. Phoronix. 6. August 2012. Abgerufen am 23. Juni 2015.
  2. Chris Hoffmann: How Intel and PC makers prevent you from modifying your laptop's firmware. 13. Februar 2015. Abgerufen am 23. Juni 2015.
  3. BIOS Freedom Status. 12. November 2014. Abgerufen am 23. Juni 2015.
  4. Michael Larabel: Raspberry Pi GPU Driver Turns Out To Be Crap. Phoronix. 24. Oktober 2012. Abgerufen am 23. Juni 2015.
  5. Jake Edge: Chromium suddenly starts downloading a binary blob. LWN.net. 17. Juni 2015. Abgerufen am 23. Juni 2015.
  6. Debian packages built from the source package 'firmware-nonfree' – Binary firmware for various drivers in the Linux kernel. 2010. Abgerufen am 25. März 2010.
  7. Jem Matzan: BSD cognoscenti on Linux. NewsForge. 15. Juni 2005. Abgerufen am 7. Juli 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?"
  8. Jeremy Andrews: Interview: Theo de Raadt. In: KernelTrap. Jeremy Andrews. 2. Mai 2006.
  9. Protest against ATI nearly led to the arrest of RMS. Free Software Foundation. 27. April 2006. Abgerufen am 10. Oktober 2006.
  10. Explaining Why We Don't Endorse Other Systems. GNU Project. 13. Juli 2011. Abgerufen am 10. September 2011.
  11. Debian firmware-linux packages. 2010. Abgerufen am 25. März 2010.
  12. Explaining Why We Don't Endorse Other Systems # Debian. 2013. Abgerufen am 29. März 2013.
  13. Jeremy Andrews: Interview: Theo de Raadt. In: KernelTrap. Jeremy Andrews. 2. Mai 2006.
  14. a/lt-binary. In: lwn.net.
  15. Greg Kroah-Hartman: A position statement on Linux Kernel Modules. The Linux Foundation. Juni 2008.
  16. Free System Distribution Guidelines (GNU FSDG) – GNU Project – Free Software Foundation. In: gnu.org.
  17. Explaining Why We Don't Endorse Other Systems – GNU Project – Free Software Foundation. In: gnu.org.
  18. ::[FSFLA:: Take your freedom back, with Linux-2.6.33-libre]. In: fsfla.org.
  19. Greg Kroah-Hartman: Myths, Lies, and Truths about the Linux kernel. Linux Symposium. 2006.: „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.“
  20. Jeremy Andrews: Interview with Jonathan Gray and Damien Bergamini. kerneltrap.org. 19. April 2006. Abgerufen am 6. Januar 2008.
  21. Intel vPro Technology. Intel.com. 14. Mai 2012. Abgerufen am 10. April 2014.
  22. BIOS & Firmware Compatibility. Absolute.com. Abgerufen am 10. April 2014.
  23. as per IBM PC specs
  24. Campaign for Free BIOS. Free Software Foundation. 29. November 2006. Abgerufen am 2. Januar 2007.