An diesem Punkt ist core 1 außerhalb von SMM, während core 0 darin ist, sodass core 1 core 0 angreifen kann. Hier ist der Haken: Damit dies funktioniert, brauchen wir eine sehr, sehr, seeeehr lange Instruktion — länger, als jede Instruktion jemals dauern sollte. Die meisten Maschineninstruktionen auf einer modernen CPU sind schnell: add dauert 1 Zyklus. Um core 1 dazu zu bringen, auf core 0 aufzugeben, brauchen wir eine Instruktion auf core 0, die etwa 4.000.000.000 Zyklen dauert — über 1 Sekunde Echtzeit.

Das Ein-Sekunden-Timeout

x86-Firmware führt den folgenden Code aus, wenn ein CPU-Kern in SMM eintritt:

Der Code wartet darauf, dass alle Kerne in SMM eintreten, oder bis zu 1 Sekunde, je nachdem, was zuerst eintritt. Um einen Kern dazu zu bringen, SMM-Code auszuführen, während ein anderer Kern außerhalb von SMM weiterläuft, muss dieser äußere Kern für die gesamte Sekunde unterbrechungsfrei bleiben — ein SMI wird an einer Instruktionsgrenze angenommen, sodass jede Lücke zwischen zwei Instruktionen es dem ausstehenden SMI ermöglicht, den Kern in SMM zu ziehen. Die Verzögerung muss daher eine einzelne Instruktion sein: eine einzige nicht unterbrechbare Operation, die das Ein-Sekunden-Rendezvous überdauert.

Proof-of-Concept

Es gibt viele Wege, um zur verbotenen Ein-Sekunden-Instruktion zu gelangen, und der genaue Ansatz variiert von Plattform zu Plattform. Aber grob gesagt: Finde eine Hochlatenz-MMIO-Adresse und überzeuge dann die CPU, so langsam wie möglich von ihr zu lesen — missbrauche eine undokumentierte Region, die Lesezugriffe im Schneckentempo beantwortet, verwende den breitesten Load, den die ISA dir bietet, um so viele Bytes wie möglich in einer einzigen Instruktion darüber zu bewegen, und lass die anderen Kerne um denselben Bus konkurrieren, um es weiter zu verlangsamen. Ein Lesezugriff, eine Instruktion, und die CPU bleibt für den Großteil einer Sekunde daran hängen.

Das bereitgestellte Proof-of-Concept ist auf einen Zen 3 Ryzen 7 5800H abgestimmt, wo ein breiter xmm-Load von langsamem MMIO bei 0xfcc68860 lange genug anhält, um das All-Kerne-Rendezvous zu brechen:

Das PoC nutzt dies aus, indem es zwei Kerne gegeneinander antreten lässt. Ein Kern wird außerhalb von SMM gehalten durch die lange Instruktion — eine enge Schleife auf dem sehr langsamen Load:

Währenddessen aktiviert ein anderer Kern die Pro-Kern-SMI-Zähler:

Dann feuert einen Sturm von SMIs ab:

Und liest die Bilanz jedes Kerns zurück:

Wenn die Zähler voneinander abweichen, bedeutet das, dass ein Kern außerhalb von SMM weiterlief, während die anderen hineingezogen wurden — er verpasste die SMIs, die die übrigen abarbeiteten.

Um dies besser zu veranschaulichen, können wir das Proof-of-Concept hinter einer unnötig auffälligen und völlig nutzlosen GUI ausführen, die SMI-Zähler auf jedem Kern verfolgt, um zu beobachten, wie sie in perfektem Gleichschritt ausgeführt werden, bis ein stark verzögerter Kern ihre erforderliche Synchronisation bricht:

SMMs einzige Garantie — dass nichts anderes läuft, während es läuft — fällt unter einer einzigen absurden langen Instruktion auseinander.

Ausnutzung

SMMs Sicherheit beruht auf einer einfachen Annahme: Während es läuft, läuft nichts anderes.

Es gibt 100+ SMM TOCTOU CVEs da draußen: ein SMM Handler prüft einen Wert im gemeinsamen Speicher, und verwendet ihn dann. Alles, was du für die Ausnutzung brauchst, ist, diesen Wert zwischen Prüfung und Verwendung neu zu schreiben, und du bist in SMM. Aber diese Probleme liegen schlummernd und weitgehend ungepatcht in freier Wildbahn, wegen einer Annahme: Ausnutzung erfordert etwas, das den gemeinsamen Speicher während der SMM-Ausführung modifiziert, und wegen des SMM-Rendezvous befinden sich keine CPU-Kerne außerhalb von SMM, um einen Angriff zu starten. Der einzige Weg hinein war ein DMA-fähiges Peripheriegerät, das hinter dem Rücken der CPU schreibt — physischer Zugriff, ein bösartiges Gerät —, sodass die gesamte Klasse als Hardwareproblem abgeschrieben wird.

SMI-Desynchronisierung entfernt die Voraussetzung, die die Plattform sicher hielt: Ein äußerer Kern, ohne physischen Zugriff oder Hardware, kann jetzt während der SMM-Ausführung laufen — und die schlummernden CVEs werden aus Software heraus ausnutzbar.

Gegenmaßnahmen

Es gibt wahrscheinlich keine, was dieses Problem etwas interessanter macht als traditionelle SMM-Probleme. Behalte das Timeout bei, und das Rendezvous ist leicht zu brechen. Entferne das Timeout, und ein legitimerweise festhängender Kern hängt die Plattform beim ersten SMI auf. Erhöhe das Timeout, und du tötest die Leistung auf Plattformen mit vielen Kernen, die gezwungen sind, alle Kerne bei jedem SMM-Eintritt zu beruhigen. Es ist nicht klar, was der beste Weg nach vorne ist, oder ob es überhaupt einen Weg nach vorne gibt.

Bis dahin ist die empfohlene Abhilfe, keine langen Instruktionen auszuführen.

Portierung auf deine Plattform

Der Standard-vmovdqu bei 0xfcc68860 im Proof-of-Concept ist eine langsame Stelle auf dieser Maschine — einem Zen 3 Ryzen 7 5800H — und wahrscheinlich nirgendwo sonst. Um das Rendezvous auf deiner Maschine zu brechen, musst du die lange Instruktion neu abstimmen, sodass der Stillstand dein SMM-Timeout überdauert. Einige Tipps, wie du das machst:

1. Ziele auf dein MMIO. Finde eine langsame MMIO-Region auf deiner Plattform mit mmiotic.
2. Verbreitere den Lesezugriff. Steigere -r xmm → ymm → zmm, bis der Stillstand das Rendezvous-Timeout überschreitet.
3. Tausche die Instruktion. Wenn kein einzelner MMIO-Lesezugriff langsam genug ist, brauchst du eine andere pathologisch lange Instruktion; die asm-hall-of-shame zeigt, wie man sie findet.

Erstellen

Verwendung

Die Standardwerte sind auf eine Maschine abgestimmt. Auf allem außer einem Zen 3 Ryzen 7 5800H erwarte keine Divergenz, bis du die lange Instruktion neu abstimmst — siehe Portierung auf deine Plattform.

Führe das Tool aus, um wiederholt die sehr-sehr-lange Instruktion abzufeuern, während du den SMI-Zähler jedes Kerns auf eine Divergenz beobachtest:

Flags:

Referenzen

• DEF CON 2026 – Weaponizing Uselessness

Autor

smiiiiiiiiiiiiiiii ist ein Forschungsprojekt von Christopher Domas (@xoreaxeaxeax).