Reptar

 (lock.cmpxchg8b.com)
2 Punkte von GN⁺ 2023-11-15 | 1 Kommentare | Auf WhatsApp teilen

Entdeckung eines CPU-Mysteriums

  • Wenn du dich für Fehler interessierst, die im Inneren moderner CPUs auftreten können, solltest du weiterlesen.
  • Wenn du schon einmal x86-Assembly geschrieben hast, bist du wahrscheinlich mit dem Befehl rep movsb vertraut, der zum Verschieben von Speicher verwendet wird.
  • Man setzt Quelle, Ziel, Richtung und Zähler, und der Prozessor kümmert sich um alle Details.

Interpretation von Befehlspräfixen

  • Eine der Besonderheiten von x86 ist, dass die Befehlsdekodierung im Allgemeinen sehr flexibel ist.
  • Selbst wenn man Präfixe verwendet, die bedeutungslos sind oder mit anderen Präfixen kollidieren, werden sie meist ignoriert.
  • Compiler können überflüssige Präfixe verwenden, um die gewünschte Ausrichtungsgrenze zu erreichen.

REX-Präfix

  • i386 hatte 8 allgemeine Register, sodass 3 Bit ausreichten, um ein Register anzugeben.
  • x86-64 führte 8 zusätzliche allgemeine Register ein, wodurch mehr Bits erforderlich wurden.
  • Das REX-Präfix erlaubt es dem folgenden Befehl, sich zusätzliche Bits zu leihen, und ermöglicht so die Kodierung von 16 allgemeinen Registern.

Kodierungsregeln

  • Das REX-Präfix vergrößert den verfügbaren Raum zur Kodierung von Operanden.
  • Unnötige oder redundante Präfixe werden bei x86 größtenteils ignoriert.
  • Der Befehl rex.rxb rep movsb hat keine Operanden, daher haben die REX-Bits keine Bedeutung, und der Prozessor ignoriert das REX-Präfix.

Fast Short Repeat Move (FSRM)

  • FSRM ist ein neues Feature, das mit Ice Lake eingeführt wurde und die Nachteile von ERMS behebt.
  • Bei ERMS besteht der schwierige Teil effizienter String-Moves darin, den Puffer auszurichten und den jeweils breitestmöglichen Speicherzugriff zu verwenden.
  • FSRM zielt darauf ab, kurze Strings mit bis zu 128 Byte schneller zu verschieben.

Entdeckung

  • Mithilfe der Prozessor-Verifikationstechnik Oracle Serialization wurde geprüft, ob zwei Formen zufällig erzeugter Programme denselben Endzustand haben.
  • Im August entdeckte die Verifikations-Pipeline einen Fall, in dem das Hinzufügen eines redundanten rex.r-Präfixes zu einer FSRM-optimierten rep movs-Operation zu unvorhersehbaren Ergebnissen führte.
  • Es wurde bestätigt, dass der Prozessor eine Machine-Check-Exception meldet und stoppt, wenn mehrere Kerne denselben Bug auslösen.

Reproduktion

  • Die Forschungsergebnisse wurden in einem Sicherheitsforschungs-Repository veröffentlicht.
  • Um die Schwachstelle zu reproduzieren, kann das Tool icebreak verwendet werden.
  • Auf nicht betroffenen Systemen sollte es keine Ausgabe geben, auf betroffenen Systemen hingegen wird bei jeder erfolgreichen Reproduktion ein . ausgegeben.

Analyse

  • Wie Microcode auf modernen Systemen genau funktioniert, ist geheim, daher sind nur beobachtungsbasierte Theorien möglich.
  • Es wird vermutet, dass der Bug dazu führt, dass das Frontend die Größe des movsb-Befehls falsch berechnet, wodurch nachfolgende Einträge im ROB (Reorder Buffer) mit falschen Adressen verknüpft werden.

Fragen

  • Es könnte Fragen dazu geben, was in diesem unerwarteten „Glitch“-Zustand möglich ist.
  • Bekannt ist, dass sich der Systemzustand so weit beschädigen lässt, dass ein Machine-Check-Fehler ausgelöst wird, und dass ein Thread die Ausführung seines SMT-Geschwisterprozessors beeinflussen kann.
  • Da es keine Möglichkeit gibt, die μop-Ausführung zu debuggen, ist nicht bekannt, ob sich damit eine Privilegieneskalation erreichen lässt.

Lösung

  • Intel hat aktualisierten Microcode für alle betroffenen Prozessoren veröffentlicht.
  • Möglicherweise stellen Betriebssystem- oder BIOS-Anbieter das Update bereits bereit.

Alternative

  • Falls ein Update nicht möglich ist, lassen sich schnelle Strings über das modell-spezifische Register IA32_MISC_ENABLE deaktivieren.
  • Dies führt jedoch zu einem erheblichen Leistungsverlust und sollte nur verwendet werden, wenn es unbedingt notwendig ist.

Meinung von GN⁺

Der wichtigste Punkt dieses Artikels ist, dass ein unerwarteter „Glitch“-Zustand in modernen CPUs entdeckt wurde und dass sich daraus Sicherheitslücken ergeben können. Der Beitrag dürfte für Softwareentwickler interessant sein und hilft, das Bewusstsein für die Komplexität von CPUs und die Verwundbarkeit von Systemen zu schärfen. Außerdem erleichtert er das Verständnis dafür, wie solche Entdeckungen zu realen Sicherheitsbedrohungen werden können, und unterstreicht die Bedeutung aktualisierten Microcodes.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-11-15
Hacker-News-Kommentare

  • Das Team von Konrad Magnusson hat ein Problem im Zusammenhang mit mimalloc entdeckt.

    • Konrad Magnusson von Paradox Interactive hat ein Issue im Zusammenhang mit mimalloc gefunden, das mit einer neuen CPU-Schwachstelle in Verbindung stehen könnte, die von Google-Forschern entdeckt wurde.

  • Mehrere Forschungsteams innerhalb von Google haben den Bug unabhängig voneinander entdeckt.

    • Mehrere Forschungsteams innerhalb von Google, darunter das silifuzz-Team und das Google Information Security Engineering Team, haben denselben Bug unabhängig voneinander gefunden.

  • Der Prozessor meldet eine Machine-Check-Exception und stoppt.

    • Es wird ein Phänomen erwähnt, bei dem der Prozessor eine Machine-Check-Exception meldet und den Betrieb einstellt.

  • Man erkennt, dass das Verständnis von Hardware unzureichend ist.

    • Es wird wahrgenommen, dass das Wissen über Hardware unzureichend ist, und es wird gefragt, warum ein "Präfix" nötig ist, um das Verhalten eines Befehls zu ändern.

  • Es erinnert an die Diagnose, als qemu auf das Problem mit repz ret stieß.

    • Es wird an die Situation erinnert, in der qemu das Problem mit repz ret diagnostizierte.

  • Sowohl Intel-Mitarbeiter als auch Google-Mitarbeiter haben das Problem gemeldet.

    • Intel bedankt sich bei den eigenen Mitarbeitern und den Google-Mitarbeitern dafür, dass sie dieses Problem intern entdeckt und gemeldet haben.

  • Viel interessanter als der Artikel von Google.

    • Es wird ausgedrückt, dass diese Diskussion deutlich interessanter ist als der Artikel von Google.

  • Zweifel daran, ob es möglich ist, eine CPU zu entwerfen, die nicht der Reihe nach, sondern spekulativ ausgeführt wird, ohne Sicherheitsprobleme.

    • Es wird die Frage aufgeworfen, welche Sicherheitsprobleme auftreten können, wenn man eine CPU entwirft, die nicht der Reihe nach, sondern spekulativ ausführt, und ob die Zukunft dahin gehen könnte, dass jeder einzelne A55-Kern unabhängig eine Anwendung ausführt.

  • Erklärung zu Intels Sicherheitsmitteilung.

    • Intels Sicherheitsmitteilung erklärt, dass es auf bestimmten Intel-Prozessoren eine Befehlssequenz gibt, die unerwartetes Verhalten verursacht und es einem authentifizierten Benutzer ermöglichen kann, Rechte auszuweiten, Informationen offenzulegen oder einen Denial-of-Service auszulösen.