Comment contourner la limite de 2 machines virtuelles sur Apple Silicon (2023)

• Sur macOS basé sur Apple Silicon, Virtualization.framework limite à un maximum de 2 VM macOS exécutables, conformément à une clause du contrat de licence macOS
• L’analyse montre que cette limite est gérée par la variable privée hv_apple_isa_vm_quota à l’intérieur du noyau XNU, et qu’elle peut être redéfinie via des arguments de démarrage
• Pour contourner la vérification AppleInternal de System Integrity Protection, une procédure consistant à compiler et démarrer un noyau de développement (Development Kernel) est utilisée
• Après configuration, il a été possible d’exécuter jusqu’à 9 VM macOS simultanément dans UTM, Viable, Parallels, etc.
• Le fait qu’Apple ait laissé dans le noyau une fonction de redéfinition de la limite de VM est notable, et ouvre la voie à de futures améliorations via des outils d’automatisation ou des extensions du noyau

---

Processus de suppression de la limite de 2 VM macOS sur Apple Silicon

• Sur les Mac Apple Silicon, lors de l’exécution de machines virtuelles macOS avec Virtualization.framework, il existe une limite à 2 instances maximum
  • Cette limite est définie conformément à la clause 2.B.iii du contrat de licence logicielle macOS (SLA)
  • Cette clause autorise l’exécution d’au maximum 2 instances de macOS pour le développement, les tests, l’utilisation de macOS Server et un usage personnel non commercial
• L’analyse montre que cette limite est implémentée non pas en espace utilisateur mais dans une zone privée du noyau XNU
  • Le noyau Intel ne contient pas le même code, et c’est la famille de fonctions hv_vm_* du noyau Apple Silicon qui prend en charge la pile de virtualisation
  • La variable hv_apple_isa_vm_quota dans le code d’initialisation hv_init() gère le nombre de VM, avec incrémentation et décrémentation lors de la création et de la suppression des VM
  • Le noyau accepte les arguments de démarrage hypervisor= et hv_apple_isa_vm_quota=, ce dernier permettant de redéfinir la limite de VM
• Dans le noyau de release, l’usage de l’argument hypervisor est restreint par la vérification AppleInternal de System Integrity Protection (SIP)
  • L’argument hv_apple_isa_vm_quota n’est pris en compte que si le drapeau CSR_ALLOW_APPLE_INTERNAL est activé
  • Pour contourner cela, la méthode utilisée consiste à démarrer le noyau de développement d’Apple (Development Kernel)

Compilation d’une collection de noyau de développement

• Il faut télécharger et installer le Kernel Debug Kit (KDK) depuis le site Apple Developer
  • Le KDK doit correspondre exactement à la build macOS de l’hôte, sinon des erreurs de liaison du noyau et des kexts, ainsi que des échecs de démarrage, peuvent se produire
• Après avoir vérifié l’architecture du noyau avec la commande uname, on utilise kmutil create pour générer une collection de noyau de développement (VirtualMachine.kc)
  • L’exemple utilise macOS 14.0 (build 23A5301h) et le noyau T6020
  • L’option --variant-suffix development permet de sélectionner le noyau de développement, en incluant plusieurs dépôts d’extensions système

Configuration du démarrage sur le noyau de développement

• Après avoir éteint le Mac, il faut démarrer en mode de récupération (recoveryOS) puis effectuer les réglages suivants dans le terminal
  1. Désactiver System Integrity Protection (csrutil disable)
  2. Lever la restriction sur les arguments de démarrage (bputil --disable-boot-args-restriction)
  3. Spécifier la collection de noyau personnalisée (kmutil configure-boot)
  4. Définir les arguments de démarrage (transmis via la commande nvram)
     • kcsuffix=development : démarrage sur le noyau de développement
     • hypervisor=0x1 : activation de fonctions spéciales de la pile de virtualisation
     • hv_apple_isa_vm_quota=0xFF : définit le nombre maximal de VM à 255
• Après redémarrage, on peut vérifier l’application des réglages avec sysctl kern.osbuildconfig et nvram boot-args

Résultat de l’exécution de plusieurs VM

• Une fois la configuration terminée, des tests ont été menés avec des solutions basées sur Virtualization.framework comme UTM, Viable et Parallels
  • Sur un MacBook Pro M2 Pro, il a été possible d’exécuter 9 VM macOS simultanément
  • Le système restait encore utilisable à un niveau acceptable pour les tests

Moment d’ajout de la fonctionnalité et structure interne

• L’argument de démarrage hv_apple_isa_vm_quota a été ajouté avec la pile Virtualization à partir de macOS 12 Monterey
  • Dans les versions ultérieures, y compris macOS Sonoma, la vérification AppleInternal est toujours présente
  • Cela confirme qu’Apple maintient plusieurs fonctions privées à l’intérieur de XNU

Points d’attention lors des mises à jour de l’OS

• L’utilisation d’une collection de noyau personnalisée désactive les mises à jour automatiques de l’OS
  • Des erreurs surviennent après mise à jour, il faut donc restaurer la collection de noyau par défaut
  • En mode de récupération, on peut revenir au noyau par défaut en générant une nouvelle politique de démarrage avec bputil
  • Par exemple : bputil --full-security ou l’option --disable-boot-args-restriction

Conclusion et pistes d’amélioration

• L’implémentation par Apple de la limite de VM a été identifiée, et une méthode non officielle mais fonctionnelle de suppression de cette limite a été validée expérimentalement
  • Il est notable que, même sans documentation officielle de l’équipe Virtualization, Apple ait laissé dans le noyau une fonction de redéfinition de la limite de VM
• Pistes d’amélioration envisagées
  • Développement d’un outil d’automatisation pour la compilation de KC et la configuration du démarrage
    • Génération automatique de collections de noyau de développement selon l’hôte et prise en charge de la configuration en mode de récupération
  • Implémentation d’une fonction de redéfinition de la variable hv_apple_isa_vm_quota via une extension du noyau (kext)
    • Explorer la possibilité de lever la limite sans démarrer sur un noyau de développement
• Le prochain sujet de recherche portera sur la possibilité d’enregistrer les VM Apple Silicon dans DEP et de redéfinir le numéro de série

[GN⁺]

Commentaires sur Hacker News

• Ce genre de limitation, appliquée de la même façon à tous les Mac, est totalement irrationnelle
  Si on a acheté un Mac plus puissant, on devrait pouvoir virtualiser davantage d’instances de macOS
  Par exemple, une limite de 2 pour un M5, 4 pour un M5 Pro et 8 pour un M5 Max semblerait plus logique

  • Je ne comprends même pas pourquoi il y a une limite au départ
    Les performances matérielles constituent déjà une limite naturelle, donc l’utilisateur s’arrêterait de lui-même
  • Cela ressemble davantage à une décision business qu’à un problème de ressources
    C’est probablement une mesure destinée à empêcher les services VPS Mac bon marché
  • Ici, on ne se bat pas contre une limite matérielle, mais contre les inquiétudes de Tim Cook pour les ventes
  • Si on achète une licence Windows 11 Pro à 100 dollars, la limite de VM est de 1024
    Hyper‑V peut exécuter jusqu’à 1024 VM simultanément si le matériel le permet
    Même sur mon petit portable Windows ARM, je peux en faire tourner 4 sans difficulté
  • C’est vraiment absurde
    J’ai lancé une VM pour tester openclaw, puis j’ai été surpris de voir que l’accès à iCloud et à l’App Store était restreint

• Il est intéressant de voir que Mykola Grymalyuk a rejoint Apple deux ans après avoir écrit cet article de blog
  Ça rappelle le mème « mourir en héros ou… »

• À partir de la puce M3, il est possible d’exécuter des VM imbriquées via Hypervisor.framework / Virtualization.framework
  Si cela permet de contourner la limitation, ce serait assez amusant

  • Si je me souviens bien, seule l’imbrication de guests Linux est possible
    macOS est limité à un seul niveau, donc on ne peut pas lancer un autre guest macOS à l’intérieur d’un guest macOS
  • Si chaque VM pouvait à son tour exécuter 2 VM, on pourrait peut-être créer une chaîne infinie de VM
    Je suis trop paresseux pour tester, mais j’aimerais bien que quelqu’un le fasse

• Je me demande vraiment pourquoi Apple a imposé cette limitation

  • Le modèle économique d’Apple consiste à vendre ensemble le matériel et le logiciel
    Les ventes de matériel financent le développement du logiciel, donc Apple ne veut pas que des personnes utilisent macOS sans acheter le matériel
  • macOS comporte beaucoup de restrictions imposées aux utilisateurs
    Pour Apple, garder le contrôle passe avant la liberté de l’utilisateur
  • C’est peut-être aussi une mesure destinée à empêcher de faire tourner une ferme de comptes en ligne (identity farm) sur un seul Mac

• C’est impressionnant de pouvoir compiler un kernel personnalisé, démarrer dessus et aller jusqu’à lancer l’interface graphique

• L’article lui-même est vraiment intéressant, mais c’est étrange d’utiliser pour le développement une plateforme avec ce type de limitations arbitraires

  • Je me demande si Apple a vraiment été une plateforme de développement sérieuse au cours des 20 dernières années
    Beaucoup de développeurs l’utilisent pour son matériel haut de gamme, mais macOS a toujours été « presque Linux, sauf que l’OS reste contrôlé par une entreprise centrée sur iTunes »

• Il paraît qu’avec une collection de kernels personnalisés sur Apple Silicon, les mises à jour automatiques de l’OS deviennent impossibles
  Mais au fond, cela pourrait être une bénédiction déguisée

• Je me demande si cela pourrait aussi fonctionner avec lume
  Il y a actuellement une limitation similaire

  • Ça semble possible
    De ce que je comprends, lume est un wrapper léger autour de la Virtualization.framework d’Apple

• J’ai entendu dire qu’en désactivant SIP et en définissant des arguments de boot, c’était possible même sans kernel personnalisé

  • Si c’est vrai, c’est une astuce largement sous-estimée

• Apple a limité les VM à 2 ?

  • Oui, les VM macOS sont limitées par la licence à 2
    Les guests d’autres OS peuvent être exécutés sans limitation