Kein Spectre Schutz

[/mecki78]

Zwar haben die alle Microcode Patches schon ab Werk drauf, aber diese schützen nicht wirklich vor Spectre, da sie nur neue Befehle einführen mit denen theoretisch ein Compiler Code vor Spectre schützen kann, falls er gefährdete Stellen erkennt und dort auch diese neuen Befehle dann verwendet. Nur das ist eben leider ein ganz dickes falls. Vergleichbar mit einem echten Hardwareschutz vor Spectre, wo es egal ist mit welchen Compiler man baut und was für CPU Befehle der erzeugt, ist das aber natürlich nicht. Und gegen zukünftige Spectre Angriffe, die noch gefunden werden (und da werden ganz sicher noch welche gefunden) schützt das natürlich auch nicht, weil für die braucht man dann wieder ein Microcode Update, ggf. wieder neue Befehle, wieder neue Compileranpassung und darf dann wieder sämtlichen Code neu bauen und Daumen drücken, dass der Compiler alle Stellen findet.

Intel verkauft hier nach wie vor eine fehlerhaftes Produkt und sie wissen, dass ihr Produkt fehlerhaft ist, aber sie verkaufen es dennoch und ohne den Kunden auf den Fehler hinzuweisen. Dass Software diesen Fehler dann ggf. umgehen kann macht das Produkt nicht weniger Fehlerhaft. Wenn Intel mal wieder eine CPU mit FPU Bug herstellen würde, dann kann Software das auch umgehen, indem sie ggf. bestimmte FPU Berechnungen dann nicht auf der FPU durchführt, was Performance kostet aber zu korrekten Ergebnissen führt, aber auch da würde ja niemand sagen, dass die CPU nicht fehlerhaft ist, nur weil Software in der Lage ist diesen Fehler zu umgehen, oder?

/Mecki

[Ford Prefect]

Alle Prozessoren sind fehlerhaft und benötigen Korrekturen sowohl im Microcode als auch auf Betriebssystemebene. Schon sehr lange. Auch von der Konkurrenz (z.B. viele erste Ryzen-Modelle verursachen Abstürze mit älteren Linux-Kernen).

Wenn Patches notwendig sind, die zu gravierenden Performanzeinbußen führen, dann ist das sicherlich kritisch zu sehen, bei bereits verkauften Prozessoren. Werden die Prozessoren von vornherein so ausgeliefert, dann ist ja die beworbene Performanz unter den fehlerkorrigierten Bedingungen bekannt und der Kunde kann sich informieren und entscheiden.

Ich sehe hier gar kein Problem, viel wichtiger ist, dass in Zukunft keine neuen Sicherheitslücken entstehen, hierzu soll sich Intel ruhig Zeit lassen, statt jetzt voreilig schnelle Lösungen auf Hardwareebene zu produzieren, die dann evtl. auch nicht beständig sind.

[yumiko]

Ford Prefect schrieb:
--------------------------------------------------------------------------------
> Alle Prozessoren sind fehlerhaft und benötigen Korrekturen sowohl im
> Microcode als auch auf Betriebssystemebene. Schon sehr lange. Auch von der
> Konkurrenz (z.B. viele erste Ryzen-Modelle verursachen Abstürze mit älteren
> Linux-Kernen).

Ja, deshalb hat die auch AMD gegen neuere Revisionen umgetauscht - KOSTENLOS.
Wie sich das gehört.
Intel geht da eher den VW-Weg.

[/mecki78]

Ford Prefect schrieb:
--------------------------------------------------------------------------------
> Alle Prozessoren sind fehlerhaft und benötigen Korrekturen sowohl im
> Microcode als auch auf Betriebssystemebene.

So kann man das nicht formulieren. Korrekt muss das lauten: Alle Prozessoren können Fehler aufweisen und benötigen dann ggf. Mikrocodeupdates und/oder spezielle Anpassungen auf Betriebssystemebene, um diese Fehler zu umgehen.

Es ist aber etwas anderes, ein Produkt zu verkaufen, das keine bekannten Fehler aufweist, und wo man dann hinterher eben doch welche findet, die man jetzt irgendwie umgehen muss und ein Produkt zu verkaufen, wo man schon lange weiß, dass dieses Produkt Fehler aufweist, schwerwiegende Fehler, und dazu auch noch solche, die sich nicht so einfach durch irgend ein Update umgehen lassen.

> Werden die Prozessoren von vornherein so ausgeliefert, dann
> ist ja die beworbene Performanz unter den fehlerkorrigierten Bedingungen
> bekannt und der Kunde kann sich informieren und entscheiden.

Da hast du was falsch verstanden, es geht hier nicht um Peformance. Das Problem ist nicht, dass durch den Spectre Fix Performance verloren geht, das Problem ist, dass es eine 50%tige Chance gibt, dass der Spectre Fix gar nichts fixed und beliebiger Code immer noch durch Spectre angreifbar bleibt, auch nachdem man den Fix eingespielt hat. Denn der Spectre Fix verlässt sich hier auf die Fertigkeiten der Compiler; wer also keinen Compiler mit Spectre Fix nutzt, dem sein Code bekommt grundsätzlich keinen Spectre Schutz, auch nicht mit Microcodeupdate. Und wer so einen Compiler nutzt, der muss darauf hoffen, dass der Compiler durch Spertre angreifbarer Stellen erkennt und das ist aber bei jeder zweiten Stelle aktuell gar nicht der Fall.

Und informieren kann sich der Kunde nur, wenn du ihm auch die notwendige Info lieferst. Also wo genau steht in der Produktbeschreibung der CPU:

"Aufgrund von Seitenkanalangriffen über das Cache ist es möglich, das Code den Inhalt von Speicherseiten auslesen kann, auf die er eigentlich gar keinen Zugriff haben dürfte. Dieses lässt sich nur durch die Verwendung spezieller CPU Anweisung verhindern, wobei Intel keinerlei Garantie dafür übernimmt, dass Compiler diese auch verwenden."

Und jetzt kann ein Kunde sagen "Ah, okay, aber Sicherheit ist mir extrem wichtig, also lieber greife ich zu einer anderen Lösung, die dieses Problem nicht hat, auch wenn sie teurer, langsamer oder sonst irgendwie minderwertiger ist". So aber wird dem Kunden eine CPU verkauft, die ein vermeintlich sicheres Speicherzugriffskonzept hat, das aber in der Praxis nicht sicher ist, weil man es leicht aushebeln kann und diese Tatsache ist aber Intel bekannt und Intel selber hat nichts dagegen unternommen, außer dir Werkzeuge vor die Füße zu werfen und zu sagen "Hier, repariere's doch selber".

/Mecki



2 mal bearbeitet, zuletzt am 30.08.18 15:16 durch /mecki78.