Bild: „Intel“ von Christian Rasmussen Lizenz: CC By-SA 2.0
In den letzten Tagen wurde einmal wieder Kritik an Intel laut, da die Veröffentlichung eines neuen Microcodes gegen die L1 Terminal Fault-Lücke sowie gegen Speculative Store Bypassing (SSB) an Lizenzbedingungen geknüpft war, die zumindest für Debian nicht akzeptabel waren.
Debian verweigerte die Auslieferung
Wie aus der Antwort auf einen Debian-Bugreport hervorging, hielt der Debian-Kernel-Maintainer Henrique de Moraes Holschuh den seit Wochen bereits paketierten Microcode mit der Bezeichnung intel-microcode 3.20180807.1 aufgrund der zum im Juli ausgelieferten Vorgänger intel-microcode 3.20180703.2. geänderten Lizenz zurück, ohne dass Holschuh jedoch zunächst auf den genauen Grund einging.
Perens benennt Ross und Reiter
Den lieferte dann Open-Source-Urgestein Bruce Perens in seinem Blog. Die Lizenzbestimmungen waren, wie Perens darlegt, um einen Zusatz ergänzt worden, der es untersagte, Benchmarks oder Vergleiche, die auf der Grundlage des eingespielten Microcodes entstanden sind, zu veröffentlichen.
»You will not, and will not allow any third party to … publish or provide any Software benchmark or comparison test results.» – Intel Lizenzbedingung
Maulkorb für die Kunden
Dabei ging es Intel wohl darum, zu verhindern, dass die zu erwartenden Leistungseinbußen, die bei virtuellen Maschinen angeblich bis zu 50 Prozent betragen können und beim Desktop immer noch 5 – 10 Prozent ausmachen sollen, öffentlich belegt werden. Bereits bei den vorangegangenen Spectre-Lücken war Intel mehrfach, hauptsächlich von Unternehmen, verklagt worden, da die zugesagten Eigenschaften der Prozessoren aufgrund der Leistungseinbußen nicht erfüllt wurden. Da der Mikrocode für jede Anweisung der CPU gilt, scheint dies eine Nutzungseinschränkung durch die hinzugefügte Lizenzklausel für den gesamten Prozessor zu sein, folgert Perens.
Nichts gelernt
Damit hat Intel mal wieder gezeigt, dass die Verantwortlichen seit Januar, der ersten Veröffentlichung der Meltdown- und Spectre-Lücken, nichts dazugelernt haben. Anstatt Kritik zu unterdrücken, sollte das Unternehmen zu den Fehlern stehen und seine Kunden möglichst umfassend über deren Asuswirkungen informieren.
Kommando zurück
Mittlerweile hat Intel zurückgerudert und die zusätzliche Klausel wieder entfernt. Warum diese überhaupt aufgenommen wurde bleibt unklar. Es kann nicht gänzlich ausgeschlossen werden, dass es ein Versehen war und der Text für eine Beta-Version verwendet wurde. Jedoch passt der Vorfall genau in das bereits bekannte Schema, sodass es wahrscheinlicher ist, das es darum ging, den Kunden einen Knebel zu verpassen. Jedenfalls zeigt sich wieder einmal, dass öffentliche Kritik zum Umdenken führt.
Intel hat weitere Microcode-Updates freigegeben, wie der aktualisierten Microcode Revision Guidance zu entnehmen ist. Dort listet Intel den jeweiligen Stand der Microcode-Updates zur Eindämmung von Meltdown und Spectre, den beiden CPU-Verwundbarkeiten, die Anfang des Jahres publik wurden. Änderungen seit der letzten Version des Papiers werden jeweils gelb hinterlegt. Braun hinterlegte Abschnitte sind noch in der Erprobungsphase.
Skylake abgedeckt
Anfang Februar hatte Intel überarbeitete Microcodes für Skylake-CPUs der Serien U, Y, H, S und U23e freigegeben, die sich gegen die Spectre Variante 2 richten. In der vergangenen Woche folgten dann korrigierte Codes für die Plattformen Apollo Lake, Cherry View und Bay Trail. Die Microcodes für die älteren Plattformen Broadwell, Haswell, Sandy Bridge und Ivy Bridge verblieben noch in der Beta-Phase.
Broadwell und Haswell nachgeliefert
Jetzt wurden die überarbeiteten Microcodes für Broadwell- und Haswell-CPUs aus dem Beta-Status entlassen und gelten als stabil. Damit verbleiben die Prozessorgenerationen Sandy Bridge und Ivy Bridge als letzte in der Beta-Phase. Sie stellen auch die ältesten Generationen dar, die Gegenmaßnahmen gegen die Verwundbarkeiten erhalten. Die Überarbeitung der Microcodes war unter anderem dadurch nötig geworden, da mit im Januar ausgelieferten Microcodes Broadwell- und Haswell-CPUs spontane Neustarts der Hardware auslösten und daraufhin von Intel zurückgezogen wurden.
Die Updates wurden bereits an Hersteller und OEMs ausgeliefert. Naturgemäß wird es eine Weile dauern bis diese als BIOS- oder Firmware-Updates bei den Endanwendern ankommen. Am schnellsten landen Intel Microcode-Updates wie auch die von AMD in der Regel bei Linux. Die meisten Distributionen liefern die Microcodes als Distributionspakete aus, die beim Start des Rechners in den Kernel geladen werden. Den Stand des jeweils erreichten Schutzes gegen die beiden Lücken können Linux-anwender mit dem Script Spectre-Meltdown-Checker überprüfen, das in einigen Distributionen, wie etwa bei Debian, auch als Paket im Archiv vorliegt. In der letzten Woche erhielt zudem auch OpenBSD Patches gegen Meltdown.
Intel rät seit gestern offiziell von der Verbreitung und Verwendung des aktuellen Microcodes mit der Versionsnummer 20180108 ab. Die Firmware enthält hauptsächlich Maßnahmen gegen Spectre in Variante 2 mit der Kennung CVE-2017-5715. Bereits am 11. Januar hatte Intel bekannt gegeben, dass die aktuelle Version des Microcodes auf einigen Plattformen Probleme verursachen könne. Auf den CPU-Plattformen Broadwell und Haswell wurden spontane Reboots sowie insgesamt instabiles Verhalten beobachtet.
Microcode gegen Spectre
Daraufhin zogen einige OEM-Partner ihre dementsprechenden BIOS-Versionen vom Download zurück. In den letzten Tagen gingen auch Linux-Anbieter diesen Weg. Hier bedarf es keiner BIOS-Version, der Microcode kann direkt beim Start des Rechners geladen werden. Red Hat machte, gefolgt von Ableger CentOS den Anfang, zog das Microcode-Paket zurück und verwies seine Kunden für weitere Aktualisierungen an die OEM-Partner. Auch Ubuntu zog die aktuelle Version zurück, ersetzte sie allerdings gegen eine ältere Version vom Juli 2017. Mittlerweile setzte auch Debian bei Unstable die Version zurück auf 20171117.
Torvalds kritisiert Intel
Seit gestern rät nun auch Intel offiziell von der Verwendung der Firmware ab. Intel gibt gleichzeitig an, das Problem mittlerweile gelöst zu haben. Eine neue Version der Firmware werde bereits von Industriepartnern getestet. Intel entschuldigte sich für die Störungen, die durch den Microcode verursacht wurden. Auch bei Linus Torvalds steht Intel derzeit in der Kritik. Dieser äußerte sich am Wochenende mit drastischen Worten zu einer Patch-Serie, die Intel für Kernel 4.16 eingereicht hat. Er kritisiert, dass die Patches »absoluten Müll« enthalten und den Kernel schützen wollen, wo dieser durch Retpoline bereits mit weit weniger Overhead geschützt sei.
Komplexe Materie
Im Nachhinein betrachtet ist er damit wohl etwas über das Ziel hinausgeschossen. Das zeigt deutlich die Komplexität der Sachlage auf, wenn selbst Torvalds nach einem kurzen Review die Fakten verwechselt. Dave Woodward, der ehemals für Intel arbeitete und die Patch-Serie einreichte, versucht die komplizierte Sachlage etwas verständlicher darzustellen.
