Avatar von /mecki78
  • /mecki78

mehr als 1000 Beiträge seit 03.07.2004

Re: Das Spectre Problem lässt sich nicht per Patch beheben!

7eggert schrieb am 04.05.2018 21:53:

Stimmt, aber ich denke, das wären das nur wenige Maschinenworte, also entsprechend den wenigen Instruktionen, die spekuliert werden, maximal jeweils zwei (misaligned access).

Das meinte ich mit, wenn man ihn groß genug macht. Wie viel Instruktionen eine CPU, genauer ein Kern (von mir aus auch ein virtueller Kern, Stichwort HyperThreading) maximal spekulativ ausführt, das ist ja begrenzt, da gibt es eine harte Obergrenze, die wahrscheinlich sowieso nur ganz selten überhaupt mal erreicht wird. Nimmt man also diese Obergrenze mal die Anzahl der Cores mal die maximale Menge an Speicher, die bei irgend einer Operation überhaupt aus dem Speicher geholt oder in den Speicher geschrieben werden kann, dann müsste das einen Wert ergeben, der in der Praxis immer sicher ist, da die CPU real immer unter diesen Wert bleiben wird. Und es stimmt, wir sprechen hier sicher eher nur von Bytes, bzw. wenigen Kilobytes, preislich fällt das gar nicht in's Gewicht. Darin sehe ich nicht das Problem.

Das Problem ist, dass es eine Logikeinheit geben muss, die im einen Fall das Rollback Log verwaltet und im anderen Fall das Umschalten zwischen Cache und Shadow Cache bzw. das Mapping zwischen den beiden. Außerdem muss sie im ersten Fall den eigentlichen Rollback durchführen, wenn ihr gesagt wird sie soll alles verwerfen bzw. im zweiten Fall dafür sorgen das Shadow Cache aufzuräumen (indem entweder die Mappings nur einfach alle vergessen werden oder aber eben zuerst ein Sync mit dem echten Cache erfolgt, wenn diese Änderungen behalten werden sollen). Das ist zwar nicht super komplex was sie tun muss, aber eine derartige Einheit existiert derzeit überhaupt nicht.

Natürlich hat Intel hier noch mehr Möglichkeiten. Tatsächlich geht es auch ohne so eine Einheit und ohne zusätzlichen Cache Speicher, z.B. wenn die CPU Instruktionen explizit Rückabwickeln kann und diese Rückabwicklung in Zukunft dann auch auf das Cache durchschlägt, was aktuell eben nicht der Fall ist. Die gerade ausgeführten Anweisungen liegen sowieso im Instruktionscache der CPU und das kann die CPU theoretisch einfach wieder Rückwärts zurück gehen, um den Effekt einer jeden Anweisung umzudrehen. Ich fürchte nur, dass wäre noch viel langsamer als meine anderen beiden Vorschläge, weil hier wirklich Anweisung für Anweisung abgearbeitet werden muss, während im anderen Fall manchmal einfach alles auf einmal verworfen werden kann (quasi in einer einzigen Operation). Das ganze erinnert ein bisschen an Jounaling Dateisysteme oder Datenbank Transaktionen. Da geht es zwar eher darum sicherzustellen, dass mehrere Änderungen atomar oder gar nicht durchgeführt werden, aber es läuft letztlich auf die selben Mechanismen hinaus, denn die Anweisungen und die Cache Änderungen bilden auch einen Einheit und in Zukunft müssen beide entweder atomar zugelassen werden oder atomar verworfen werden und nicht irgendwas dazwischen so wie heute, wo die Auswirkungen der Transaktionen verworfen werden, ihre Cache Änderungen aber dummerweise erhalten bleiben.

/Mecki

Bewerten
- +