Suse plant für seine Unternehmensprodukte, in Hinblick auf UEFI Secure
Boot eine auf Fedoras Strategie aufsetzende Lösung zu verwenden und
diese geringfügig zu erweitern. Was das Opensuse-Projekt in dieser Frage
beabsichtigt, ist noch noch nicht entschieden.
[Blockierte Grafik: http://www.pro-linux.de/images/NB3/imgdb/n_opensuse-logo.jpg]
Der Suse-Mitarbeiter Olaf Kirch
erläutert den derzeitigen Stand der Diskussion der Nürnberger zum Thema
UEFI Secure Boot in einen ausführlichen Blog-Eintrag. Darin spricht
Kirch zunächst allgemein über mögliche Probleme, die sich für
Linux-Distributoren im Zusammenhang mit UEFI-Secure-Boot ergeben, und
stellt dann die von Suse für seine Unternehmensprodukte favorisierte
Lösung vor.Die sieht ebenfalls den Einsatz des von Matthew
Garret von Red Hat entwickelten Bootloaders Shim vor, der aller
Voraussicht nach über eine Microsoft-Signatur verfügen wird. Das weitere
Vorgehen bei Suse unterscheidet sich jedoch in einigen Punkten von
Fedoras Plan und trägt in einigen Details auch Züge der von Canonical
für Ubuntu geplanten Lösung. Was das bedeutet erläutert der
Suse-Entwickler Vojtěch Pavlík in einem weiteren Blog-Eintrag.
Zwar
will auch Suse den von Garret entwickelten Mini-Boot-Loader Shim
einsetzen, der soll aber in zwei Versionen beiliegen, einmal mit
Microsoft-Schlüssel signiert und einmal mit einer Signatur von Suse,
womit die Strategie auch Züge der von Canoncial favorisierten Lösung
trägt, denn Ubuntu will künftig ebenfalls einen eigenen, selbst
signierten Boot-Loader mitliefern. Die Shim-Variante von Suse mit
eigener Signatur wird bei Hardware mit UEFI-Firmware und eingeschaltetem
Secure Boot nur booten, wenn in der Firmware ein öffentlicher Schlüssel
hinterlegt ist, der die Signatur von Suse verifiziert. Im Unterschied
zu Fedoras Lösung erweitert Suse Shim derart, dass der die öffentlichen
Schlüssel zum Verifizieren von Kernel und Grub in separaten Dateien
ablegt, während Fedoras Shim diese Schlüssel in der Binärdatei enthält,
was das Hinzufügen weiterer Schlüssel ohne Neuübersetzen und Signieren
von Shim verhindert. Suse nennt seine in Dateiform gespeicherten
öffentliche Schlüssel MOKs (Machine Owner Keys). Damit Shim unerlaubte
Modifikationen erkennen kann, soll der Hash-Wert der Datei in einer
sogenannten »Boot Services Only Variable« von UEFI gesichert sein,
welche die UEFI-Spezifikationen neben »Authenticated Variables«
ebenfalls vorsehen. Im weiteren Verlauf gleicht die sichere Boot-Kette
wieder dem Fedora-Verfahren, bei dem Shim den eigentlichen Boot-Loader
Grub2 nachlädt und ausführt, sofern dieser vertrauenswürdig ist, was
Shim wiederum einem der hinterlegten MOKs entnimmt, die Shim an Grub
übergibt. Damit kann Grub seinerseits prüfen, ob der ausgewählte Kernel
vertrauenswürdig ist, und diesen dann starten.
Suses Verfahren
erlaubt auf einfache Weise das Starten selbst signierter Kernel via
Secure Boot, weil der zugehörige Schlüssel nur bei Shim hinterlegt sein
muss, während bei Fedoras Verfahren auch Shim und Grub mit privaten
Schlüsseln signiert und die zugehörigen öffentlichen Schlüssel in der
UEFI-Firmware hinterlegt sein müssen. Pavlík räumt zwar ein, dass sein
Verfahren auf dem ersten Blick den UEFI-Spezifikationen sowie den
Windows-8-Logo-Anforderungen zu widersprechen scheint, dass es die UEFI
Spezifikationen aber erlauben, wenn auch nicht zwingend verlangen, dass
eine UEFI-Implementation benutzerautorisierten EFI-Code mit »ungültiger«
Signatur mit einem Datei-basierten Schlüssel verifiziert, dessen
Hash-Wert in einer Boot Services Only Variable gespeichert ist. Sogar
Garret selbst hat sich inzwischen in seinem Blog anerkennend zu Pavlíks Vorschlag geäußert und kann sich vorstellen, die Lösung auch für Fedora zu übernehmen.
Laut
Olaf Kirch steht im Moment jedoch lediglich die Überlegung im Raum, die
von Pavlík aufgezeigte Lösung für Suse Linux Enterprise 11 Service Pack
3 bei einer Neuinstallation auf Geräten mit Secure-Boot anzubieten.
Weitere Details und konkrete Pläne will Kirch erst in den kommenden
Tagen in Form weiterer Blog-Einträge rund um das UEFI-Secure-Boot
diskutieren und vervollständigen. Das gibt auch der
Opensuse-Gemeinschaft die Möglichkeit, über den Vorschlag für ihre
eigene Distribution nachzudenken, denn beim Opensuse-Projekt ist in
dieser Frage bisher noch keine Entscheidung gefallen.
Aus: Pro-Linux