UEFI Secure Boot sperrt manche freie Software aus
Lange Bearbeitungszeiten beim Signaturprozess des Secure-Boot-Bootloaders Shim lassen einige Programmierer verzweifeln.
BIOS-Setup-Optionen für UEFI Secure Boot
(Bild: c't Magazin)
Monatelange Verzögerungen bei der Freigabe freier Betriebssysteme für den Bootloader Shim bereiten Entwicklern und Softwarefirmen erhebliche Probleme. Das trifft vor allem Nicht-Linux-Betriebssysteme abseits der großen Linux-Distributionen, die wegen der langen Bearbeitungszeiten bestimmte Patches und neue Software-Versionen nicht ausliefern können.
"Hauptschlüssel" bei Microsoft
Die meisten aktuellen Desktop-PCs, Notebooks und Server sowie auch viele Embedded Systems mit x86-Prozessoren starten mit UEFI Secure Boot, um die Sicherheit zu stärken. Den kryptografischen "Hauptschlüssel" hat dabei allerdings de facto Microsoft in der Hand.
Zwar lässt sich Secure Boot bei vielen Systemen im BIOS-Setup abschalten und einige UEFI-BIOS-Implementierungen erlauben es, eigene Zertifikate für selbst signierte Bootloader in die Firmware zu importieren. Letzteres ist aber kompliziert und aufwändig, ersteres schwächt die Sicherheit.
In der Praxis ist es daher auch für freie Software wichtig, im Secure-Boot-Standardmodus mit Microsoft-Signatur starten zu können.
Shim-Review
Secure Boot soll Computer sicherer machen, indem es nur kryptografisch signierte Bootloader ausführt. Auch freie Betriebssysteme können im Secure-Boot-Modus sicher starten, etwa indem sie den Bootloader Shim nutzen.
Um die Vertrauenswürdigkeit sicherzustellen, müssen solche freien Betriebssysteme aber eine Reihe von Anforderungen erfüllen und eine Prüfung durch das Shim Review Board durchlaufen. Letztlich signiert dann Microsoft die von Shim Review Board als gut befundenen Bootloader. Die genauen "UEFI Signing Requirements" beschreibt Microsoft in seiner Tech Community.
Review-Probleme
Schon seit mehreren Jahren gibt es immer wieder Kritik, dass Shim-Reviews sehr lange dauern können. Doch seit Bekanntwerden der Sicherheitslücke BootHole hat sich das Problem noch verschärft.
Für Betriebssysteme, die keinen Linux-Kernel verwenden, ist die Situation besonders schwierig. Eine Voraussetzung für ein erfolgreiches Shim-Review ist nämlich der Nachweis, dass der Kernel-Lockdown funktioniert. Damit ist gemeint, dass der im Secure-Boot-Modus gestartete Kernel zur Laufzeit nur signierte Kernel-Module lädt, deren Signatur zum hinterlegten Secure-Boot-Schlüssel in der Firmware passen. Ansonsten würde sich Secure Boot letztlich aushebeln lassen.
Mitglieder des Shim Review Board sehen sich aber derzeit außerstande, den Kernel Lockdown Mode bei anderen als Linux-Kernels zu beurteilen.
Somit ist eine sehr schwierige Situation entstanden. Laut einem GitHub-Issue-Eintrag arbeiten die Shim-Entwickler derzeit an einer möglichen Lösung für das Problem. Termine wurden aber nicht genannt.
Auch bei Patches gegen die BootHole-Lücke gab es bei einigen Linux-Distributionen zwischenzeitlich Probleme, die auch deren jeweiligen Shims betreffen.
(ciw)
