Der XEN Hypervisor und Microcode-Updates

Man sollte meinen, dass Microcode-Updates auf modernen Linux-Distributionen eigentlich unproblematisch wären. Diese Annahme ist auch grundsätzlich richtig. Dennoch gibt es immer wieder Edge-Cases, in denen Distributionsentwickler etwas übersehen.

Am Beispiel von Ubuntu 18.04 LTS „Bionic Beaver“ in Verbindung mit dem XEN Hypervisor wird dies klar, wenn es zu den Microcode-Updates kommt.

Ubuntu liefert zwar für AMD und Intel jeweils aktualisierte Microcode-Pakete aus, diese werden jedoch scheinbar nicht in den Prozessor eingespielt.

XEN Microkernel

Hintergrund ist, dass das Host-System bei Xen bereits paravirtualisiert ist, und aus Sicherheitsgründen nicht direkt auf die CPU Einfluss nehmen kann. Dementsprechend schlagen auch manuelle Versuche, den aktuellen Microcode einzuspielen, fehl.

In diesem Falle muss man das Einspielen dem XEN-eigenen Microkernel überlassen, der diese Aufgabe zum Boot-Zeitpunkt übernimmt.

Kommandozeile in Grub anpassen

Damit der XEN-eigene Kernel den Microcode der CPU patchen kann, muss er zum einen Zugriff auf diesen zur Boot-Zeit haben, zum anderen muss er auch die Anweisung bekommen. Letzteres erreichen wir, indem wir der Grub-Bootloader-Konfiguration einen Parameter in der Kernel-Kommandozeile hinzufügen.

Im Falle von Ubuntu 18.04 LTS findet sich die Grub-Konfigurationsdatei unter: /etc/default/grub

Dort sollte sich die Datei xen.cfg befinden. Dies ist natürlich nur der Fall, wenn das XEN Hypervisor Paket auch installiert ist. Diese öffnet man mit seinem Lieblingseditor und sucht die Stelle mit der Variable GRUB_CMDLINE_XEN_DEFAULT. Diese ergänzt man um den Parameter ucode=scan. Im Default-Zustand sieht die Zeile der xen.cfg dann so aus:

GRUB_CMDLINE_XEN_DEFAULT="ucode=scan"

Initramfs anpassen

Neben der Anweisung braucht der Microkernel des Xen Hypervisors auch Zugriff auf die jeweiligen Microcode-Dateien sowie ggf. das Intel-Microcode Tool.

Während die Microcode-Pakete in der Regel bereits richtig installiert sind, ist das Intel-Tool möglicherweise per sudo apt-get install iucode-tool nachzuinstallieren. Ferner muss dafür Sorge getragen werden, die Microcode-Dateien auch in die initiale Ramdisk zu bekommen. Hierzu stellt uns Ubuntu bereits passende Scripte zur Verfügung.

Im Default-Zustand versucht das System, die Microcodes die in die InitramFS gelangen sollen, passend zur Hardware-CPU auszuwählen. Dies gelingt leider nicht immer, daher muss man ggf. hier Hand anlegen.

Mit dem Befehl sudo lsinitrd /boot/initrd.img-4.15.0-46-generic lässt sich beispielsweise prüfen, welche Inhalte in der InitramFS mit Namen initrd.img-4.15.0-46-generic vorhanden sind. Sollte beispielsweise auf einem Intelsystem etwas von AMD aber nicht von Intel zu lesen sein, ist die automatische Prozessorerkennung bei Erstellen der Initramdisk schiefgegangen.

Hier hilft es, im Verzeichnis /etc/default die Dateien amd64-microcode und intel-microcode anzupassen. Diese verfügen über jeweils eine Variable AMD64UCODE_INITRAMFS bzw. IUCODE_TOOL_INITRAMFS, die jeweils auf no, auto oder early stehen können. Default ist auto, was das System veranlasst, auf Basis der CPU-Erkennung entweder AMD oder Intel-Microcode zu integrieren. Ist dies schief gegangen, sollte man entsprechend den Wert early bei der Datei setzen, die zum Hersteller der eingebauten CPU passt und den anderen auf no. Ist der Hersteller Intel, kann man in der Datei intel-microcode zusätzlich folgende Variable setzen:

IUCODE_TOOL_SCANCPUS=yes

Dies veranlasst das Scriptset dazu, eine erweiterte CPU-Erkennung auf Basis der Intel-CPUs zu versuchen, sodass nur die Microcode-Dateien in die InitramFS gelangen, die zur CPU passen. Dies vermeidet eine übergroße initiale Ramdisk.

Änderungen finalisieren

Sowohl die Änderungen an der Grub-Config als auch die Anpassungen an die InitramFS müssen dann auch umgesetzt werden. Dies erfolgt dann über

sudo update-initramfs -u
sudo update-grub

Ein anschließender Neustart des Hypervisors wird dann den Xen Microkernel veranlassen, die in der InitramFS mitgelieferten Microcode-Patches in die CPU zu integrieren.

Lohnt sich der Aufwand?

Anpassungen am Microcode der Prozessoren sind wichtig. Hier liefern die CPU-Hersteller Fehlerbereinigungen zu der von ihnen verkauften „Hardware“ aus, die durchaus auch – wie wir im letzten Jahr an den Bugs Spectre und Meltdown gesehen haben – sehr sicherheitsrelevant sein kann.

Natürlich können Microcode-Updates auch kritisch betrachtet werden, da gerade am Beispiel Spectre und Meltdown eben diese Patches zum Teil deutliche Performanceverluste nach sich gezogen haben. Hier gilt es abzuwägen, ob man das betroffene System durch diese Microcode-Updates sichern muss oder ob dieses Riskio überschaubar ist. Hier gibt es durchaus verschiedene Ansichten, die jeweils im Kontext des Systemeinsatzes zu betrachetn sind. Ein Virtualisierungshost, auf dem virtuelle Maschinen von Dritten laufen hat ganz andere Sicherheitsanforderungen, als ein Hypervisor, der tief in der internen Infrastruktur eingebettet ist, auf dem ausschließlich vertrauenswürdige VM laufen. Zwischen diesen beiden Extremen gibt es selbstverständlich einige Schattierungen.