Intel lenkt ein

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.

Verwandte Themen

Intel Microcode für Debian Stable aktualisiert
views 195
Screenshot: ft   Für Debian GNU/Linux 9 »Stretch« steht ein aktualisierter Intel Microcode zum Schutz vor Angriffen durch die Sicherheitsl...
Intel wegen Meltdown und Spectre in der Kritik
views 274
Bild: Penguins |  Quelle: pxhere | Lizenz: CC0   Der Linux-Kernel-Entwickler Greg Kroah-Hartman übte in dieser Woche in Vancouver in eine...
Intel kündigt halbherzige Fixes für Whiskey Lake a...
views 175
Bild: Public Domain Intel hat vor wenigen Tagen die neue Prozessor-Reihe Whiskey Lake vorgestellt, ließ dabei aber völlig unerwähnt, dass die für ...
Debian schließt Intel-Lücken
views 278
Screenshot: ft Debian weist im aktuellen Security Advisory DSA-4279-1 auf die Schließung der kürzlich unter der Bezeichnung Foreshadow beziehungsw...
Intel bestätigt Gerüchte um diskrete Grafikkarte
views 400
        Bild: Graphikarte mit Intel i740 | Quelle: Wikimedia | Lizenz: GFDL   In einem kurzen Promotion-Vi...

Beitrag kommentieren

Alle Kommentare
  • Klaus Meier

    24.08.2018, 13:10 Uhr

    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.

    • Ferdinand Thommes

      24.08.2018, 13:17 Uhr

      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.

  • tuxnix

    24.08.2018, 13:30 Uhr

    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.

    • Ferdinand Thommes

      24.08.2018, 13:45 Uhr

      Das kann ich nur unterschreiben. Red Hat, Suse und Gentoo haben trotz der Lizenz veröffentlicht.

  • Nils S.

    24.08.2018, 14:31 Uhr

    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.

    • Ferdinand Thommes

      24.08.2018, 14:33 Uhr

      Intel-Microcode ist immer in non-free, das geht garnicht anders, da proprietär.

  • carlos

    24.08.2018, 21:56 Uhr

    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.

    • Ferdinand Thommes

      24.08.2018, 22:10 Uhr

      Das lässt sich vermutlich am besten im IRC #siduction-de klären. Am besten nach towo fragen, der baut unsere Kernel und nutzt selbst AMD-Grafik.

  • axt

    25.08.2018, 18:10 Uhr

    > 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.