UEFI Secure Boot mit Fedora 18: Wir nehmen einfach einen Microsoft-Schlüssel!

“Hm? Was? Wie bitte?” – also das waren meine ersten Gedanken und neugierig begann ich den Blog-Eintrag von Red Hats Matthew Garrett zu lesen, wie er das denn nun meint.

Zur Erinnerung: Windows 8 darf nur auf OEM-Rechner, wenn UEFI Secure Boot aktiviert ist. Zwar können Hardware-Hersteller einen Schalter zum Deaktivieren im BIOS bereitstellen, aber die Linux-Distributoren wollen es dem Anwender so einfach wie möglich machen. Den Nutzer erst auf Ostereier-Suche zu schicken, ist schließlich kaum im Sinne des Erfinders. Somit haben sich die schlauen Köpfe von Fedora eine Lösung ausgedacht. Garrett gibt zu, dass er mit diesem “Workaround” zwar nicht ganz glücklich ist und es auch nicht die ideale Lösung sei, aber im Moment gibt es keine Alternative, die einen besseren Kompromiss bietet. So, nun mal an das Eingemachte.

Fedora 18 wird ungefähr zum Zeitpunkt des Windows-8-Debüts erscheinen und die meiste Hardware, die man dann Ende des Jahres kaufen kann, wird für Windows 8 zertifiziert sein. Wie wir bereits wissen, ist dann UEFI Secure Boot per Standard aktiviert. Der Satz ausgelieferter Schlüssel wird nicht fest sein und höchstwahrscheinlich zwischen den verschiedenen Hardware-Herstellern variieren. Eines ist sicher: Alles mit einem Windows-Logo wird einen Microsoft-Schlüssel enthalten.

Nun haben sich die Fedora-Entwickler schlau gemacht, ob man zusammen mit den Hardware-Herstellern einen speziellen Schlüssel für das Linux-Betriebssystem erstellen kann. Die Antworten waren laut Garrett überraschend positiv. Allerdings hat sich das Unterfangen als zu komplex herausgestellt. Eine Möglichkeit wäre, eine Liste mit zertifizierter Hardware auszugeben. Allerdings wäre das wie in den alten Tagen und zu Anwender-unfreundlich.

Außerdem würde das Fedora in eine privilegierte Position bringen. Als eine der größeren Distributionen (und Red Hat im Rücken – persönliche Anmerkung) habe man natürlich einen guten Draht zu den Hardware-Herstellern. Systeme mit dem Fedora-Schlüssel würden dann Fedora ganz brav starten. Aber was ist mit der Konkurrenz wie Mandriva, Arch, Linux Mint, Mepis und so weiter, stellt Garrett in den Raum? Es sei ein Ding der Unmöglichkeit, für alle verschiedenen Distributionen einen eigenen Schlüssel zu erstellen. Man wolle Anwender durch Leistung überzeugen und nicht, weil man einen besseren Draht zu OEMs habe – Respekt dafür von mir!

Eine andere Alternative sei einen allgemeinen Linux-Schlüssel zu erstellen. Aber auch dieses Unterfangen sei schwierig. Man müsste eine Instanz finden, die sich für die Verwaltung zuständig erklärt. Auch der root-Schlüssel müsste streng geheim und unter Bewachung stehen und diese Instanz müsste Zertifikate ausstellen. Erstens sei das richtig teuer und zweitens hätte man gar nicht die Zeit, so einen Koloss nun aus dem Boden zu stampfen.

Die letzte Option sei zwar nicht sehr attraktiv, aber dennoch die mit dem besten Kompromiss. Man nutzt einfach den Microsoft-Dienst, um Zertifikate zu erhalten. Das sei zwar nicht komplett kostenlos, aber mit einer Einmaligen Gebühr von 99 US-Dollar akzeptabel. Somit sichere man sich Kompatibilität zu einer breiten Masse an Hardware und stelle Fedora nicht in eine privilegierte Position. Bis eine bessere Lösung gefunden ist, gehe man nun nach Canossa (ok, das ist ein bisschen übertrieben 🙂 ). Der erste Bootloader wird also mit einem Microsoft-Schlüssel ausgestattet.

Bootloader

Hier hat man sich für ein Vielschicht-Modell entschieden. Der Weg durch den Microsoft-Sumpf sei mühsam und alles müsse manuell durchgeführt werden. Man will aber keine Verzögerungen bei den Aktualisierungen des Bootloaders riskieren. Stattdessen schreibt man einen sehr einfachen Bootloader, der nichts weiter tut, als den eigentlichen Bootloader (GRUB) zu starten. Dieser prüft auch, ob GRUB mit einem Fedora-Zertifikat ausgestattet ist und dann führt er den richtigen Bootloader aus. Somit könne man GRUB-Updates erstellen, ohne den Startprozess zu zerstören. Die erste Stufe des Bootloaders sollte sich nur sehr selten ändern und pro Release nicht öfter als ein Mal geändert werden. Der Wartungs-Aufwand halte sich definitiv in Grenzen.

Weiterhin seien einige Arbeiten an GRUB notwendig. Das Starten von weiteren Modulen, was dem Einspeisen von Code entspricht, wird deaktiviert, weil das Secure Boot aushebeln würde. Dann brauche man noch einen Mechanismus, der den Kernel auf ein gültige Zertifikat untersucht. Auch hier seien einige Restriktionen notwendig, damit niemand mit einem zertifizierten Kernel beliebigen Code starten kann. Ist Secure Boot deaktiviert, sind auch all diese Sperren aufgehoben.

Kernel

Bei Secure Boot darf jeder vertrauenswürdige Code sofort auf die Hardware zugreifen. Somit muss jedes Kernel-Modul zertifiziert sein und manche Kernel-Funktionalität ist dadurch eingeschränkt. PCI-Regionen können also zum Beispiel nicht mehr aus dem Userspace angesprochen werden – alle Grafikkarten brauchen somit Kernel-Treiber. Userspace-Modesettings gehören damit der Geschichte an. Sobald Secure Boot deaktiviert ist, zählt dies nicht mehr.

Im Klartext heisst das: Aller mitgelieferten Treiber sind zertifiziert und alle von außen kommenden nicht. Eine wirklich befriedigende Lösung gibt es laut Garrett hier derzeit nicht. Auch hier wolle man keinen Alleingang und Nur-Fedora oder -Ubuntu-Treiber seien kontraproduktiv für jeden. Man sucht nach einer Lösung, die mit allen Distributionen funktioniert.

Wer seinen eigenen Kernel oder gar eine eigene Distribution basteln möchte, stößt natürlich auf ein Hindernis. Fedora wird die Tools für die Zertifizierung zur Verfügung stellen, kann aber natürlich die Schlüssel nicht herausgeben. Hier gebe es drei Lösungen. Einmal sei der Weg zu Microsoft, der mit einem Obolus von 99 US-Dollar behaftet ist. Dann könnte man noch seinen eigenen Schlüssel erstellen und diesen mit der System-Firmware ausgeben. Lösung Nummer Drei ist offensichtlich: Secure Boot deaktivieren.

Was ist mit ARM?

Bei ARM ist Microsoft etwas strenger. Wer sein Gerät für Microsoft zertifiziert haben möchte, darf keinen Abschaltmechanismus für Secure Boot implementieren. Somit könnte man auch hier den Weg gehen und Microsoft für den Zertifizier-Dienst bezahlen, aber Support durch Abschalten ginge nicht. Das finden die Fedora-Entwickler inakzeptabel und werden dies nicht unterstützen.

Glücklicherweise habe Microsoft auf den ARM-Markt weit weniger Einfluss. Wer Linux auf ARM laufen lassen möchte, findet genug Hardware, mit der das möglich ist.

Wie geht es weiter?

Garrett hat noch einige andere Aspekte in seinem sehr langen Beitrag. Aber das Wichtigste, oder die Grundaussage ist meiner Meinung nach hier zusammengefasst. Garrett entschuldigt sich sogar für diese Holzhammer-Lösung und sie sei auch noch nicht in Stein gemeißelt. Wenn man einen besseren Weg findet, werde man diesen auch gehen. Für den Moment schätzt man sich glücklich, überhaupt eine annehmbare Lösung zu haben.

Hat sich eigentlich Ubuntu zu diesem Thema schon gemeldet? Ich bin gespannt, welchen Weg man bei Canonical einschlägt. Egal, wie man es dreht und wendet, Microsoft als Zertifizierungs-Stelle für Linux hat einen extrem faden Beigeschmack … oder?

• fitPC3

Fedora 17 Beefy Miracle

Die GNOME-Edition ist Standard ...

8 Photos