News Sicherheitslücke in Zen 3: Predictive Store Forwarding birgt Risiken wie Spectre

[Sun_set_1]

Mittlerweile juckt es keinen mehr so recht ob da was neues kommt und die Performanceverluste werden über einen Kamm geschert.

Egalitätseffekt. Wann hast das letzte mal gehört, dass in Syrien nen Krankenhaus bombardiert wurde?
Passiert trotzdem nicht seltener, eher häufiger.

 

[N3utr4l1s4t0r]

@SV3N
Hier sind mit "Loads" eher Ladevorgänge statt Lasten gemeint. Es geht darum Daten nicht in den Speicher schreiben zu müssen, sondern direkt weiter zu verwenden.

 

[TheJoker]

[...] Abhängigkeiten zwischen Lasten („Loads“) und Speichervorgängen („Stores“) vorherzusagen.

In dem Kontext sind mit "Loads" meines Erachtens nach wohl eher Ladevorgänge (Speicherzugriffe) gemeint, als Lasten.
Edit: Verdammt!

Soweit ich das verstanden habe, wird der Fehler nur für VMs schlagend.

Sandboxing/Isolation wird z.B. auch ganz massiv von Webbrowsern betrieben, um JavaScript auszuführen. Und die benutzen wir wohl alle

Ich komme mehr und mehr zu der Schlussfolgerung, dass im Grunde die komplette spekulative out of order Vorhersage sicherheitstechnisch nicht so geil ist..

Komplett ohne OOE wären viele Programme vermutlich massiv langsamer, bzw. müsste viel mehr Assembly von Hand getunt werden.

 

[deineMudda]

Ich komme mehr und mehr zu der Schlussfolgerung, dass im Grunde die komplette spekulative out of order Vorhersage sicherheitstechnisch nicht so geil ist..

Du kannst gerne darauf verzichten, darfst dich dann aber nicht wundern, wenn die Prozessoren nur noch so schnell wie ein Atom sind. Das ist bei out of order eben das Problem: Man opfert die Sicherheit für Geschwindigkeit. Eine Lösung für das Problem hat noch kein Hersteller gefunden, daher halte ich es für wahrscheinlich, dass es auch keine Lösung mehr geben wird. Hier muss man sich wohl entscheiden.

 

[David_B]

So wie es hier aussieht, wurde dieses Problem AMD-intern gefunden. Bei Intel könnte sowas vermutlich nicht passieren.

Intel kann es sich halt leisten andere damit zu beauftragen hier bei uns an der TUGraz profitieren wir natürlich von dem Geld 😆

 

[Tanzmusikus]

Mich würde interessieren, ob und in wie weit diese Verluste auch Video-Spiele betreffen. 🤓

 

[GrumpyCat]

Das ist bei out of order eben das Problem: Man opfert die Sicherheit für Geschwindigkeit. Eine Lösung für das Problem hat noch kein Hersteller gefunden

Ist das so? Ich kenne jetzt nicht bei allen Lücken die Details, aber zumindestens teilweise kann man die Nebeneffekte ja rückgängig machen. Hat sich bei einer Speculative Execution herausgestellt, dass sie wegen Speicherschutz eigentlich nicht zulässig war? Alle im Zuge der Bearbeitung in den Cache geladenen Daten invalidieren, um Timing-Attacken zu unterbinden². Und so weiter.
Was machen denn die neueren Hardware-Mitigations?

²klar könnte man dann durch "auf der anderen Seite aus dem Cache gefallene Daten" wiederum Rückschlüsse ziehen, aber das ist ungleich aufwendiger als der ursprüngliche Angriff.

 

[Herdware]

Ist das so?

Ich (als Laie) verstehe das so, dass man durch Out-of-Order, spekulative Befehlsausführung und Speicheroperationen usw. potentielle Angriffsmöglichkeiten schafft, die bei simpleren In-Order-CPUs erst gar nicht existieren würden.
Wenn die Entwickler der komplexeren OoO-CPUs nichts übersehen und alles richtig absichern, dann ist trotzdem alles in Ordnung. Aber Menschen (und wahrscheinlich auch automatischen Entwicklungs- und Kontroll-Tools) passieren halt Fehler.

So gesehen ist es also schon ein in Kauf nehmen von potentiellen Risiken für mehr Leistung, auch wenn natürlich nicht bewusst Sicherheitslücken eingebaut werden.

(Das ist auch einer der Gründe, warum ich für den Atomausstieg bin. Es mag theoretisch möglich sein, ein 100% sicheres Atomkraftwerk zu bauen. Aber Fehler passieren und Dinge werden übersehen. Also besser erst gar keine AKWs mehr betreiben und so das Risiko komplett vermeiden, halbe Kontinente dauerhaft unbewohnbar zu machen. 😉 )

 

[TriggerThumb87]

1. 0,5% Leistungsverlust
2. Eigenes Sicherheitsteam macht darauf aufmerksam

Währenddessen verneint Intel Lücken, die andere finden, und je nach Aufgabenstellung fressen Fixes 90% Leistung. Aber die CPUs in der Pipeline schön weiterverkaufen die nächsten Jahre!

Als jemand, der herstellerunabhängig kauft, freue ich mich über den Konkurrenzdruck!

 

[PietVanOwl]

Scheint wohl wieder so eine sehr theoretische Lücke zu sein, eh man die ausgenutzt bekommt...
Der Perfomance Verlust wenn man PSF aussschaltet ist ja auch zu vernachlässigen.
100 Prozentige Sicherheit gibt es eh nicht im IT Bereich.
MFG Piet

 

[IBISXI]

Anfangs war der Aufschrei groß als die Sicherheitslücken bei Intel bekannt wurden.

Ja, das ganze ist etwas abgeflaut.

Mittlerweile juckt es keinen mehr so recht ob da was neues kommt und die Performanceverluste werden über einen Kamm geschert.

Ich hatte mir das letztes Jahr mal angesehen.

Bei Intel waren 247 Lücken gemeldet:
https://www.cvedetails.com/vulnerability-list/vendor_id-238/Intel.html

Bei AMD 16:
https://www.cvedetails.com/vulnerability-list/vendor_id-7043/AMD.html

Respekt vor dem, der hier noch den Überblick hat.

 

[KWMM]

Das niemand absichtlich sowas einbaut versteht sich von selbst.

Ach ja, ist das so ?

 

[Sun_set_1]

Komplett ohne OOE wären viele Programme vermutlich massiv langsamer, bzw. müsste viel mehr Assembly von Hand getunt werden.

Macht die Schlussfolgerung nicht weniger Falsch und war damals auch das Fazit des Spectre Entdeckers. Grundsätzlich lässt sich jede spekulative Ausführung manipulieren. Da das Spekulieren auf historischen Inputdaten basiert. Fälscht man also den Input, verfälscht man den Output.

Das Beispiel war damals mit Salz und Zucker im Schrank. Egal ob in jede Suppe Salz gehört.

Wenn ich einen Kochanfänger nehme, ihn neben mich stelle und sage: Lerne vom Zuschauen.
Und dann jedes mal in jeder Suppe Zucker hinzufüge, welche Zutat wird der Azubi wohl beim Kochen seiner ersten Suppe aus dem Schrank holen?

Und genauso kann man jede spekulative Ausführung manipulieren.

 

[HyperSnap]

Da AMD mehr im kommen ist werden sicher auch mehr nach was suchen.
Würde mich ned wundern wenn das mehr wird^^

 

[karl_laschnikow]

Das hatte ich erwartet das wieder neue Lücken auftauchen. Egal ob AMD oder Intel.

Was mich überrascht, ist das AMD selber es meldet. Heißt entweder sie schauen ständig wo noch Lücken sein könnten oder sie haben die Lücke selbst nicht erkannt und erhielten einen Hinweis.

Es ist glaube ich gang und gebe das Forschergruppen welche Lücken finden dann die Hersteller informieren und eine Deadline setzen. Sollte der Hersteller sich nicht innerhalb der Deadline äußern melden sich dann die Gruppen.

Einen Spieler werden diese paar 0,% nicht interessieren. Das hat man bei Meltdown gesehen.
Das Bsp mit bis zu 90% bei Intel ist mMn extremes Cherry Picking und interessiert die wenigsten.
So wird es hier auch sein.

 

[mibbio]

Ich komme mehr und mehr zu der Schlussfolgerung, dass im Grunde die komplette spekulative out of order Vorhersage sicherheitstechnisch nicht so geil ist..

Nur hat der Wechsel von "in order" zu "out of order" Architekturen inkl. dem ganzen speculative Kram mit den Meisten Leistungsschub gebracht. Braucht man ja nur mal die ersten Netbook angucken, deren häufig genutzen Atom 230 oder Atom 330, noch mit "in order execution" arbeiten. Die sind selbst hochgerechnet auf Takt & TDP von Desktop-CPUs arschlahm im Vergleich zu den Core-i Modellen aus der gleichen Zeit.

 

[PuscHELL76]

wo finde ich diese Anleitung ?

 

[FrozenLord]

Mal schauen, wie lange es dauert, bis das Sicherheitsproblem doch softwareseitig gepatcht wird. Bei Intel hat es nach Bekanntwerden zu lange gedauert und wie man am Ende weiß, war der Leistungsverlust unbedeutend.

Scheinbar haben wir unterschiedliche Definitionen von "unbedeutend".
Für mich ist unbedeutend bei niedrigen Prozentpunkten angesetzt - bis ca. 3% gehe ich da mit.
Laut Phoronix, die als einer der wenigen das Leistungsgefälle durch die ganzen Sicherheitslücken angeschaut haben, stehen aber rund 25% (bei einem 7700K bzw. 8700K) auf dem Spiel:
https://www.phoronix.com/scan.php?page=article&item=3-years-specmelt&num=9

Selbst ein 9900K kommt auf mehr als 23% Leistungseinbuße.
Und das sind dann doch Dimensionen in der Leistung, die Intel von einer Generation zur nächsten nicht liefert.
In vielen Spielen ist ein Upgrade von 8600K auf 9900K weniger wert, als diese Lücken an Leistung vernichten.
Siehe beispielhaft:
https://www.anandtech.com/show/13400/intel-9th-gen-core-i9-9900k-i7-9700k-i5-9600k-review/17

Da ich einen 9700F nutze bin ich Intel geschädigt und freue mich, dass AMD es nicht nur technisch besser zu machen scheint.

 

[Che-Tah]

wo finde ich diese Anleitung ?

Ist der 1. Link in der News.

https://www.amd.com/system/files/documents/security-analysis-predictive-store-forwarding.pdf
Nur für Linux.

 

[Johannes125]

Hätte sich herausgestellt, dass das Deaktivieren des kritischen Features sagen wir mal 20-30% Leistung kostet und die neuen Zen3-CPUs damit hinter die Intel-Konkurrenz zurückfallen würden, könnte ich mir vorstellen, dass auch AMD erstmal schweigt und intern alle Hebel in Bewegung setzt, um irgendeine weniger fatale Maßnahme zur Schadensbegrenzung zu finden, und man erst danach selbst an die Öffentlichkeit gehen will.

Ist ein gefährlicher Drahtseilakt.
Würde man es verheimlich so würde man weiterhin eine guten Umsatz und generell die Shareholder glücklich machen im ersten Moment.

Aber ein großteil der Shareholder sind nicht dumm und schauen nur auf Rendite und Absatz und co.. Es wird auch auf ein gesundes Wachstum/Gewinn geachtet. Daher würde bei einen Skandal die Shareholder die Unternehmensführung noch stärker abstrafen und zusätzlich würden es denen noch mahr Verluste verursachen als Gewinn aus dem Umsatz bevor bekannt werden.
Auch darf man nicht vergessen AMD steigert von Jahr zu Jahr die Absätze im HPC Bereich. Ein Skandal in diesem Bereich würde dazuführen, dass die schon geringeren Absätze wieder komplett wegbrechen und man weißt, dass dieser Bereich einer der Umsatzstärksten ist.
Ich sehe durchaus mehr Vorteile als nach Nachteile soetwas publik zumachen.