Software::Security
UEFI Secure Boot: Technische Beschreibung von Shim
Red Hat-Entwickler Matthew Garrett hat den von ihm entwickelten Bootloader Shim näher beschrieben. Shim soll von Microsoft signiert sein und dient normalerweise dazu, einen weiteren signierten Bootloader nachzuladen.
Michael Kofler
UEFI-Bootmenü
Shim war aus der Zielsetzung entstanden, Distributionen auch mit aktiviertem Secure Boot lauffähig zu halten. Dazu muss der Bootloader signiert sein und sich mit einem im UEFI-BIOS hinterlegten Schlüssel verifizieren lassen. Aufgrund des Microsoft-Monopols kann aber nur der Microsoft-Schlüssel als einziger als vorhanden vorausgesetzt werden, weshalb alle Linux-Distributionen entweder einen von Microsoft signierten Bootloader verwenden müssten, oder ein spezieller signierter Booloader zum Einsatz kommen muss, der einen der bekannten freien Bootloader starten kann. Ein solcher Bootloader ist Shim. Shim wurde nach einer Idee von Suse noch um eine eigene, vom BIOS unabhängige Schlüsselverwaltung erweitert. Diese ermöglicht das einfache Laden und Verwalten von Schlüsseln, die dann permanent gespeichert werden, mit einer für alle Systeme identischen Oberfläche. Sie vermeidet den Umgang mit dem BIOS, bei dem keine einheitliche Oberfläche und kein Komfort vorausgesetzt werden kann, sondern jeder Hersteller eine andere Implementierung haben kann.
Red Hat-Entwickler Matthew Garrett, der UEFI Secure Boot und seine Auswirkungen bereits zuvor ausführlich beschrieben hatte, hat nun die Funktionsweise des von ihm entwickelten Bootloaders Shim im Detail beschrieben. Wie er schreibt, ist Shim nicht sehr komplex, da es eigentlich nur signierte Binärdateien laden muss. Es sei aber doch etwas komplizierter geworden als gedacht. Alle geplanten Funktionen von Shim sind laut Garrett jetzt komplett und der Quellcode ist auf GitHub zu finden.
Zunächst prüft Shim, ob die Signatur-Verifikation, also effektiv Secure Boot, im BIOS abgeschaltet ist. Falls ja, zeigt es kurz eine Warnung an und setzt dann ohne Signaturprüfung fort. Hat der Benutzer einen Mok-Request angestoßen, was wohl die Absicht bedeutet, die Signaturdatenbank zu bearbeiten, startet Shim den MokManager. Ansonsten wird die Mok-Schlüsselliste ins RAM kopiert, wo sie auch vom Linux-Kernel später zugreifbar ist, um Module zu verifizieren. Ferner installiert Shim ein UEFI-Protokoll, das es anderen Anwendungen ermöglicht, Teile von Shim aufzurufen.
Nun kann Shim den eigentlichen Bootloader laden. Dieser wird ins RAM geholt, dann werden die Sektionen identifiziert, die von der Signatur abgedeckt werden. Von diesen wird der benötigte Hash generiert, wozu eine Kopie der Krypto-Bibliothek verwendet wird, die aus dem BIOS-Quellcode (Tiano) stammt. Dies ist nach Garrett lediglich eine dünne Schicht über der OpenSSL-Bibliohek. Dann wird geprüft, ob der errechnete Hash in einer schwarzen Liste enthalten ist; falls ja, beendet sich Shim. Ebenso beendet sich Shim, wenn die Signatur nicht verifiziert werden kann.
Im Erfolgsfall dagegen nimmt Shim noch notwendige Anpassungen an der Binärdatei vor und startet sie dann. Wenn es sich um einen Bootloader handelt, sollte dieser normalerweise nicht mehr zu Shim zurückkehren. Kommt es dennoch dazu, beendet sich Shim, womit das UEFI-BIOS die nächste Bootoption probieren kann, sofern vorhanden.
Shim wird voraussichtlich nicht nur von Fedora, sondern auch von Ubuntu und Suse verwendet. Fedora sorgte außerdem dafür, dass Shim auch von kleineren Distributionen genutzt werden kann.
){kind=small}
