Binärblob

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

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

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

Die Free Software Foundation (kurz FSF) setzt sich aktiv gegen Binärblobs ein.[9] Sie betrachtet den OpenBSD-Grundsatz als verwirrend formuliert, da „Blobs“ in der BSD-Gemeinschaft unfreie Treiber bezeichnet und nicht unfreie Firmware.[10] 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.[11] Ab Debian 6.0 wurden diese Blobs aus den „main“-Softwarequellen entfernt und in die „non-free“-Softwarequellen verschoben[12] und eine strikte Trennung von freier und nicht-freier Firmware auch im Linux-Kernel selbst vollzogen.[13]

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

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.“

– 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, 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.“

– 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 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.“

– 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 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

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

Systemfirmware

[Bearbeiten | Quelltext bearbeiten]

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;[21][22] das Problem hierbei ist, dass das Betriebssystem keine Kontrolle über diese Hintertür hat und auch nichts von dieser weiß).[23]

Das PC-BIOS wurde ab ca. 2010 schrittweise vom Unified Extensible Firmware Interface, kurz EFI oder UEFI, abgelöst,[24] und ist seit ca. 2020 nicht mehr in (ehemals IBM-kompatiblen) PCs zu finden. UEFI teilt jedoch die beschriebenen Probleme des BIOS.[25]

Die FSF fördert daher das Projekt Libreboot in ihrer Kampagne für eine freie Systemfirmware.[26]

Siehe auch

[Bearbeiten | Quelltext bearbeiten]
Portal: Freie Software – Übersicht zu Wikipedia-Inhalten zum Thema Freie Software
[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. In: pcworld.com. 13. Februar 2015, abgerufen am 23. Juni 2015.
  3. ↑ BIOS Freedom Status. In: puri.sm. 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, archiviert vom Original am 23. März 2006; abgerufen am 26. Mai 2022. 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?"
  8. ↑ a b Jeremy Andrews: Interview: Theo de Raadt. In: kerneltrap.org. 2. Mai 2006, archiviert vom Original am 3. Juni 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. ↑ KernelFirmwareLicensing – Status of firmware distributed with the Linux kernel source. In: Debian Wiki. 25. November 2019, archiviert vom Original am 14. März 2021; (englisch).
  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: Jonathan Gray and Damien Bergamini. In: kerneltrap.org. 19. April 2006, archiviert vom Original am 9. Juli 2012; abgerufen am 26. Mai 2022.
  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. ↑ Marco Wehrens, Steffen Münch: UEFI: Was ist das? UEFI-Modus erklärt – der BIOS-Nachfolger. In: Computer Bild. 19. Oktober 2023, abgerufen am 30. November 2023.
  25. ↑ Valentin Sattler: Asus-Mainboards: Update-Software im UEFI bringt Komfort und Sicherheitsbedenken. In: PCGH. 27. Oktober 2018, abgerufen am 30. November 2023.
  26. ↑ Campaign for Free BIOS. Free Software Foundation, 29. November 2006, abgerufen am 2. Januar 2007.
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Binärblob&oldid=243680787“