UEFI Secure Boot Saga – Blinder Alarm im Gummiboot

30 Juni 2012 3 Kommentare Autor: Thomas (td)

Red Hat Logo 150x150Das Secure-Boot-Thema erregt nach wie vor die Gemüter und taucht im Netz irgend eine neue Information auf, kocht auch die Diskussion wieder hoch. Auf jeden Fall herrscht nach wie vor ein reges Interesse an der Frage, was die wichtigen Distributionen in dieser Angelegenheit planen. Die Standpunkte, bzw. Beschlüsse zum Thema von Fedora, bzw. Red Hat und Canonical sind inzwischen bekannt und hinreichend diskutiert, auch die Tatsache, dass Linus Torvalds die ganze Geschichte gewohnt gelassen sieht. Auch wir haben das Thema hier schöpfend behandelt. Da Red Hats Beschluss, mit einem Microsoft signierten Mini-Bootloader arbeiten zu wollen amtlich zu sein scheint, stürzte sich die Blog- und Nachrichten-Szene heute Morgen auf die von einem bekannten Online-Nachrichtenkanal verbreitete Meldung, Red Hat habe unter der Bezeichnung „Gummiboot“ bereits einer erste Version des geplanten Mini-Bootloaders fertiggestellt. Dem ist aber nicht so.

Nette Geschichte

Konkret ging es um die Meldung, die Red Hat-Entwickler Kay Sievers und Harald Hoyer hätten eine erste Version des von Red Hat geplanten Microsoft-signierten Bootloaders fertig, der Linux auf UEFI-Systemen starten können soll, wie von Matthew Garret ursprünglich vorgeschlagen. Das Gummiboot existiert auch und schaust Du Dir die Beschreibung an, ist tatsächlich nicht auf dem ersten Blick klar, dass es hier nicht um die offiziell von Red Hat abgenickte Lösung eines Microsoft-signierten Mini-Bootloaders geht. Von daher kann man auch niemanden einen Vorwurf machen, das Gummiboot mit der geplanten Red Hat-Lösung in Verbindung zu bringen. Der Bezug ist ja auch durchaus da. Worin der eigentliche Zweck des Gummiboots tatsächlich besteht wurde indes erst klar, als Harald Hoyer die auf Heise Online verbreitete Nachricht richtig stellen ließ. Toll finde ich übrigens, dass Heise Online die Korrektur mit nur 90 minütiger Verzögerung online stellte. Ich würde darauf auch gar nicht herumreiten – für „Fehler“ dieser Art kann niemand was, am allerwenigsten Heise Online, denn die Produktbeschreibung von Gummiboot ist wirklich dürftig und beim gewählten Sub-Titel drängt sich der von Heise Online hergestellt Bezug geradezu auf – aber ohne Hoyers Intervention könnte ich jetzt nicht erzählen, was der Zweck des Gummibootes ist.

Voila

Der Gummiboot-Bootloader. (Quelle: http://freedesktop.org)

Der Gummiboot-Bootloader ist laut Hoyer und Sievers lediglich eine Referenzimplementierung für ein neues Konfigurationsdatei-Layout, das dazu dienen soll, ein gemeinsames Verzeichnis für die Bootkonfigurationen aller Linux-Systeme zur Verfügung stellen zu können, damit sich mehrere parallel installierte Distributionen beim Booten nicht in die Quere kommen. Gummiboot soll  installierte Kernel automatisch finden und einen anderen Bootloader nachladen können, wobei Gummiboot gefundene Kernel, bzw. einen installierten Grub in einem einfachen Menü zur Auswahl anbietet und für die weitergehende Konfiguration einfache Textdateien benutzt. Diese müssen zusammen mit Kernel und Initrd-Dateien in der EFI System Partition liegen.

Streitbar

Ich bin gespannt wie es weitergeht mit Linux und UEFI. Hierin stimme ich übrigens mit Jürgens Meinung überein, den Ansatz von Red Hat sympathischer zu finden, als den von Canonical geplanten Alleingang. Dass Red Hat dezent darauf hingewiesen hat, man hätte auch seine Kontakte zu den Hardwareherstellen für einen Red-Hat-signierten Bootloader nutzen können, dies aber im Interesse einer gemeinschaftlichen Lösung unterlassen, kann natürlich auch anders verstanden werden. Aber Spekulieren hilft hier nicht weiter.

Im Übrigen scheint es mir, dass die verschiedenen Interessengruppen in Sachen Secure-Boot ein paar Dinge durcheinander bringen. Offenbar scheint es des Einen nur darum zu gehen, eine Lösung für die Installierbarkeit von Linux auf UEFI-Boards zu finden, während Andere der Idee von Microsoft durchaus einen Sinn abringen, denn es geht ja nicht darum, dass Entwickler Secure Boot abschalten  können, sondern um eine sichere Bootkette nebst Gewährleistung der Integrität von Kernel und Modulen. Hier besteht offenbar auch ein deutlicher Unterschied im Pragmatismus, wie in Ubuntu versteht und der relativ gelassenen Haltung von Linus. Der hat ja auch nur gesagt, dass Secure Boot nicht den Weltuntergang darstellt und er Garrets Ansatz nachvollziehbar findet. Und dann wäre dann noch eine dritte Gruppe, die alles „böse“ findet, was Microsoft tut. Doch mal im Ernst. Es geht um rund 100 Dollar pro Hersteller, pro Bootloader, die noch nicht einmal an Microsoft, sondern an VeriSign gehen.



Du kannst gerne Deinen Senf zu diesem Beitrag geben: Hier geht es zu den Kommentaren


Schreiben macht durstig! Eine kleine Erfrischung kann daher nie schaden. Wem dieser freie Artikel gefallen hat, der darf mir gerne einen frisch gezapften Hopfen-Tee ausgeben (Paypal - der Spenden-Knopf
oder bitcoin - Adresse: 1NacVNwcLLePUVv8uSafu5Ykdwh8QyDfgK). Ich freue mich über jede noch so kleine Spende. Vielen Dank und Prost!
 Alle Kommentare als Feed abonnieren

3 Kommentare zu “UEFI Secure Boot Saga – Blinder Alarm im Gummiboot”

  1. Setsuna sagt:

    Doch mal im Ernst.

    Es geht hier nicht darum, dass viele ein Problem mit Microsofts "Böse"-Image haben (das ihnen nebenbei niemand verliehen hat, das haben sie sich selbst erarbeitet). Auch ob das Geld nun an MS oder an VeriSign geht ist zweitrangig.

    Das Problem sind auch nicht x86er-Maschinen, auf denen SecureBoot zwar im eingeschaltenen Zustand ausgeliefert, aber abschaltbar sein soll. Das eigentliche Problem, und dafür hat sich MS nach Leibeskräften eingesetzt, ist die Tatsache, dass per Design auf ARM-basierten Devices (Handhelds, Tablets) SecureBoot gar nicht abschaltbar sein darf, sollte sich der Hersteller um eine Win8-Zertifizierung bemühen. MS versucht hier, als Spätkommender, in einen bestehenden Markt einzusteigen und durch diese Maßnahme ein neues Monopol zu erzeugen, da auf diesen Geräten niemals etwas anderes als das vorinstallierte Win8 laufen darf. Denn wie bekommst du ein alternatives System auf eine Hardware die nur den MS-Schlüssel (der ja, Win8-zertifiziert, vorhanden ist) akzeptiert?

    Mit genau dieser Frage beschäftigen sich zur Zeit die Distributionen und versuchen Workarounds zu finden doch einen Weg zu finden um ihre Systeme auf diesen Geräten starten zu können.

    Jedoch selbst wenn es den Distris gelingt (, dass Canonical und RedHat nichts anderes einfällt als ebenfalls einen MS-Schlüssel zu kaufen beweist wie gut MS die Geschichte eingefädelt hat), was ist mit selbstgebackenen Kerneln? Was ist mit Nutzern die z.B. ein Gentoo einsetzen wollen? Die stehen weiterhin vor dem Problem, dass sie das nicht können/dürfen.

    Der Wechsel zu einem anderen als dem vorinstallierten System soll so unattraktiv gemacht werden, dass eben jenes System auf dem Gerät verbleibt: Win8.

    Unabhängig von meiner Meinung zu MS oder einer technisch neutralen Sicht auf die Umsetzung von Win8 hoffe ich, dass diese Geräte in den Geschäftsregalen verbleiben.

    • Gerald sagt:

      Genau darum geht's. UEFI Secure Boot ist nur bei geschlossenen Betriebssystemen überhaupt möglich bzw. bei solchen, an denen der Benutzer nichts verändern kann.

      Secure Boot basiert nämlich darauf, dass die gesamte Kette sicher ist, und bei Linux hört sich das schon per Philosophie sofort nach dem Bootloader auf. Denn wie sollte man denn sonst seine Freiheit, den Kernel neu compilieren zu dürfen, nützen? In dem Moment, in dem ich das mache, ist der Kernel nicht mehr "secure" und Secureboot für die Katz'.

      Natürlich kann ich jetzt sagen: "OK., ich weiß ja, was ich mit meinem Kernel und Betriebssystem tue. Wichtig ist mir, dass mir keiner ins BIOS reinpfuschen kann." Jedoch ist alleine die Tatsache, dass Linux nun mal offen ist, ein juristischer Grund für Microsoft, den Bootloader NICHT zu signieren, da die Secureboot-Kette nicht gewährleistet werden kann.

      Für Red Hat bedeutet das nicht Anderes, als dass sie für die Zertifizierung verhindern müssten, dass der Benutzer am Kernel und am GNU-System überhaupt etwas verändern kann. Das widerspricht aber klar der GPL.

      • jdo sagt:

        Ich glaube es geht Red Hat in erster Linie um folgende Schadensbegrenzung: Linux-Neulingen den Einstieg so einfach wie möglich zu machen. Die Profis werden sowieso erst mal ins BIOS gehen und den Blödsinn deaktivieren - was die Hardware-Hersteller so hoffentlich auch alle einbauen ...

Antworten