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

11 Kommentare Autor: Jürgen (jdo)

Windows 8 UEFI Secure Boot kein Linux 150x150“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 ...




 Alle Kommentare als Feed abonnieren

11 Kommentare zu “UEFI Secure Boot mit Fedora 18: Wir nehmen einfach einen Microsoft-Schlüssel!”

  1. konichiki says:

    Das ist ja schrecklich!! Das klingt ja fast schon nach Apfel Methoden. Wo kommen wir denn da hin das wir, egal ob die Macher meiner Distro oder ich, Geld dafür bezahlen müssen das wir unseren PC benutzen dürfen. Ich kauf mir den PC also will ich damit auch machen was ich will

  2. Rayman says:

    Das klingt ja alles nicht so prall. Ich stecke jetzt nicht so tief in der Materie drin aber für mich riecht das alles nach Erpressung von Seiten Microsofts die hier schamlos ihr Monopol ausnutzen um der freien Konkurrenz die Luft abzuschnüren. Man kann mich aber gerne eines Besseren belehren. Bringt denn Secure Boot wirklich einen Sicherheitszuwachs? Ich bin da skeptisch.

    • stfischr says:

      > Bringt denn Secure Boot wirklich einen Sicherheitszuwachs?

      Da die genaue Implementierung vom Mainboardhersteller abhängt, hast du neben Betriebssystem noch eine 2. Stelle, der du vertrauen musst. Und das Hardwarehersteller es mit der Sicherheit nicht ganz so ernst sehen, sieht man ja an diversen "verschlüsselten" USB-Stickst.

      Ich vertraue nur Ubuntu und den Programmen in dessen Paketquellen. LUKS verschlüsselt und /boot auf nen USB-Stick. Mehr Sicherheit bekommt man anderswo auch nicht.

  3. Caleb_IX says:

    Früher ist es mir kalt den Rücken hinuntergelaufen, wenn ich solche Nachrichten gelesen habe. Heute sehe ich das pragmatischer...

    1. Denke ich, dass es in jedem BIOS eine Funktion geben wird, um das Secure-Zeugs zu deaktivieren.

    2. Selbst, wenn nicht, traue ich den Linux-Entwicklern genug Einfallsreichtum zu, um auch mit diesem Problem fertig zu werden.

    3. x86 Systeme sind eh ein Auslaufmodell und Windows auf ARM ist so atraktiv, wie eine alte Frau in Reizwäsche. Für mich (jetzt mal rein subjektiv) ist klar, dass ich keinen gechlossenen Windows 8+ Computer kaufen werde. Ich will kein Windows und brauche es nicht (auch nicht als Dualboot!). Im schlimmsten Szenario, wird bei mir also ARM und Android, den gesammten Heimcoputerbereich übernehmen. HP wird also noch einige Stellen abbauen können und Nokia kann den Laden gleich dicht machen, wenn die Aktionäre nicht endlich Ordnung im Stall machen. 😉

    • Victor says:

      Ich bin auch deine Meinung.

      Ausserdem ist nur eine Frage der Zeit, bis man das Master-Kay knackt.
      So wie bei HDMI und DVD der Fall war 😉

  4. asdf says:

    Sag mir einer wenn ich was falsch verstehe:

    Mir stellt sich schon die Frage, inwiefern "mehr Sicherheit" gewährleistet ist, wenn man sich die Vertrauenwürdigkeit bei M$ mal eben für 99$ holen kann...

    • Mike says:

      Das ist eine ausgezeichnete Frage!
      Wie sicher ist das ganze eigentlich wirklich, spätestens dann, wenn mal ein Schlüssel an die Öffentlichkeit gelangt?

  5. Darvon says:

    Eine Firma nutzt ihren hohen Marktanteil, um Druck auf die Hardwarehersteller auszuüben, damit diese Beschränkungen in ihre Produkte einbauen, die es erschweren, konkurrierende Produkte mit der Hardware nutzen zu können. Diese Beschränkungen können entweder gar nicht (ARM) oder nur mit einem gewissen Verlust des Funktionsumfanges (Secureboot ausschalten) deaktiviert werden.
    Riecht nach einer Klage bei den Wettbewerbsbehörden. In Australien hat man es ja schon überlegt, glaub ich...

    • Victor says:

      Und warum klagt Deutschland, Schweiz, Österreich usw. nicht???

      Wie könnten wir die Wettbewerbsbehörden motivieren zu klagen deine Meinung nach?

  6. Killx says:

    Hmm dann werde ich mir vielleicht doch noch einen neuen PC kaufen bevor dieser Müll auf den Markt kommt :>

    Denn ich will auf keinen Fall Windoof 8, die können ihre Kacheln schön behalten ^^

    Eigentlich ist das schon sehr dreist. Am besten wäre es wenn Hardware mit dieser Funktion verboten werden würde, dann würden die Hersteller ganz schnell wieder umschwenken ^^

    Aber viel ändern können wird man da jetzt auch nicht mehr, leider :/

  7. Thoys says:

    Ich find die Idee mit der Litse der Linux-Zertifizierten Hardware eigentlich gut. Also vorausgesetzt es gäbe dann auch - wie es hier beschrieben wird - genug Firmen die es machen würden.
    Diese sollen für ihre Mühen dann auch damit belohnt werden, dass Linuxuser ihre Hardware kaufen und im Idealfall merken die anderen diese 2 Prozent Umsatzeinbuse.

    Man darf ja träumen gg

    Grüße