Cómo eludir el límite de 2 máquinas virtuales en Apple Silicon (2023)

• En macOS basado en Apple Silicon, Virtualization.framework limita a un máximo de 2 VM de macOS ejecutables, con base en una cláusula del contrato de licencia de uso de macOS
• El análisis mostró que este límite se gestiona mediante la variable privada hv_apple_isa_vm_quota dentro del kernel XNU, y que puede sobrescribirse mediante argumentos de arranque
• Para eludir la verificación de AppleInternal de System Integrity Protection, se utiliza un procedimiento para compilar e iniciar con un kernel de desarrollo (Development Kernel)
• Tras la configuración, se logró ejecutar hasta 9 VM de macOS al mismo tiempo en UTM, Viable y Parallels
• Llama la atención que Apple haya dejado en el kernel una función para sobrescribir el límite de VM, y se plantean posibles mejoras futuras mediante herramientas de automatización o extensiones del kernel

---

Proceso para quitar el límite de 2 máquinas virtuales de macOS en Apple Silicon

• Al ejecutar máquinas virtuales de macOS con Virtualization.framework en una Mac basada en Apple Silicon, existe una restricción que solo permite ejecutar hasta 2 VM al mismo tiempo
  • Esta restricción está configurada conforme a la cláusula 2.B.iii del contrato de licencia de software (SLA) de macOS
  • Dicha cláusula permite ejecutar hasta 2 instancias de macOS únicamente para desarrollo, pruebas, uso de macOS Server o uso personal no comercial
• El análisis mostró que esta restricción está implementada en una zona privada del kernel (XNU), no en espacio de usuario
  • El kernel de Intel no contiene el mismo código, y en el kernel de Apple Silicon el grupo de funciones hv_vm_* se encarga del stack de virtualización
  • La variable hv_apple_isa_vm_quota dentro del código de inicialización hv_init() gestiona la cantidad de VM, incrementándose o decrementándose al crear o eliminar VM
  • En el kernel existen los argumentos de arranque hypervisor= y hv_apple_isa_vm_quota=; el segundo permite sobrescribir el límite de VM
• En el kernel de lanzamiento, en lugar del argumento hypervisor, la restricción queda sujeta a la verificación AppleInternal de System Integrity Protection (SIP)
  • El argumento hv_apple_isa_vm_quota solo se aplica cuando está activada la bandera CSR_ALLOW_APPLE_INTERNAL
  • Para eludir esto, se utilizó el método de arrancar con el kernel de desarrollo (Development Kernel) de Apple

Compilación de la colección de kernel de desarrollo

• Es necesario descargar e instalar el Kernel Debug Kit (KDK) desde el sitio de Apple Developer
  • El KDK debe coincidir exactamente con la compilación de macOS del host; si no coincide, pueden producirse errores de enlace del kernel y de los kext, así como fallos de arranque
• Tras verificar la arquitectura del kernel con el comando uname, se usa kmutil create para generar una colección de kernel de desarrollo (VirtualMachine.kc)
  • En el ejemplo se usa macOS 14.0 (build 23A5301h) y el kernel T6020
  • La opción --variant-suffix development especifica el kernel de desarrollo e incluye varios repositorios de extensiones del sistema

Configuración de arranque del kernel de desarrollo

• Después de apagar la Mac, se arranca en modo de recuperación (recoveryOS) y se realiza la siguiente configuración desde Terminal
  1. Desactivar System Integrity Protection (csrutil disable)
  2. Quitar la restricción de argumentos de arranque (bputil --disable-boot-args-restriction)
  3. Especificar la colección de kernel personalizada (kmutil configure-boot)
  4. Configurar los argumentos de arranque (pasados con el comando nvram)
     • kcsuffix=development : arranque con kernel de desarrollo
     • hypervisor=0x1 : activa funciones especiales del stack de virtualización
     • hv_apple_isa_vm_quota=0xFF : establece el máximo de VM en 255
• Después de reiniciar, puede verificarse la aplicación con sysctl kern.osbuildconfig y nvram boot-args

Resultado de la ejecución de múltiples VM

• Tras completar la configuración, se realizaron pruebas con soluciones basadas en Virtualization.framework como UTM, Viable y Parallels
  • En una MacBook Pro M2 Pro se logró ejecutar 9 VM de macOS al mismo tiempo
  • El sistema seguía funcionando a un nivel todavía utilizable para pruebas

Momento en que se añadió la función y estructura interna

• El argumento de arranque hv_apple_isa_vm_quota se añadió junto con el stack de Virtualization desde macOS 12 Monterey
  • En versiones posteriores, incluida macOS Sonoma, la verificación AppleInternal sigue presente
  • Esto confirma que Apple mantiene varias funciones privadas dentro de XNU

Precauciones al actualizar el sistema operativo

• Al usar una colección de kernel personalizada, la función de actualización automática del sistema operativo queda desactivada
  • Después de una actualización se producen errores, por lo que es necesario restaurar la colección de kernel predeterminada
  • En modo de recuperación, puede volver al kernel predeterminado creando una nueva política de arranque con bputil
  • Ejemplo: usar las opciones bputil --full-security o --disable-boot-args-restriction

Cierre e ideas de mejora futura

• Se verificó experimentalmente la forma en que Apple implementa la restricción de VM y un método no oficial para quitarla
  • Aunque el equipo de Virtualization no lo documenta oficialmente, llama la atención que hayan dejado en el kernel una función para sobrescribir el límite de VM
• Posibles mejoras futuras
  • Desarrollo de una herramienta para automatizar la compilación de KC y el arranque
    • Soporte para generar automáticamente la colección de kernel de desarrollo por host y configurar el modo de recuperación
  • Implementación de una función para sobrescribir la variable hv_apple_isa_vm_quota mediante una extensión del kernel (kext)
    • Explorar la posibilidad de quitar la restricción sin arrancar con un kernel de desarrollo
• Como próximo tema de investigación, se planea explorar la posibilidad de registrar DEP y sobrescribir el número de serie en VM de Apple Silicon

[GN⁺]

Opiniones de Hacker News

• Este tipo de límite que se aplica igual a todas las Mac es demasiado irracional
  Si compraste una Mac más potente, deberías poder virtualizar más instancias de macOS
  Por ejemplo, algo como limitar a 2 en la M5, 4 en la M5 Pro y 8 en la M5 Max sonaría razonable

  • Ni siquiera entiendo por qué poner un límite en primer lugar
    El rendimiento del hardware ya es un límite natural, así que el usuario se detendría por su cuenta
  • Esto parece más una cuestión de negocio que de recursos
    Lo más probable es que sea una medida para impedir servicios baratos de Mac VPS
  • Esto no es una limitación de hardware, sino una pelea contra la preocupación de Tim Cook por las ventas
  • Si compras una licencia de Windows 11 Pro por 100 dólares, el límite de VM es 1024
    Hyper‑V puede ejecutar hasta 1024 VM al mismo tiempo si el hardware lo soporta
    Incluso en mi pequeña laptop Windows ARM puedo correr 4 sin problemas
  • De verdad es ridículo
    Ejecuté una VM para probar openclaw, pero me desconcertó que el acceso a iCloud y App Store estuviera restringido

• Es interesante que Mykola Grymalyuk entró a trabajar en Apple dos años después de escribir esta entrada de blog
  Me hace pensar en el meme de “o mueres como héroe…”

• Desde la M3 en adelante se pueden correr VM anidadas usando Hypervisor.framework / Virtualization.framework
  Sería bastante divertido si eso pudiera servir para saltarse esta limitación

  • Si no recuerdo mal, solo se permite anidación con invitados Linux
    macOS solo llega a un nivel, así que no se puede iniciar otro invitado macOS dentro de un invitado macOS
  • Si cada VM pudiera correr 2 VM, entonces hasta se podría hacer una cadena infinita de VM
    Me da flojera, pero ojalá alguien lo pruebe

• De verdad me intriga por qué Apple puso este límite

  • El modelo de negocio de Apple es vender hardware y software juntos
    Las ventas de hardware financian el desarrollo del software, así que no quieren que alguien use macOS sin haber comprado hardware
  • macOS tiene muchas restricciones al usuario de este tipo
    Para Apple, mantener el control es más importante que la libertad del usuario
  • Quizá también sea una forma de evitar que se opere una granja de cuentas en línea (identity farm) con una sola Mac

• Sorprende que se pueda compilar un kernel personalizado, arrancarlo y hasta levantar la GUI

• El artículo en sí es realmente interesante, pero es raro usar como plataforma de desarrollo algo con este tipo de limitaciones arbitrarias

  • Me pregunto si Apple ha sido una plataforma de desarrollo seria en los últimos 20 años
    Muchos desarrolladores la usan por el hardware de gama alta, pero macOS siempre ha sido “casi Linux, pero bajo el control de una empresa centrada en iTunes”

• Dicen que usar una colección de kernels personalizada en Apple Silicon hace imposible recibir actualizaciones automáticas del sistema operativo
  Pero quizá eso incluso sea una bendición disfrazada

• Me pregunto si esto también podría funcionar en lume
  Actualmente tiene una limitación parecida

  • Parece que sí
    Tengo entendido que lume es un wrapper delgado sobre el Virtualization.framework de Apple

• Escuché que también se puede sin kernel personalizado si desactivas SIP y configuras argumentos de arranque

  • Si eso es cierto, entonces es un consejo infravalorado

• ¿Apple limitó las VM a 2?

  • Sí, por licencia las VM de macOS están limitadas a 2
    Los invitados con otros sistemas operativos se pueden ejecutar sin límite