Linux Foundation hat Probleme mit Microsofts UEFI-Signatur-Prozess

James Bottomley hat eine interessante Odyssee bezüglich UEFI Secure Boot beschrieben, die immer noch nicht zu Ende ist. Der Code für den Pre-Bootloader ist fertig, allerdings verzögert sich die ganze Geschichte etwas.

Man hat die 99 US-Dollar an Verisign (Symantec) bezahlt und einen gültigen Verisign-Schlüssel bekommen – für die Linux Foundation. Hier müsse man lediglich anrufen und das Ganze bestätigen. Der Schlüssel wird dann in Form einer URL geschickt, der diesen im Browser installiert. Die Standard-Linux-SSL-Tools lassen sich benutzen, um das zu exrtahieren und ein PEM-Zertifikat und Schlüssel zu erzeugen. Das habe zunächst nichts mit UEFI-Signing zu tun. Aber man braucht es für Microsofts sysdev-System, um sich zu identifizieren.

Bevor man allerdings so ein sysdev-Konto erzeugen kann, müsse man eine ausführbare Datei digital unterschreiben und diese hochladen. Hier gibt es strikte Regeln, dass man sich eigentlich mit einer bestimmten Windows-Plattform anmelden muss. Allerdings hat sbsign genauso funktioniert und das Konto ließ sich anlegen.

Ist das Konto angelegt, kann man die UEFI Binaries aber immer noch nicht hochladen. Zuvor muss man noch einen Vertrag unterschreiben. Die Konditionen darin seien nicht Ohne und würden viele Lizenzen außen vor lassen (auch GPL für Treiber, allerdings keine Bootloader). Die hauseigenen Anwälte kamen zu dem Schluss, dass es die Linux Foundation kaum betreffe, weil man nicht selbst Produkte ausliefert. Es könnte für andere Firmen allerdings heikel werden. Laut Matthew Garret sei Microsoft allerdings bereit, mit Distributionen spezielle Konditionen auszuhandeln, um die Probleme zu beseitigen.

Sobald der Vertrag unterschrieben ist, beginne der wirkliche Spaß mit der Technik. Man könne nicht einfach die UEFI Binärdatei hochladen und bekommt diese unterschrieben zurück. Man müsse diese zunächst in eine Microsoft-Cabinet-Datei einwickeln. Zum Glück gibt es das Open-Source-Projekt lcab, mit dem sich das erledigen lässt. Nun müssen man die cab-Datei mit dem Verisign-Schlüssel unterzeichnen. Auch hier gibt es ein Open-Source-Projekt, osslsigncode, das diese Aufgabe erledigt. Diese Tools befinden sich auch in Bottomleys Repository openSUSE Build Service UEFI.

Das ist natürlich auch noch nicht das Ende der Fahnenstange, weil der Prozess auch noch Silverlight verlangt. Moonlight, selbst in Version 4 Preview, kann nicht, was Microsoft voraussetzt. Somit musste man Windows 7 in einer virtuellen Maschine hochfahren. Bei diesem Schritt muss man außrdem bestätigen, dass die zu unterschreibende Datei nicht unter der GPLv3 oder ähnlichen Open-Source-Lizenzen steht. Bottomley schätzt, dass diese Klausel verhindern soll, dass der Schlüssel einfach ausgegeben werden kann. Allerdings sei unklar, was “ähnliche Lizenzen” bedeuten.

Sobald die Datei hochgeladen ist, wird diese durch 7 Arbeitsschritte gejagt. Beim ersten Hochladen hängte das System bei Schritt 6 (die Dateien unterschreiben). Nach 6 Tagen hat der Entwickler eine E-Mail an den Microsoft-Support geschrieben und wollte wissen, was los ist. Als Antwort bekam er, dass die hochgeladene Datei keine gültige Win32-Applikation ist. Außerdem wurde er gefragt, ob es denn eine gültige Win32-Applikation sei. Er schrieb zurück, dass es natürlich keine Win32-Applikation ist, sondern eine gültiges UEFI-64-Bit-Binary. Darufhin bekam er keine weiteren Antworten.

Er hat es nochmal versucht und hat darauf hin eine unterschriebene Datei als E-Mail bekommen und das Dashboard hat einen Fehler angezeigt. Die Binärdatei funktioniert auf der Secure-Boot-Plattform und ist mit diesem Schlüssel unterzeichnet:

subject=/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
issuer=/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011

Wieder den Support angeschrieben, warum der Prozess angeblich fehlgeschlagen ist und nach diversen E-Mails er bekam als Antwort dass er die Datei nicht benutzen soll, weil sie nicht korrekt unterzeichnet ist. Man wolle sich wieder bei ihm melden. Bottomley vermutet, dass die Datei zwar mit einem generischen Microsoft-Schlüssel unterzeichnet ist. Allerdings deute nichts darauf hin, dass sich der Schlüssel mit der Linux Foundation in Zusammenhang bringen lasse.

Deswegen wartet man immer noch auf Microsoft, um einen von Microsoft gültig unterzeichneten Pre-Bootloader für die Linux Foundation zu bekommen. Sollte dies irgendwann passieren, wird man diesen auf der Webseite der Linux Foundation veröffentlichen.

Tja, da hat Microsoft nun Stein und Bein geschworen, diese neue Hürde nicht zu missbrauchen. Allerdings schaut mir der Prozess nicht gerade Linux-freundlich aus. Alleine das Voraussetzen von Silverlight ist ein Dealbreaker. Somit zwingt Microsoft jeden, der einen gültigen Schlüssel haben möchte, an einem gewissen Punkt Windows zu verwenden. Das Ganze stinkt einfach irgendwie.