Red Hats Matthew Garret: Warum UEFI problematisch für Linux ist

Matthew Garret beschäftigt sich bekanntlich intensiv mit UEFI oder Secure Boot. Er hat sich auch zu den technischen Details geäußert. Diese würden Leute aber nun so auslegen, dass Linux mit minimalem Aufwand UEFI unterstützen kann. In einem neuen Beitrag klärt er auf, dass dies irgendwie schon richtig sei, aber nicht das Problem löse.

Secure Boot setzt voraus, dass sämtlicher Code, der Hardware berührt, vertrauenswürdig sein muss

Secure Boot ist ein Mechanismus, der nur vertrauenswürdigen oder digital signierten Code ausführen lässt. Das bedeutet dass die UEFI-Treiber, der Bootloader und der Kernel digital unterschrieben sein müssen. Damit ist sichergestellt, dass das zu startende Betriebssystem sicher ist. Im Gegensatz zu Trusted Boot, kannst Du bei Secure Boot nicht sichergehen, dass nur vertrauenswürdiger Code ausgeführt wurde. Dies muss vom Betriebssystem abgesichert sein.

Laut Garret klingt das zunächst nach keinem großen Problem – ist es aber. Er stellt folgendes Szenario als Beispiel:

Stell Dir vor wir haben eine signierte Linux Bootloader und einen signierten Linux-Kernel und diese Signaturen sind mit einem globalen vertrauenswürdigen Schlüssel erstellt. Dieser Kernel würde auf jeder Hardware starten, die Secure Boot verwendet. Nun stell Dir vor, dass ein Angreifer ein Kernel-Modul schreibt, das eine vorgetäuschte UEFI-Umgebung aufsetzt, den Kernel keinen Code mehr ausführen lässt und dann den Windows Bootbloader ausführt – ein bisschen wie kexec. Der Windows Bootloader denkt, er führt ein Secure Boot durch, allerdings läuft alles in der vorgetäuschten UEFI-Umgebung ab. Der Windows-Kernel wird so modifiziert, den Linux-Code zu verbergen. Alles schaut eigentlich gut aus, aber Deine Kreditkarten-Details sind schon auf dem Weg nach China. In diesem Fall würde der Linux-Kernel ganz einfach als Malware-Loader missbraucht. Einziges Anzeichen, dass etwas faul ist – der Startprozess ist etwas langsamer.

Somit ist nur den Kernel digital zu unterschreiben nicht genug. Signierte Kernel müssen dann verhindern, dass unsignierte Kernel-Module eigenladen werden. VirtualBox unter Linux, NVIDIAs proprietäre Treiber unter Linux, alle weitere Treiber außerhalb des Kernel-Baums würden damit tot sein. Ebenso sei es nicht möglich, einen aktualisierten Treiber lokal zu übersetzen. Das Problem gelte auch für Windows. Während der Anwender unter Windows 7 Integritäts-Prüfungen für Treiber deaktivieren kann, muss Windows 8 das verbieten, wenn Secure Boot verwendet wird.

Behebt der Custom Mode diese Probleme?

Microsofts neues Regelwerk besagt, dass alls Systeme einen Custom Mode haben müssen (das gilt aber nur für x86-Systeme. Auf ARM-Rechnern darf es keinen Custom Mode geben, wenn der Hardware-Hersteller Windows 8 ausliefern möchte). Somit ist es Linux-Herstellern möglich, einen eigenen Schlüssel zu erzeugen und diesen auszuliefern. Somit sollte eigentlich jeder glücklich sein. Allerdings ist das laut Garret nicht gut genug. Viele Leute hätten sehr viel Zeit investiert, um Linux auf einfache Weise zu installieren. Meist müsse man nur eine CD einlegen.

Allerdings würde man technisch weniger versierten Anwendern eine zusätzliche Hürde aufbürden. Diese müssten in die Firmware vordringen und weitere Dinge neu konfigurieren. Somit sei die Möglichkeit Linux zu installieren, eingeschränkt.

Weiterhin sei es unmöglich, eine Linux-Installation zu dokumentieren. Diese sei damit erstens kompliziert und zweitens abhängig vom Hardware-Hersteller. Letztere werden ihre eigenen Firmware-Schnittstellen ausgeben, um sich von anderen abzuheben. Der Custom Mode würde also überall anders aussehen. Ebenso gibt es derzeit keine Spezifikation, in welcher Form der Schlüssel übergeben werden muss.

Ebenso weist Garret darauf hin, wie das bei Masseninstallationen sei. Ein paar tausend Rechner über das Netzwerk zu installieren sein eine schwierige Aufgabe, wenn ein Mensch zunächst den Custom Mode aktivieren muss.

Fazit

Der Custom Mode behebt die Probleme also nicht. Man könne Code in kurzer Zeit schreiben, damit Linux Secure Boot unterstützt – das meiste davon sei sogar schon erledigt. Allerdings sei das Secure Boot für den praktischen Einsatz alles andere als ausgereift.