On Sun, 2 May 2021 09:50:06 +0000 Rolf Schumann
Am 02.05.21 um 10:00 schrieb Tobias Crefeld:
Welche Sicherheitsvorteile soll XEN bieten? aus Linuxmagazin:
"Anders bei KVM: KVM koordiniert im Kernel etwa den Zugriff auf RAM und CPU selbst. Der Hostkernel sieht immer die gesamte Hardware. Eine Amok laufende VM kann dadurch andere VMs stören. Das gilt sogar für direkt an eine VM durchgereichte Hardware. Wer also bei KVM etwa einzelnen VMs eigene NICs zur Verfügung stellt, hat nicht die Garantie, dass eine über diese NICs stattfindende Attacke nicht das Hostsystem und damit andere VMs beeinflusst.
In Xen ist das anders: Weil der Hypervisor die Hardware verwaltet, ist sicher, dass wirklich nur die jeweilige VM beeinflusst wird, der die NIC zugeordnet ist."
Sorry, den Artikel hatte ich nicht gelesen. Halte den Text für irreführend, weil er suggeriert, dass es bei XEN einen Hypervisor gäbe und bei KVM nicht. Ist natürlich Quatsch, weil KVM _ist_ der Hypervisor, ordnet also den VMs die Resourcen zu. Alle mir bekannten x86-basierten Virtualisierer arbeiten mit einem Kernel, auf dem ein Hypervisor läuft. Es gibt Unterschiede hinsichtlich der Frage, ob er dort im User-Space und/oder Kernel-Space läuft, aber einen Kernel gibt es überall. Die Zuordnung von Resourcen klappt bei allen moderneren x86-Hypervisor zuverlässig. Dass eine "Amok laufende" VM den Host bzw. die anderen VM runter zieht, ist mir schon lange nicht mehr untergekommen. Ausbrüche aus einer VM mit Übernahme des Hostkernel sind mir bislang nur als Proof-of-Concept bekannt, für das etliche Voraussetzungen gegeben sein müssen. Kritisch und am ehesten Quelle für Instabilitäten sind hardware-nahe Dinge wie die Einbindung von Adapterkarten via PCI-passthrough, wo Hardware außerhalb der Hypervisor-Kontrolle durchgereicht wird. Es gibt in Hardware bzw. Firmware gegossenen Hypervisor, die tatsächlich keinen Kernel haben, der manipuliert werden könnte, z.B. LPAR von IBM. Besonders bei den frühen Implementierungen waren die Resourcen-Zuordnungen sehr statisch. Dafür hast Du die Dinger selbst mit roher Gewalt nur schwer zum Systemstillstand bringen können. Das ging (geht?) soweit, dass in Tabellen festgelegt werden musste, welche Logical Partition (=VM) welchen RAM-Adressbereich nutzen darf.
Unterschiedliche Gastsysteme: wir benutzten Debian als dom0 für XEN, worauf Windows und Ubuntu als Gastsysteme liefen. Das ist nun Geschichte, aber unzufrieden waren wir damit nicht...
Wie gesagt, das kommt darauf an, welches XEN man meint. Traditionell mussten die VMs alle dasselbe OS wie die dom0 nutzen. Ihr hattet hingegen XEN mit Qemu. Qemu bietet hier die nötige Vollvirtualisierung, die man benötigt, um VMs mit anderen OS zu betreiben. Bei den frühen Installationen hat das jeder vermieden, weil es deutlich Performance gekostet hat. Der Punkt fiel erst mit der Verbreitung von CPUs mit den Virtualisierungsfeatures nicht mehr ins Gewicht. Ich hatte vor ein paar Jahren ein Altsystem zu betreuen, dass noch mit einem traditionellen XEN-Setup arbeitete. Dort die VMs (alias dom) so zu extrahieren, dass sie in einem Vollvirtualisierer lauffähig sind, war schon eine besondere Herausforderung. IIRC haben wir am Ende lieber die Notwendigkeit zur Beibehaltung des Systems wegdiskutiert. ;) Gruß, Tobias.