Matthew Garret rollt die Kernel-Diskussion um Secure Boot noch mal mehr oder weniger sachlich auf und ich bin zwigespalten

Nachdem erst einmal die Fetzen und diverse für Torvalds typisch unverblümte Aussagen geflogen sind, haben sich die Gemüter vielleicht ein bisschen beruhigt und Mr. Shim, Matthew Garret, geht noch einmal sachlicher an die Geschichte heran.

Wenn eine Linux-Distribution im Moment ein System it aktiviertem UEFI-Secure Boot starten möchte, geht das relativ stressfrei, wenn der Anwender einen digital unterzeichneten Bootloader wie Shim oder den von der Linux Foundation verwendet. Es ist zwar nicht wie früher “einstecken und loslegen”, aber besonders kompliziert ist es auch nicht. Der präsente Endanwender kann auch seinen Schlüssel hinzufügen und muss sich dann nicht weiter um Microsoft kümmern.

Was passiert aber, wenn eine Distribution starten soll, ohne dass der Anwender einen Schlüssel installieren muss, fragt Garret. Es gäbe einige Szenarien, bei denen man das wolle: Bequemlichkeit, Netboot und so weiter. Dieses Systeme ließen sich aber nun auch benutzen, um eine Windows-Installation anzugreifen. Das sei bisher noch nicht passiert, aber sollte das der Fall sein, könnte Microsoft diesen Schlüssel auf eine schwaze Liste setzen und die Distribution würde auf Systemen mit UEFI Secure Boot nicht mehr starten. Garret hält das für möglich.

Dieses Szenario könne man verhindern, indem man zum Beispiel den Kernel dazu bringt, alle Module zu unterschreiben. Für die in den Distributionen enthaltenen Module sei das einfach, weil man diese bereits ausliefert. Für Module von Drittanbietern sei das nicht mehr so trivial. Nun könnte man

1. Keine Module von Drittanbietern unterstützen
2. Die Distribution müsse die Module unterschreiben
3. Der Hersteller muss die Module unterschreiben

Option 1 sei nicht gut, weil man damit Anwender verärgert.

Lösung 2 bringe Lizenz-Sorgen mit sich und außerdem müsse man entscheiden, welche Treiber man überhaupt unterschreibt. Bei NVIDIA und AMD sei dies recht einfach, aber wie verhält es sich mit der Software vom “Ehrlichen Johns Treiber Imperium”. Das Problem ist also, die Identität von jemandem zu verifizieren und das ist nicht einfach und kann teuer sein.

Option 3 würde die Verantwortung in die Hände anderer Leute geben. Natürlich sei es immer gut, wenn andere für einen arbeiten, aber man muss diesen auch vertrauen können. Eine Alternatie sei, dass man bereits Schlüsseln vertraut, die mit einem vertrauenswürdigen Schlüssel unterzeichnet wurde. Also das Prinzip: Der Freund eines Freundes ist auch mein Freund.

Gut sei, dass so ein Schlüssel existiert. Die schlechten Nachrichten: er gehört Microsoft.

Die hitzige Diskussion auf LKML drehte sich um ein Patchset, das dem Kernel erlaubt hätte, neue Schlüssel abzunicken, die sich in einen PE/COFF-Binärdatei befinden, die bereits von einem vertrauenswürdigen Schlüssel abgesegnet sind. Bedeutet hier, wenn der Kernel ein Modul vorgesetzt bekommt, das mit dem selben Schlüssel abgezeichnet wurde, mit dem auch der Bootloader unterschrieben ist, winkt er das Modul durch. Garret weist darauf hin, dass dieses Patchset nicht den Schlüsselsatz ändert, dem der Kernel sowieso schon vertraut.

Linus Torvalds ist mit dieser Idee gar nicht glücklich. Der Kernel würde dadurch etwas komplexer, weil er einen Parser für das oben genannte Szenario bräuchte und es gibt bereits eine Schnittstelle, die das mit X.509-Zertifikaten macht. Das Problem ist aber nun, dass Microsoft keine X.509-Zertifikate unterschreibt und es keine Möglichkeit gibt, PE/COFF-Signaturen in eine X.509-Signatur umzuwandeln. Jemand müsste die Schlüssel also wieder unterzeichnen, was zurück zu Option 2 führen würde. Ein automatisches System wäre schön, das die PE/COFF-Zertifkate auf eine gültige Microsoft-Signatur überprüft, den Schlüssel extrahiert und dann im Endeffekt ein X.509-Zertifikat ausspuckt. Somit bräuchte man keinen neuen Code im Kernel.

Dazu braucht es aber wieder einen Dritten und die logische Wahl fiele auf die Linux Foundation. Allerdings säßen dort Mitglieder, die das Unterzeichnen von Modulen für unnötig halten und es gäbe auch kein Risiko, dass Microsoft sich traut, Schlüssel einfach auf die Blacklist zu setzen.

Das ganze könnte nun auch so enden, dass die Distributonen das Patchset eigenständig aufnehmen und andere lassen es halt. Einige wird es ein Dorn im Auge sein, dass man mit dieser Lösung zu viel Vertrauen in Microsoft legt. Garret betont noch einmal, dass dies aber nicht wirklich so sei: Wenn die Firmware Microsoft vertraut, vertraut man Microsoft sowieso schon. Wenn die Firmware Microsoft nicht vertraut, wird das der Kernel auch nicht tun.

Garret würde es nicht verwundern, dass absolut gar nichts passiert, bis jemand ein unterzeichnetes Linux-System verwendet, um damit Windows anzugreifen. Microsofts Antwort schätzt er dann düster ein.

Mein Senf

UEFI Secure Boot an oder aus?

Man muss ja Matthew Garret für seine Arbeit mit Shim irgendwie dankbar sein, dass sich Linux recht einfach auf Rechnern mit aktiviertem UEFI Secure Boot installieren und ausführen lässt. Auch seine Bemühungen, alles verständlich zu erklären und so weiter und so fort.

Was mich persönlich aber echt an der Sache stört ist, keiner spricht drüber, ob das ganze Secure Boot überhaupt notwendig ist. Microsoft hat es durchgedrückt und den Hardware-Herstellern das so befohlen. Die haben den Schwanz eingezogen, da man sich sonst keinen Windows-8-Aufkleber auf den Rechner pappen kann. Was wäre denn passiert, wenn alle Hersteller gemeinsam gesagt hätten: Gut Microsoft, dann verkaufen wir halt kein Windows 8, kannst ja Deine eigenen Rechner bauen. Wenn es dann mal ne vernünftige Lösung für alle gibt, dann reden wir noch mal drüber: Option 4! Solange sich der Unsinn abschalten lässt, werde ich das auch tun und es auch allen empfehlen, die mich danach fragen. Schalt den Scheiß ab, dann installiere, was Du möchtest. Willst Du Windows sowieso verwenden, kannst es ja aktiviert lassen.

Was mir sehr missfällt und das hat auch Torvalds erwähnt, dass Garret mit seinen düsteren Microsoft-Rache-Voraussagungen Angst und Schrecken verbreitet. Um mit einem unterschriebenen Linux Windows anzugreifen, muss ich erst mal physikalisch am Rechner sitzen, den Schlüssel eintragen und dann Linux starten. Ja gut, da könnte nun einer eine Distribution machen, die beim Ausführen des Live-Systems Windows mit Viren, rootkits und anderem Zeug vollpumpt … ah ja … lassen wir mal lieber die Kirche im Dorf. Und selbst dann wenn sie einer Distribution den Schlüssel entziehen – ich kann weiterhin UEFI Secure Boot deaktivieren. So weit ich das verstehe wird es auch nicht so sein, dass Microsoft einen Schlüssel auf die schwarze Liste setzt und die Distribution dann nicht mehr auf bereits ausgelieferten Rechnern startet. Dazu ist erst ein Firmware-Update notwendig oder ein neuer Rechner mit einer Firmware auf dem neuesten Stand.

Anstatt zu evaluieren, wie man den Mist wieder abschaffen kann, hat Microsoft bekommen, was sie wollten und die Kernel-Entwickler hauen sich die Köpfe drüber ein … wie war das mit dem lachenden Dritten? Von daher verstehe ich den Standpunkt von Torvalds sehr gut, den es nicht interessiert, was Microsoft will … und es mit X.509 bereits einen Standard gibt …