Quasi als Weihnachtsgeschenk hat das Entwickler-Team den für viele Plattformen erhältlichen Quick-EMUlator (QEMU) in Version 10.2 veröffentlicht. 188 Entwickler haben dazu über 2300 Neuerungen und Verbesserungen in das OpenSource-Projekt einfließen lassen.

Nicht mehr alle Security-Bugs sind Security-Bugs

Gleich der erste Hinweis im Changelog zu QEMU 10.2, der als "Klarstellung der Sicherheitsrichtlinie von QEMU" bezeichnet wird, wirft Fragen auf. Zunächst einmal: In Version 10.2 des QEMU-Projekts wurde die Security Policy explizit klarer definiert, insbesondere was der Begriff "Security Bugs" im Kontext von QEMU bedeutet. Von nun an gelten Fehler nur noch dann als echte Security-Bugs, wenn sie in klar definierten "Virtualization Use Cases" auftreten. Dazu zählen Szenarien mit Hardware-Beschleunigern unter WHPX (Windows), KVM (Linux), HVF (macOS) oder NVMM (NetBSD) und vor allem nur bestimmte Maschinen-Typen, die in den "Security Requirements" explizit aufgelistet werden: aarch64 (virt), i386 und x86_64 (microvm, xenfv, xenpv, xenpvh, pc, q35), s390x (s390-ccw-virtio), loongarch64 (virt), ppc64 (pseries) sowie riscv32 und riscv64 (virt). Das bedeutet, dass sicherheitskritische Fehler in allen anderen Emulations-Szenarien im QEMU-Kontext nicht mehr grundsätzlich als sicherheitstechnische Fehler angesehen werden (müssen).

Damit fallen viele Anwendungsbereiche aus der Sicherheitsrichtlinie heraus, beispielsweise die rein software-basierte "Full System Emulation" mit dem Tiny Code Generator (TCG), bei dem Gast-CPU-Instruktionen dynamisch in Host-Code übersetzt werden. Das betrifft alle Anwendungsfälle, in denen eine beliebige Gast-Architektur auf einem beliebigem Host ausgeführt wird. Zum Beispiel wenn ein ARM-Gast auf einem x86-Host für Cross-Architektur-Entwicklung, Firmware-Tests, Embedded-Simulation oder Debugging ausgeführt wird. Und auch die "User-Mode Emulation" (qemu-user), die nur CPU- und Systemaufrufe, aber kein komplettes System emuliert, dürfte damit aus der neuen Sicherheitsrichtlinie herausfallen. Das betrifft unter anderem Cross-Builds und CI sowie vermutlich auch Container-Builds mit "multi-arch-Docker".

Schwierig wird die Zuordnung, wenn es um hybride QEMU-Modi geht. Das ist der Fall, wenn grundsätzlich Hardware-Beschleunigung eingesetzt wird, dazu aber bestimmte Geräte oder Funktionen per TCG emuliert werden (legacy-devices). Der Sicherheitsstatus ist dabei vom konkreten Setup abhängig. Als QEMU-Anwender muss man dann herausfinden, ob das Szenario als unterstützter Virtualization Use Case gilt - oder nicht. Das dürfte spannend werden.

Viel Neues bei ARM, RISC-V und PowerPC, weniger für LoongArch, s390x und x86

QEMU erweitert die ARM-Emulation um zahlreiche neue CPU-Features, entfernt die veraltete pxa-CPU-Familie und verbessert Debugging sowie Geräteunterstützung (u. a. SME/SME2 in gdbstub, mehrere SMMUv3-Geräte, neue/erweiterte SoC-Komponenten bei aspeed und xlnx). Zusätzlich gibt es ein neues Board-Modell (amd-versal2-virt) und genauere Modellierung von Interrupt- und PCIe-Hardware in bestehenden ARM-Plattformen.