hikaru hat geschrieben: 
26.01.2018 10:13:54
NAB hat geschrieben: 25.01.2018 19:24:46
Auch auf einem SMP-System werden Prozesse pausenlos vom Prozessor genommen und danach wieder draufgesetzt ... also Kontextwechsel durchgeführt.
Ja, natürlich. Mir ist allerdings nicht klar, ob sich das unterbinden oder zumindest für eine Behandlung im Rahmen eines Spectre-Angriffs voraussagen lässt.
Eh, was? Mir ist nicht klar, worauf du hier hinaus willst. Ich wollte nur ein anschauliches Beispiel für Kontextwechsel bringen. Das hat mit Spectre erst mal gar nichts zu tun. Ich wüsste auch nicht, warum man Kontextwechsel unterbinden oder einen Prozessor-Kern-Wechsel dabei verhindern sollte. Darum erst mal zu den anderen beiden Themen:
hikaru hat geschrieben: 26.01.2018 10:13:54
Mir ist ehrlich gesagt noch nicht mal völlig klar, was eine Sprungvorhersage überhaupt ist. Was sie macht, glaube ich verstanden zu haben, aber wie sie implementiert ist weiß ich nicht. Ist das eine Art Firmware-Funktion? Oder ist das eine in Silizium gegossene Logik? Oder ist das etwas ganz anderes?
Was ich glaube zu wissen ist, das sie Register füllt, teils mit Werten die bei fehlerhafter Vorhersage normalerweise nutzlos sind, im Zuge der Angriffe aber gefährlich werden können. Und genau diese Register sind der wichtige Punkt, nicht die Sprungvorhersage selbst.
Stelle es dir als große Tabelle vor, in der Code-Schnipsel mit einem bedingten Sprung gespeichert werden, und in der letzten Zeile, wohin dieser Sprung das letzte mal geführt hat. Und dazu eine Vergleichseinheit, die den aktuell anliegenden Code mit sämtlichen Tabellenspalten gleichzeitig vergleicht um herauszufinden, wohin der aktuell anliegende Sprung das letzte mal geführt hat. Während der Prozessor nichts zu tun hat, weil er auf das Ergebnis der Bedingung wartet, rechnest du an dieser Stelle schon mal weiter ... auf dem echten Prozessor (du hast ja keinen anderen). Und auf den echten Registern. Dazu wird der Zustand der Register vorher gesichert (Backup). Wenn der Prozessor später herausbekommt, dass die Sprungvorhersage Blödsinn erzählt hat, dann stellt er den alten Zustand wieder her (Backup wird wieder eingespielt) und bessert die Tabelle der Sprungvorhersage nach. Dann ärgert er sich kurz, richtet sein Krönchen und macht weiter im Text.
Das ist soweit völlig korrekt, inklusive des Registerzugriffs. Was nicht so ganz korrekt ist, ist, dass der Prozessor während dieser spekulativen Code-Ausführung auch aus Speicher lesen darf, zu dem der aktuelle Kontext, also der aktuelle Prozess, eigentlich keinen Zugriff hat. Bisher hat man gesagt, das sei egal, denn die Ergebnisse dieses Leseszugriffs werden ja im Fehlerfall wieder verworfen - die stehen ja nur in den Registern, die mit dem alten Backup überschrieben werden.
Nun haben findige Forscher herausgefunden, dass du die Zeit, die der Prozessor mit dieser spekulativen Code-Ausführung verbringt, messen kannst. Aufgrund dieser Zeitmessung passiert dann das, was eigentlich nicht passieren sollte ... du kannst (statistische) Aussagen über Speicherinhalte machen, die du eigentlich nicht lesen darfst.
Wie die Sprungvorhersage dabei genau implementiert ist, ist irrelevant. Es sind ja zig Varianten sämtlicher Hersteller betroffen. Aber da du das Ding gerne möglichst performant haben möchtest, wirst du wohl zu viel Silizium greifen. Und es gibt nicht "den wichtigen Punkt", sondern es sind mehrere Punkte, die ineinandergreifen müssen, damit Spectre funktioniert.
hikaru hat geschrieben: 26.01.2018 10:13:54
Ich weiß nicht, ob du dich hier nur unpräzise ausdrückst, oder ob du dem gleichen Missverständnis aufsitzt, das ich schon bei Anderen beobachtet habe: Es gibt keine CPU- und HT-Kerne, oder auch "echten" und "virtuellen" Kerne.
Bei HT laufen zwei Prozesse gleichzeitig auf ein und demselben Kern. Das funktioniert, weil ein Kern im Prinzip wie das Fließband in einer Autoproduktion funktioniert.*
Nein. Was du da beschreibst, ist eine "Pipeline". Danach haben sie "superskalar" erfunden. Und dann dachten sie sich, hey, wenn wir eh schon mehrere Befehle gleichzeitig ausführen können, dann fehlt nicht mehr viel und wir können so tun als seien wir mehrere Prozessoren. Das ist ein zusätzlicher echter Kern, echte Hardware, keine "virtuelle". Naja, es ist der Rumpf eines Kernes, bestehend aus eigener Befehlspipeline und eigenen Registern. Die restliche Ausführungslogik teilt er sich mit dem anderen Kern. Also ist es doch kein echter Kern, wie wollen wir es nennen? So'n bisschen Kern? HT-Kern? Simultaneous-Mulitithreading-Doppel-Kern? Egal. Im Kontext wäre interessant, welche Teile der Sprungvorhersage die beiden sich teilen, und das weiß ich nicht. Muss ich auch nicht wissen. Das ist Intels Problem, wie sie das zurechtbiegen.
hikaru hat geschrieben: 26.01.2018 10:13:54
Was man hier bräuchte, wäre praktisch die "Negation des Gegenteils": Man müsste verhindern, dass ein anderer Prozess auf einem Kern dazwischenhüpft oder zumindest den Zustand speichern können bevor das passiert. Ob das geht weiß ich nicht.
Man kann aber zumindest hoffen, dass das nicht passiert und so eine Art Spectre-Lotterie spielen. Wie da die Gewinnchancen sind weiß ich nicht. Die von dir angesprochene Zuverlässigkeit ist dann aber natürlich im Eimer.
Du willst gar nicht verhindern, dass die Prozesse umherhüpfen. Das ist nur ein Nebenprodukt des Kontextwechsels und lässt sich unterbinden, wie du ja selber sagst. Erstens machst du dir ohne Kontextwechsel das Multitasking kaputt und zweitens ist es vermutlich eh egal, ob die Prozesse umherhüpfen, da die Sprungvorhersagetabelle vermutlich prozessorweit gilt - das spart Silizium.
Aber sieh es mal anders herum: Die Sprungvorhersagetabelle enthält gewissermaßen geheime Informationen über andere Prozesse - was sie berechnet haben und was dabei herausgekommen ist. Und nun gibt es eine Methode, diese geheimen Informationen auszunutzen. Man könnte einfach eine Sprungvorhersagetabelle pro Prozess einführen, das wäre eine "complete barrier for branch prediction". Vermutlich ist das nicht die Implementation, die Intel per Microcode-Update gebacken kriegt, aber so grob in die Richtung müsste es laufen. Ich
vermute, sie werden die Sprungvorhersagetabelle einfach bei jedem Kontextwechsel leerputzen, mit der entsprechenden performance penalty.
"Lotterie" spielen wir übrigens schon länger. Cache-Angriffe sind seit Jahren bekannt:
https://cyber.wtf/2016/06/16/cache-side ... y-problem/
Bisher haben sie mit hohem "Rauschen" zu kämpfen, die Qualität der gewonnenen Informationen ist dubios bzw. unzuverlässig. Meiner Meinung nach ist das nur eine Frage ausreichend guter Rauschunterdrückungssysteme bzw. statistischer Analysen. Wenn du beide Seiten kontrollieren kannst, kannst du über den Cache schon Video-Telefonieren:
https://www.youtube.com/watch?v=a9sGk7FtnYk
Bisher hat Intel das nicht gejuckt. Nun wurde erstmals ein recht schnelles und - was die Aufbereitung der gewonnenen Daten angeht - sehr unkompliziertes Verfahren vorgestellt. Plötzlich kippen sie alle aus den Puschen ... na sowas aber auch ...
P.S.: Da taucht doch grad wieder Meltdown auf meinem Radar auf:
https://security-tracker.debian.org/tra ... -2017-5754
Zumindest der proprietäre Nvidia-Grafiktreiber scheint auch betroffen zu sein. Wie mag es mit anderen proprietären oder Kernel-fremden Treibern stehen?
Never change a broken system. It could be worse afterwards.
"No computer system can be absolutely secure." Intel Document Number: 336983-001
