Zenbleed

Nachdem die Presse das ziemlich stiefmütterlich zu behandeln scheint, wollte ich hier einmal anmerken, daß es aktuell auf allen AMD Zen 2 CPUs einen massiven Data Leak gibt, der sogar Meltdown und Spectre gut in den Schatten stellt: [Zenbleed]. Da wir auf der Arbeit EPYC CPUs im Bereich der NVIDIA vGPU Virtualisierung im Deep Learning einsetzen, die aus der Zen 2 Generation stammen - also "Rome" CPUs - waren wir betroffen. Da die entsprechenden HPE Firmware Updates erst frühestens im Oktober erscheinen dürften (denn erst da erscheinen die ersten patched AMD AGESA Firmwares) gab es zwingenden Handlungsbedarf.

Wer Linux einsetzt, möge auf der Baremetal Maschine die msr-tools installieren, also jene Werkzeuge, die die Modifikation von Chipsatzregistern oder "Model-Specific Registers" ermöglichen, und dann folgenden Befehl ausführen:

# wrmsr -a 0xc0011029 $(($(rdmsr -c 0xc0011029) | (1<<9)))

Außer natürlich man sei auf einer Maschine, die upstream ist und den letzten Linux Kernel 6.x beziehen kann, dann reicht ein volles Systemupdate mit Reboot.

Auf Microsoft Windows Maschinen exitiert ein ähnlicher Workaround, nachdem es noch keine Patches gibt: [Siehe hier]. Vor allem natürlich interessant auf Multi-User Maschinen, wie Terminal Servern. Erfordert aber die vorübergehende Deaktivierung von Hyper-V.

FreeBSD User können auf [cpucontrol(8)] setzen, um den selben Effekt zu erzielen, wie oben mit msr-tools gezeigt. Mehr dazu [hier].

PS.: Ich habe heute auf einer VM auf einem unserer vGPU Virtualisierer den [PoC Code von Google] kompiliert und ausgeführt; Das war schon ganz witzig, wie er wahllos im Akkordtempo Daten aller VMs und des Hosts einfach so rausgelesen hat; Wer auch immer also Zen 2 CPUs im Multiuserkontext laufen hat, sollte wirklich handeln! Das Tempo in dem man Daten einfach dumpen kann ist schwindelig. Von beliebigen SQL Queries über Userdaten bis hin zu Usernamen und Passwörtern ist alles drin!

Das ist eben das Problem; Der Leak ist extrem, und zwar jetzt. Diese AGESA Fixes sind viel zu spät. Deswegen sollte man entweder jetzt die Kernel Patches und/oder Software µCode Updates einspielen, oder einen der MSR Fixes nutzen (so wie wir es derweil gemacht haben). Meltdown ist echt ein Dreck gegen das hier.

Edit: AMD hatte übrigens schon im Mai hiervon erfahren. Was gut Zeit ist. Also die machen's auch einen Dreck besser als Intel bei Meltdown und Spectre.

Zen 3 ist nicht betroffen, sagt AMD. Ich habe das auf meiner (ungepatchten) Zen 3 Maschine nachweisen können, da blutet im Rahmen von Zenbleed tatsächlich nichts. Zen 1 soll angeblich betroffen sein, hier habe ich aber leider keine Maschinen um das zu testen.

Du könntest aber z.B. einfach ein Linux in einer VM aufsetzen auf'm Zen+, den Google Code bauen (ist ziemlich easy) und das so testen. Am schnellsten geht's, wennst der VM alle Threads/Kerne des Hosts zuweist. Je mehr Kerne, desto mehr Daten lassen sich rausziehen.

Zenbleed Proof-of-Concept Quelltext für Linux: [zenbleed.zip]

*Irrelevanter Fun Fact: Wenn die betroffene 256-bit YMM Prozessorregister prinzipiell gar nicht erst genutzt werden können, wird die Maschine immun. Das geht dann, wenn der Betriebssystemkernel keine Unterstützung für die AVX bzw. AVX2 Befehle XSAVE und XRSTORanbietet. Das führt dazu, daß keinerlei AVX Register oder Opcodes genutzt werden können. Also z.B. Linux 2.4 oder Windows XP oder so. Ajo, bei Apple mit x86 müßte man auf OS X 10.8 Mountain Lion setzen.

*Edit: Das ist nur meine Vermutung, dürfte aber ziemlich sicher stimmen, weil YMM Register nur mit AVX Befehlen ausgelesen werden können, und selbige schmeißen auf alten Systemen eine Illegal Instruction Exception.