fefes blog massive Lücke in VT?

[rprengel]

Hallo,
mein Lieblings-Blogger räumt gerade mal wieder ab.
Kann das jemand hier Fakten einmal bewerten?

Gruß
Ralf


https://blog.fefe.de/


[l] Apokalyptisches Security Advisory von Intel. Der Bug is in VT-d, das ist deren Marketingname für die IOMMU. Die IOMMU wird verwendet, um einem I/O-Gerät einen virtuellen Adressraum zu geben. Traditionell war das so, dass jedes PCI-Gerät, wenn es wollte, überallhin schreiben konnte im Speicher. Als AMD den Speicherkontroller in die CPU schob (vorher war das ein externer Baustein), haben sie die Gelegenheit genutzt, um da auch gleich eine MMU reinzuschieben.
Der Kernel kann jetzt der IOMMU sowas sagen wie: Das Gerät XY sieht diesen physischen Speicher an diesen Adressen. Wenn da nur Speicher sichtbar ist, der für nichts anderes parallel benutzt wird, dann kann so auch ein bösartiges Gerät nicht mehr den Kernel überschreiben.

Das ist besonders wichtig für zwei Szenarien. Erstens: Wenn ein PCI-Bus aus dem Gerät rausgeführt wird, wie bei Thunderbolt. Zweitens: Für einen Hypervisor.

Der Hypervisor kann so nämlich ein Gerät an den Guest "durchreichen" und muss das nicht emulieren. Der Hypervisor könnte könnte der IOMMU sagen: Das Gerät sieht diesen Speicher, der dem Guest gehört. Den Guest kann man dann das Gerät direkt programmieren lassen, und das schlimmste was er kaputtmachen kann ist dass er seinen eigenen Speicher überschreiben lässt. Nicht den Speicher anderer virtueller Maschinen auf der gleichen Hardware, und nicht den Speicher des Hypervisors.

Inzwischen betreibt niemand mehr einen Hypervisor ohne VT-d oder das AMD-Äquivalent. Wenn da also ein Bug drin ist, heißt das praktisch zwangsläufig, dass ein Guest damit aus der VM ausbrechen kann.

Intel sagt das nicht direkt sondern spricht von "privilege escalation" und "authenticated user" und "local access". Das ist technisch korrekt aber irreführend. Es geht nicht nicht darum, dass der User Fefe sich Admin-Rechte beschafft. Es geht darum, dass Kernel-Code in einer VM den Hypervisor kompromittiert.

Die betroffenen Produkte ist einmal die Produktpalette inklusive Atoms und Core-CPUs ab 10th gen.

Das mit der IOMMU ist übrigens auch ansonsten ein Schlachtfeld und bei weitem nicht so schön einfach wie ich es hier erklärt habe. Häufig ist es so, dass wenn du write auf einen Socket machst, dass der Kernel dann halt die Page mit dem Buffer für die Hardware lesbar macht. Da steht aber neben den 5 Bytes, die du schreiben wolltest, noch irgendwelche anderen Daten drauf. Die Granularität der IOMMU ist eine Page (4 KB). Mein Kumpel Ilja hat da mal mit einem gehackten qemu immer schön die Pages gedumpt, die die Netzwerkkarte freigeschaltet hatte, und konnte Passwörter und Keymaterial sehen. Insofern ist auch mit funktionierender IOMMU nicht alles rosig.

Aber das hier ist m.E. deutlich schlimmer als die Presse bisher darüber berichtet hat.

Update: Nomenklatur-Verwirrung. Ich schrieb "Host" und meinte "Guest".

[Martin]

Inzwischen betreibt niemand mehr einen Hypervisor ohne VT-d oder das AMD-Äquivalent.

Die allermeisten vSphere-Umgebungen die ich kenne, verwenden kein PCI passthrough / VT-d, außer ein paar spezielle VDI-Installationen mit teuren Nvidia-Karten für 3D-Support in virtuellen Desktops.

[Dayworker]

Passthrough machen im Normalfall nur die wenigsten, daher ist die offizielle VMware-Liste dazu weiterhin ausgesprochen kurz. Die Frage wäre allerdings, wie sich die Lage ab TR-Pro bzw Epyc mit ihrer RAM-Verschlüsselung ändert.
Im Umkehrschluß bedeutet das allerdings auch, daß die Gerätehersteller zukünftig die Grösse des DMA-Speicherfensters genauer angeben und damit auch einhalten müssen.