Login
Newsletter
Werbung

Fr, 1. Juni 2012, 12:12

Software::Distributionen::Fedora

Garrett: Implementierung von UEFI Secure Boot in Fedora

Matthew Garrett, ein bei Red Hat angestellter Kernel-Entwickler, erklärt anlässlich der Tatsache, dass Windows 8 mit seiner Secure Boot-Funktion auf Mainboards mit neuster UEFI-Version ab 2.3.1 den Start unsignierter Bootloader wie Grub2 verhindert, wie sich Red Hat die Lösung des Problems für Fedora 18 vorstellt.

fedoraproject.org

Windows 8 implementiert unter anderem eine neue Funktion »Secure Boot«, die auf PC-Mainboards mit der aktuellen UEFI-Versionen ab 2.3.1 den Start unsignierter Bootloader blockiert. Ist Secure Boot aktiv, lässt sich demnach auch kein Linux oder anderes Betriebssystem starten, das nicht mit einem im BIOS hinterlegten Schlüssel signiert wurde. Die Idee dabei ist, den Rechner vor Zugriffen durch ein anderes Betriebssystem zu schützen, etwa wenn ein Dieb ein gestohlenes Notebook von einem Linux-USB-Stick zu booten versucht, um an die auf der Festplatte gespeicherten Daten zu gelangen. Matthew Garrett hatte bereits im Herbst letzten Jahres in seinem Blog darauf hingewiesen, dass es sich in Zukunft als problematisch erweisen könnte, Linux auf einem PC mit UEFI-2.3.1-Mainboard zu installieren. Jetzt erklärt er in einem erneuten Blog-Eintrag, auf welche Weise die nächste Fedora-Version 18 die UEFI-Funktion Secure Boot unterstützen soll.

Das größte Problem dabei sei, dass der Schlüssel im BIOS hinterlegt sein müsse. Da Red Hat über die notwendigen Kontakte zu den Hardware-/Mainboard-Herstellern verfüge, könne man diese zwar sicher davon überzeugen, den Fedora-Schlüssel zusätzlich zum Windows-Schlüssel in Ihr BIOS zu integrieren, sodass Fedora einen eigenen Schlüssel erstellen und den Bootloader der Distribution damit signieren könne, davon hätten aber andere Distributionen, bzw. Linux-Versionen nichts. Ein generischer Schlüssel für alle Linux-Distributionen hingegen erfordere eine aufwendige und teure Zertifizierungsinfrastruktur für Linux-Distributionen.

Garrett schlägt daher als pragmatischte Lösung vor, für die Signierung des eigenen Bootloaders das Microsofts-Angebot von 99 US-Dollar für die Signierung eines Bootloaders in Anspruch zu nehmen. Da eine Signierung mit welcher Lösung auch immer kaum einfacher und günstiger zu haben sei, werde Fedora 18 aller Wahrscheinlichkeit einen von Microsoft signierten Bootloader besitzen. Dabei werde man jedoch nicht mehr auf Grub allein zurückgreifen können, weil die Signierung dann bei jedem Grub-Update erneut erforderlich wäre. Besser sei daher das Vorschalten eines offiziell signierten Mini-Bootloaders, der dann wiederum die Integrität von Grub2 prüfen und anschließend den Standard-Bootloader von Linux starten könne. Grub2 wird jedoch in Fedora 18 keine Module nachladen können, sondern lediglich die dem Kernel zu übergebende Kommandozeile und die Integrität des Kernels prüfen, um eine sichere Boot-Kette zu gewährleisten.

Dass Microsoft mit seiner Secure Boot-Funktion nicht die Existenz anderer Betriebssysteme erschweren oder verhindern will, zeigt sich im moderaten Preis für die Signierung, denn die Grundidee bei UEFI Secure Boot, dass nur vertrauenswürdiger, also signierter Code auf die Hardware zugreifen darf, ist durchaus begrüßenswert. Konsequenterweise muss dann aber auch jedes Kernel-Module signiert sein und der Kernel das Laden unsignierter Module verweigern. Zudem müssten die Kernel-Entwickler wohl die eine oder andere Kernel-Funktionen deaktivieren, damit jeder Hardwarezugriff aus dem Userspace, wie etwa beim X-Server, unterbunden wird.

Garrett selbst findet den vorgeschlagenen Ansatz nicht besonders attraktiv, weil ein Signierungszwang für Treiber ein Problem für sämtliche Treiber darstelle, die nicht Teil der Distribution sind. Außerdem werde das Übersetzen eines eigenen Kernels damit deutlich aufwendiger.

Werbung
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung