Matthew Garret erklärt, wie kleinere Distributionen mit UEFI Secure Boot arbeiten können
Am Plan, wie Fedora mit UEFI Secure Boot umgehen wird, hat sich laut Garret eigentlich nichts geändert. Allerdings sei die Methode davon abhängig, eine Binärdatei mit dem eingebetteten Fedora-Schlüssel zu erzeugen und diese müsste dann von Microsoft digital unterschrieben werden. Für Fedora sei das einfach, aber kleinere Distributionen könnten ihre Schwierigkeiten damit haben. Diese hätten nun diverse Möglichkeiten:
- Secure Boot muss deaktiviert sein – nicht wirklich ideal, weil das von Gerät zu Gerät unterschiedlich sein kann.
- Der Rechner müsse sich im Setup-Modus befinden. Distributionen könnten dann einen unsignierten Bootloader ausliefern, der die Distributions-Schlüssel dann in die Datenbank schreibt. Wie das funktioniert, ist hier beschrieben. Ideal sei das aber auch nicht, weil man eben das Problem habe, dass das UI von Maschine zu Maschine unterschiedlich ist.
- Einen signierten Booloader ausliefern, der Schlüssel in seine eigene Datenbank aufnehmen kann. SUSEs Bootloader-Design ist so gestaltet, dass der Bootloader seine eigene Schlüssel-Datenbank hat. Der Bootloader wird so jegliche zweite Stufe mit einem Schlüssel aus dieser Datenbank unterschreiben. Weil der Bootloader nun für seine eigene Schlüssel-Auslieferung verantwortlich ist, kann er auch seine eigenen Regeln aufstellen und neue Schlüssel von einem Dateisystem aufnehmen.
Garret hat SUSEs Code für das Schlüssel-Management genommen und in seinen eigenen Shim-Tree mit einigen Änderungen übertragen. Der grundlegende Unterschied sei, dass ein Bootloader der zweiten Stufe mit einem nicht vertrauenswürdigem Schlüssel immer ein UI aufrufe und nicht einfach einen Start verweigert. Somit kann der Anwender die vorhandenen Dateisysteme ansteuern und einen möglichen Schlüssel importieren. Ab da wird der Bootloader Binärdateien vertrauen, die mit diesem Schlüssel unterzeichnet sind.
Nun können Distributionen eine existierende und unterschriebene Kopie von Shim nehmen und auf ihren Installations-Medien ausliefern – das gilt natürlich auch mit einer Datei, der ihren Schlüssel enthält.
Der Vorteil dieser dritten Methode ist, dass das UI immer gleich aussieht und sich konsistent verhält. Somit lasse sich der Installations-Prozess einfacher dokumentieren. Der Nachteil ist, dass die Distribution Shim nicht neu bauen kann und eine vorkompilierte Binärdatei ausliefern muss. Für einige Distributionen mag das ein inakzeptabler Ansatz sein (Garret nennt als Beispiel Debian), allerdings spart es anderen, sich selbst mit Microsoft herumplagen zu müssen.
