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.
9 Antworten zu „Intel lenkt ein bei Lizenz zu Microcode“
Klaus Meier
Und die DAUs werden weiterhin Intel kaufen, als gäbe es kein morgen.
Keine Ahnung, an was es liegt, ich habe es nicht jeden Tag getestet. Aber beim kompilieren von einem Paket (Gento) ist meine Kiste (Laptop/Intel) so gepeilt 25% langsamer als wie zu Beginn des Jahres. Das ist jetzt keine wissenschaftliche Studie und ich will auch nicht unterstellen, dass es nur am Microcode liegt.
Aber als erste Reaktion auf den eigenen Murks, von dem AMD nicht betroffen ist, erst mal die Benchmarks verbieten, das ist schon heftig. Ach, und nun ist es an die Öffentlichkeit gekommen und da rudert Intel auf einmal zurück?
Ok, es muss halt auch Anbieter für Personen geben, dich sich verarschen und abzocken lassen wollen.
Das Schlimmste ist, dass Intel an der ganzen Katastrophe noch verdienen wird. Ich vermute, im Silikon bereinigte Prozessoren werden weggehen wie geschnitten Brot. Ich bin seit vielen Jahren auch mit Intel unterwegs. Mein Grund zum damaligen Umstieg war das problemlose Handling der integrierten Grafik. Reicht für mich völlig aus. Ich kann Desktop-Nutzern mit Intel, bei denen nur vertrauendwürdige Menschen Zugriff auf die Hardware haben nur raten, genau zu schaun, ob sie die Microcodes auch brauchen. Bei den meisten Mitigationen ist das nämlich nicht der Fall.
An dieser Stelle mal ein ganz dickes Lob an Debian.
Bei keiner anderen Distribution wird so gründlich auf Lizenzen geschaut.
Eine gewiss aufwendige und langwierige Arbeit, die in ihrer Wichtigkeit allzu oft unterschätzt wird.
Dass debian das nicht aufgenommen hat liegt aber an deren policies.
Sowas landet dann halt in non-free, wenn es doch aufgenommen wird, weil irgendwelche Gründe es erfordern.
Ich errinnere mich noch gut an Ubuntu 5.04 und Fedora aus der selben Zeit, wo man per default nichtmal mp3s abspielen konnte.
So wird aus frei wieder restriktiv, aus der User-Sicht zumindest.
Der Kapitän hat doch letztes Jahr das sinkende Schiff verlassen. Das sagt doch alles. 😉
Aber ein dickes Lob an Debian, genauso habe ich mir das vorgestellt, wenn ein System funktioniert. Fehler passieren überall, aber hinschauen und zeigen was geht und was nicht, das ist wahre Stärke.
Meine Intel-CPU lief immer am besten mit Siduction und Debian Stable. Trotzdem wird jetzt AMD die Chance bekommen. Ich hoffe auf Aktualisierung der Sicduction-Images, denn der Start eines AMD Systems mit integrierter Grafik klappt im UEFI-Modus nicht. Im CSM-Modus konnte ich es mittels „startx“ aber booten.
In der Zwischenzeit hat sich ja einiges getan in Sachen AMD und Treiber.
> Es kann nicht gänzlich ausgeschlossen werden, dass es ein Versehen war
Ein c&p-Error ist durch den NDA-Passus, der so nie öffentlich verwendet wird, doch offensichtlich. Und daß keiner Korrektur liest.
Bei allem auch gerechtfertigten Intel-Bashing ist eher zu kritisieren, wieso der Debian-Maintainer für diese Pakete á la „vielleicht merken sie’s ja selbst“ wochenlang nichts gesagt hat – wenn es denn tatsächlich so gewesen sein sollte.
Schreibe einen Kommentar