So umgeht man auf Apple Silicon die Begrenzung auf 2 virtuelle Maschinen (2023)

• Auf Apple-Silicon-basiertem macOS sind mit Virtualization.framework ausgeführte macOS-VMs auf maximal 2 Instanzen begrenzt, was auf eine Klausel der macOS-Softwarelizenz zurückgeht
• Die Analyse zeigt, dass diese Begrenzung über die nicht öffentliche Variable hv_apple_isa_vm_quota im XNU-Kernel verwaltet wird und sich per Boot-Argument überschreiben lässt
• Um die AppleInternal-Prüfung von System Integrity Protection zu umgehen, wird ein Verfahren zum Bauen und Booten eines Development Kernel verwendet
• Nach der Konfiguration gelang es, in UTM, Viable, Parallels und anderen Umgebungen bis zu 9 macOS-VMs gleichzeitig auszuführen
• Bemerkenswert ist, dass Apple im Kernel eine Funktion zum Überschreiben des VM-Limits belassen hat; als mögliche Verbesserungen werden künftige Automatisierungstools oder Kernel-Erweiterungen genannt

---

So wird die Begrenzung auf 2 macOS-VMs auf Apple Silicon aufgehoben

• Auf Apple-Silicon-basierten Macs gibt es beim Ausführen von macOS-VMs mit Virtualization.framework eine Begrenzung auf maximal 2 Instanzen
  • Diese Begrenzung ist gemäß Klausel 2.B.iii der macOS-Softwarelizenz (SLA) festgelegt
  • Die Klausel erlaubt das Ausführen von bis zu 2 macOS-Instanzen nur für Entwicklung, Tests, die Nutzung von macOS Server sowie für nicht kommerzielle private Zwecke
• Die Analyse ergab, dass diese Begrenzung nicht im User Space, sondern im nicht öffentlichen Bereich des Kernels (XNU) implementiert ist
  • Im Intel-Kernel gibt es keinen entsprechenden Code; im Apple-Silicon-Kernel ist die Funktionsgruppe hv_vm_* für den Virtualisierungs-Stack zuständig
  • Die Variable hv_apple_isa_vm_quota im Initialisierungscode von hv_init() verwaltet die Anzahl der VMs und wird beim Erstellen bzw. Löschen von VMs hoch- und heruntergezählt
  • Im Kernel existieren die Boot-Argumente hypervisor= und hv_apple_isa_vm_quota=; Letzteres kann das VM-Limit überschreiben
• Im Release-Kernel ist dies nicht über das Argument hypervisor, sondern durch die AppleInternal-Prüfung von System Integrity Protection (SIP) eingeschränkt
  • Das Argument hv_apple_isa_vm_quota wird nur angewendet, wenn das Flag CSR_ALLOW_APPLE_INTERNAL aktiv ist
  • Um dies zu umgehen, wird das Booten von Apples Development Kernel verwendet

Development Kernel Collection bauen

• Von der Apple-Developer-Website muss das Kernel Debug Kit (KDK) heruntergeladen und installiert werden
  • Das KDK muss exakt zum Build des Host-macOS passen; bei Abweichungen können Fehler beim Verlinken von Kernel und kexts sowie Boot-Fehler auftreten
• Nach Prüfung der Kernel-Architektur mit dem Befehl uname wird mit kmutil create eine Development Kernel Collection (VirtualMachine.kc) erzeugt
  • Im Beispiel werden macOS 14.0 (Build 23A5301h) und der T6020-Kernel verwendet
  • Mit der Option --variant-suffix development wird der Development Kernel ausgewählt, außerdem werden mehrere Speicherorte für Systemerweiterungen eingebunden

Boot-Konfiguration für den Development Kernel

• Nach dem Ausschalten des Macs wird in den Wiederherstellungsmodus (recoveryOS) gebootet und im Terminal Folgendes konfiguriert
  1. System Integrity Protection deaktivieren (csrutil disable)
  2. Beschränkung für Boot-Argumente aufheben (bputil --disable-boot-args-restriction)
  3. Benutzerdefinierte Kernel Collection festlegen (kmutil configure-boot)
  4. Boot-Argumente setzen (per nvram)
     • kcsuffix=development : bootet den Development Kernel
     • hypervisor=0x1 : aktiviert spezielle Funktionen des Virtualisierungs-Stacks
     • hv_apple_isa_vm_quota=0xFF : setzt die maximale VM-Anzahl auf 255
• Nach dem Neustart lässt sich die Übernahme mit sysctl kern.osbuildconfig und nvram boot-args prüfen

Ergebnis beim Ausführen mehrerer VMs

• Nach Abschluss der Konfiguration wurden Tests mit auf Virtualization.framework basierenden Lösungen wie UTM, Viable und Parallels durchgeführt
  • Auf einem M2 Pro MacBook Pro konnten 9 macOS-VMs gleichzeitig ausgeführt werden
  • Das System blieb dabei weiterhin auf einem noch testbaren Niveau nutzbar

Zeitpunkt der Einführung und interne Struktur

• Seit macOS 12 Monterey wurde das Boot-Argument hv_apple_isa_vm_quota zusammen mit dem Virtualisierungs-Stack hinzugefügt
  • Auch in späteren Versionen, einschließlich macOS Sonoma, besteht die AppleInternal-Prüfung weiterhin
  • Damit zeigt sich, dass Apple innerhalb von XNU mehrere nicht öffentliche Funktionen beibehält

Hinweise bei OS-Updates

• Bei Verwendung einer benutzerdefinierten Kernel Collection wird die automatische OS-Update-Funktion deaktiviert
  • Nach einem Update treten Fehler auf, daher muss vorab auf die Standard-Kernel-Collection zurückgestellt werden
  • Im Wiederherstellungsmodus kann mit bputil eine neue Boot-Richtlinie erzeugt werden, um zum Standard-Kernel zurückzukehren
  • Beispiel: Verwendung der Optionen bputil --full-security oder --disable-boot-args-restriction

Fazit und Ideen für künftige Verbesserungen

• Die Implementierung der VM-Begrenzung durch Apple wurde nachvollzogen und eine inoffizielle, aber praktikable Methode zur Aufhebung des Limits experimentell verifiziert
  • Bemerkenswert ist, dass das Virtualization-Team trotz fehlender offizieller Dokumentation eine Möglichkeit zum Überschreiben des VM-Limits im Kernel belassen hat
• Ideen für künftige Verbesserungen
  • Entwicklung eines Automatisierungstools für KC-Build und Boot-Konfiguration
    • Automatische Erzeugung einer Development Kernel Collection pro Host sowie Unterstützung für Einstellungen im Wiederherstellungsmodus
  • Implementierung einer Funktion zum Überschreiben der Variable hv_apple_isa_vm_quota über eine Kernel-Erweiterung (kext)
    • Prüfung der Möglichkeit, das Limit ohne Booten des Development Kernel aufzuheben
• Als nächstes Forschungsthema soll die Möglichkeit der DEP-Registrierung und des Überschreibens von Seriennummern in Apple-Silicon-VMs untersucht werden

[GN⁺]

Hacker-News-Kommentare

• Eine solche Einschränkung, die für alle Macs gleichermaßen gilt, ist viel zu unvernünftig
  Wenn man einen leistungsstärkeren Mac gekauft hat, sollte man mehr macOS-Instanzen virtualisieren können
  Zum Beispiel wäre es sinnvoll, das etwa so zu begrenzen: M5 auf 2, M5 Pro auf 4, M5 Max auf 8

  • Ich verstehe nicht, warum es überhaupt eine Begrenzung geben sollte
    Die Hardware-Leistung ist die natürliche Grenze, also würden die Nutzer von selbst aufhören
  • Das wirkt eher wie eine Geschäftsentscheidung als ein Ressourcenproblem
    Wahrscheinlich soll damit verhindert werden, dass günstige Mac-VPS-Dienste entstehen
  • Hier kämpft man nicht gegen Hardware-Grenzen, sondern gegen Tim Cooks Sorge um die Verkaufszahlen
  • Wenn man eine Windows-11-Pro-Lizenz für 100 Dollar kauft, liegt das VM-Limit bei 1024
    Hyper‑V kann bis zu 1024 VMs gleichzeitig ausführen, sofern die Hardware das verkraftet
    Sogar auf meinem kleinen Windows-ARM-Laptop laufen 4 ohne Probleme
  • Wirklich absurd
    Ich habe eine VM zum Testen von openclaw gestartet und war überrascht, dass der Zugriff auf iCloud und den App Store eingeschränkt war

• Interessant ist, dass Mykola Grymalyuk zwei Jahre nach dem Schreiben dieses Blogposts bei Apple angefangen hat
  Da fällt einem direkt das Meme „Entweder stirbst du als Held oder …“ ein

• Ab dem M3 kann man mit Hypervisor.framework / Virtualization.framework verschachtelte VMs ausführen
  Wenn sich die Begrenzung damit umgehen ließe, wäre das ziemlich interessant

  • Soweit ich mich erinnere, ist Verschachtelung nur für Linux-Gäste möglich
    Bei macOS geht nur eine Ebene, daher kann man innerhalb eines macOS-Gasts keinen weiteren macOS-Gast starten
  • Wenn jede VM 2 VMs ausführen könnte, ließe sich vielleicht sogar eine unendliche VM-Kette bauen
    Ich bin zu faul dafür, aber ich wünschte, jemand würde das ausprobieren

• Ich frage mich wirklich, warum Apple so eine Beschränkung eingebaut hat

  • Apples Geschäftsmodell besteht darin, Hardware und Software als Paket zu verkaufen
    Der Hardware-Verkauf finanziert die Software-Entwicklung, daher will man offenbar nicht, dass Leute macOS nutzen, ohne die Hardware zu kaufen
  • macOS hat viele solcher Einschränkungen für Nutzer
    Für Apple ist es wichtiger, die Kontrolle zu behalten, als den Nutzern Freiheit zu geben
  • Vielleicht soll damit auch verhindert werden, dass man auf einem einzigen Mac eine Online-Kontenfarm (Identity Farm) betreibt

• Erstaunlich, dass man einen Custom-Kernel kompilieren, booten und sogar bis zur GUI bringen kann

• Der Artikel selbst ist wirklich interessant, aber eine Plattform mit solchen willkürlichen Beschränkungen für die Entwicklung zu nutzen, wirkt seltsam

  • Ich frage mich, ob Apple in den letzten 20 Jahren überhaupt eine ernsthafte Entwicklungsplattform war
    Viele Entwickler nutzen es wegen der hochwertigen Hardware, aber macOS war immer „fast Linux, aber ein Betriebssystem unter der Kontrolle einer iTunes-zentrierten Firma“

• Offenbar machen automatische OS-Updates auf Apple Silicon Probleme, wenn man eine Custom-Kernel-Collection verwendet
  Aber vielleicht ist das sogar ein versteckter Segen

• Ich frage mich, ob das auch unter lume funktionieren könnte
  Dort gibt es derzeit eine ähnliche Einschränkung

  • Scheint möglich zu sein
    Soweit ich weiß, ist lume nur ein dünner Wrapper um Apples Virtualization.framework

• Ich habe gehört, dass es auch ohne Custom-Kernel möglich ist, wenn man SIP deaktiviert und Boot-Argumente setzt

  • Falls das stimmt, ist das ein unterschätzter Tipp

• Apple hat VMs auf 2 begrenzt?

  • Ja, macOS-VMs sind laut Lizenz auf 2 beschränkt
    Andere Gastbetriebssysteme kann man ohne Begrenzung ausführen