AMDs Patch für den „Division by Zero“-Fehler in Zen 1 war nicht das A und O, was das Unternehmen wollte. Das Unternehmen war zwar schnell bei der Veröffentlichung eines Patches, vielleicht aber etwas zu schnell: Laut Michael Larabel von Phoronix hat der AMD-Linux-Ingenieur Borislav Petkov einen neuen Patch veröffentlicht, der ein Problem mit der ursprünglichen Lösung (ebenfalls von ihm veröffentlicht) behebt ). Dies ist nur ein weiterer Datenpunkt zu den Schwierigkeiten, sich gegen mögliche Angriffsvektoren abzusichern.
Der ursprüngliche Fehler bezog sich darauf, wie Zen 1 unter bestimmten Umständen eine Ganzzahlberechnung dividiert durch 0 verarbeitete: Den Ergebnissen zufolge bestand die Möglichkeit, dass AMDs CPU „veraltete Quotientendaten“ in ihren Registern behielt, selbst nachdem der Vorgang vollständig abgeschlossen war, was möglich war Geben Sie Angreifern ein Fenster, um vertrauliche Informationen abzurufen. Die ursprüngliche Problemumgehung bestand darin, vor der Rückkehr vom #DE-Ausnahmehandler eine abschließende „Dummy-Division 0/1“ durchzuführen. Die Idee ist einfach: Alle noch gespeicherten alten Daten würden nach Abschluss der 0/1-Division (deren Ergebnis immer, nun ja, Null ist) gelöscht.
Das Problem bei dieser Lösung bestand, wie Petkov erklärte, darin, dass der spekulative Ausführungsangriff zum Zeitpunkt des Inkrafttretens der Sicherheitsmaßnahmen bereits zu weit fortgeschritten wäre: Auf dem AMD-Teiler befanden sich bereits einige alte Datenmengen, an die die Angreifer gelangen könnten at, bevor die Dummy-Division einsetzte. Wie Petkov es erklärte, erzwingt seine neue Lösung nun dieselbe Division in einer Reihe von Szenarien:
„Anfangs dachte man, dass eine harmlose Aufteilung im #DE-Handler dafür sorgen würde, dass keine alten Daten aus dem Teiler durchsickern, aber als der Fehler auftritt, sind die Spekulationen bereits zu weit fortgeschritten und solche Daten könnten es bereits sein wurden von jüngeren Betrieben genutzt.
Führen Sie daher die harmlose Division bei jedem Verlassen des Userspace durch, damit der Userspace keine potenziell alten Daten aus Integer-Divisionen im Kernel-Space sieht.
Machen Sie dasselbe auch vor VMRUN, um zu verhindern, dass Hostdaten auch in den Gast gelangen.
Es war bereits ein arbeitsreicher Monat in Bezug auf Schwachstellen im CPU-Bereich, wobei sowohl AMD als auch Intel von Offenlegungen betroffen waren. Von der extremeren Downfall-Schwachstelle von Intel (die Skylake bis Tiger Lake/Rocket Lake betrifft) bis hin zu den SQUIP- und Inception-Schwachstellen von AMD (und der jetzt wieder behobenen „Divide by Zero“-Schwachstelle haben die Forscher hart gearbeitet. Es ist immer noch nicht vergleichbar mit die geschichtsträchtige Geschichte der Meltdown- und Spectre-Tage (obwohl diese neuen Fehler auch mit Schwachstellen bei der spekulativen Ausführung zusammenhängen). Unter spekulativer Ausführung versteht man die Art und Weise, wie moderne CPUs versuchen, Berechnungsschritte vorwegzunehmen, bevor sie überhaupt notwendig werden, damit die erforderlichen Daten vorhanden sind bereits verfügbar für den Fall, dass es zur Ausführung aufgerufen wird. Obwohl die Korrekturen einiger dieser Schwachstellen zu (manchmal schwerwiegenden) Leistungseinbußen geführt haben, ist es zumindest ein gutes Zeichen dafür, dass AMDs 0/1-Dummy-Abteilung keinen zusätzlichen Overhead mit sich bringt.
Gleichzeitig ist es ermutigend zu sehen, dass der Sicherheitspatch zumindest in diesem Fall nicht in einer Art „Einstellen und Vergessen“-Manier herausgegeben wurde – mit der Art Karussell, wie es die Blue-Team-Experten tun tragen müssen, hätte es auch andere Wege geben können (man hätte davon ausgehen können, dass der mangelhafte Patch vollständig funktioniert, was die Tür für weitere Hacking-Erkundungen in der Zukunft offen ließ (mit welchen Auswirkungen diese auch immer haben könnten).