Das Privilege Level geprüft werden, ist Kanon. Sonst würden sie gar nicht funktionieren. Aber muss man sie vor der eigentlichen Berechnung prüfen oder reicht eine Prüfung vor Freigabe des Ergebnisses? Die bisherigen Sicherheitsüberlegungen setzten nur letzteres voraus: War eine spekulative Berechnung unnötig, illegitim oder ist aus irgend einem anderen Grund nicht verwertbar, gibt es einen Rollback zum vorhergehenden Systemzustand und es gibt keine Spuren, das überhaupt eine Berechnung stattgefunden hat. Dieses Verfahren galt sowohl auf Seiten der CPU- als auch Software-Entwickler als absolut sicher. Das die physischen Prozesse deutlich weniger klar sind als dieser nominellen Ablauf der Systemlogik wurde ignoriert.
Ich glaube aber nicht, dass das eine bewusste Entscheidung war – eben weil die gesamte IT-Welt nur in deterministischen Abläufen denkt und selten ein Bewusstsein für die physischen Vorgänge eine Ebene tiefer hat. Mein Tip: Die Cache-Designer haben daran gearbeitet, möglichst alle Prozesse zu beschleunigen, die Entwickler der Sprungvorhersage haben daran gearbeitet, möglichst effizient Instruktionen zu beschleunigen und alle Sicherheitsfragen wurden beim OoO-Management angesiedelt, weil dieses ja als Gate-Keeper "alle" Wege bewacht, über die Prozesse an Informationen gelangen. Dummerweise hat die Scheduler-Entwickler aber nie einen Grund, sich mit der Arbeitsweise des L3-Caches oder den Möglichkeiten der Sprungvorhersage auseinanderzusetzen...
Das war das TL;DR
.gif "sm_B-) :-)")
Welche Passagen waren das? (Und wieso?) Dann kann ich sehen, ob ich die fürs Print-Heft besser hinbekomme
Letzteres ist immer einfacher, es fällt aber gegebenenfalls auf, wenn die physische Firewall mit Dynamit durchtunnelt.
Zur eigentlichen Frage: Soweit ich es verstehe, sind Prozesse auf physisch distinkten CPUs voreinander sicher. Wenn also fest ein ganzer Prozesser einer VM zugewiesen wird, sollten Spectre-Angriffe aus anderen VMs auf diese unmöglich sein. Allerdings nutzt man Virtualisierung ja normalerweise, wenn die Gleichung 1 System = 1 CPU nicht aufgeht und ich weiß nicht, in wie weit die Sprungvorhersagen einzelner Kerne einer CPU untereinander Informationen austauschen. Zumindest AMD spricht ja gerne von intelligenten Netzwerken. Definitiv unsicher wird das Ganze, wenn die VMs von Kern zu Kern springen können. (Allerdings dürfte der Vorgang nutzlos langsam werden, wenn diese Wechsel zu selten stattfinden.)
Daran ändern auch Container nichts, vermutlich nicht einmal vollständige Verschlüsselungen. Das Perfide an Spectre ist, dass die eigentliche Attacke nur innerhalb der Ausführungseinheiten stattfindet – also da, wo Befehle und Daten unkodiert und ungeschützt vorliegen müssen, weil mit ihnen gearbeitet wird. Der Angreifer muss also außer der Zielapplikation keinen anderen Aspekt des Systems kennen – ob beispielsweise ein gängiger Webserver nativ auf dem komprimitierten Prozessor läuft oder in einem Container in einer VM in einem doppelt und dreifach überwachten Host, ist egal. Der Angriff arbeitet ohnehin nur mit einigen wenigen Zeilen Code des Ziels.
