Asahi Linux en el Apple M4: arrancó pese al SPTM

⏱️ Lectura: 15 min

El 1 de diciembre de 2024, en un canal de IRC, alguien escribió una sola línea: «can confirm this state gives a working usb proxy». Detrás de ese mensaje estaba el primer paso real hacia correr Linux en un Mac mini con chip M4, un SoC que Apple diseñó específicamente para bloquear ese tipo de experimento.

📑 En este artículo

1. TL;DR
2. ¿Qué es Asahi Linux?
3. Por qué el M4 cambió las reglas del juego
4. Cómo funciona el arranque de Linux en Apple Silicon
5. El debugging por fuerza bruta: bisectar con un printf
6. Núcleos secundarios y el CPU que se olvida
   1. M1-M3 frente a M4: qué cambia para el bringup
7. Cómo empezar: probar Asahi Linux hoy
8. Casos de uso reales
9. Errores comunes y buenas prácticas en bringup de hardware nuevo
10. Comparativa con alternativas de bringup
11. Profundizando: SPTM y GXF por dentro
12. Preguntas frecuentes
    1. ¿Qué Mac puedo usar hoy con Asahi Linux?
    2. ¿Qué es m1n1 dentro del port libre para Mac con chip M?
    3. ¿Por qué SPTM complica correr Linux en Apple Silicon?
    4. ¿Es seguro intentar este proceso en mi propia Mac?
    5. ¿Cómo se sostiene económicamente el proyecto Asahi?
13. Referencias
    1. 📚 Artículos relacionados

Le tomó más de un año de trabajo intermitente, una consola serial y una técnica de debugging tan vieja como la programación misma: imprimir una letra y ver si aparece. Esta es la historia técnica de cómo Asahi Linux logró correr en el M4, documentada en detalle por su autora en su blog, y de paso, una lección completa sobre cómo arranca Linux en hardware ARM64 real.

TL;DR

• Asahi Linux arrancó en el Mac mini M4 pese al SPTM, saltando la inicialización de GXF y el RVBAR.
• Un print de una sola letra en head.S permitió bisectar el fallo hasta el código de inicialización del MMU.
• Sin stdout-path = serial0 en el device tree, el kernel arranca mudo y sin ninguna pista en consola.
• El mismo smp_start_offset usado en M1 a M3 logró encender los núcleos secundarios del M4.
• El Asahi Open Collective financia el trabajo de ingeniería inversa que hace posible este tipo de bringup.

¿Qué es Asahi Linux?

Asahi Linux es un proyecto de código abierto que adapta el kernel de Linux y su ecosistema de drivers para correr de forma nativa en las Mac con procesadores Apple Silicon, de M1 a M4, sin virtualización, replicando desde cero los drivers que Apple nunca documentó.

El proyecto nació poco después del lanzamiento del primer Mac con chip M1 en 2020 y desde entonces mantiene soporte estable para M1, M2 y M3. El trabajo se apoya en m1n1, un cargador de arranque y framework de ingeniería inversa que corre antes que Linux y que permite capturar, paso a paso, cómo macOS habla con el hardware que Apple no documenta. Sin esos registros capturados, no hay manera de escribir un driver correcto.

Por qué el M4 cambió las reglas del juego

Hasta el M3, el método de trabajo era directo: correr m1n1 como hipervisor debajo de macOS, dejar que macOS arranque con sus drivers originales y registrar cada acceso a memoria mapeada (MMIO) que esos drivers hacen. Esa traza se convierte después en la base del driver de Linux.

El M4 rompió ese flujo porque fue la primera generación de Apple Silicon en exigir SPTM (Secure Page Table Monitor), una capa de hardware pensada para blindar al kernel XNU de macOS contra exploits que manipulan tablas de páginas. Para que m1n1 siga pudiendo correr macOS como invitado bajo su hipervisor, necesita cambios profundos que van más allá de lo que un solo desarrollador puede resolver en meses. Para Asahi Linux, cada generación nueva de Apple Silicon es una carrera distinta contra las defensas que Apple suma a XNU.

Eso no cerró la puerta del todo. En paralelo al trabajo de hipervisor, la autora empezó a intentar arrancar Linux directamente en el M4, sin pasar por macOS: deshabilitando la seguridad estricta de arranque, instalando m1n1 como objeto de arranque personalizado desde el modo de recuperación de macOS, y conectando una consola serial para leer los logs en crudo.

Cómo funciona el arranque de Linux en Apple Silicon

En cualquier SoC ARM64, cada núcleo de CPU arranca ejecutando la dirección de memoria que tiene cargada en su RVBAR (Reset Vector Base Address Register), un registro por núcleo que define dónde empieza a correr código al encenderse. En Apple Silicon, el firmware de Apple (iBoot) arranca primero, carga m1n1 como cargador intermedio y m1n1 después escribe el RVBAR con la dirección del siguiente objeto a ejecutar, típicamente el propio kernel de Linux.

En el M4 ese paso falló. Al intentar escribir el RVBAR, el núcleo se colgaba. La solución, después de revisar el valor existente, fue simplemente no escribir nada: el registro ya contenía la dirección correcta. Algo parecido pasó con GXF (Guarded Execution Framework), una función de Apple relacionada con modos de ejecución protegidos que en los M4 y posteriores viene deshabilitada en el arranque crudo. m1n1 solo necesitaba volver condicional esa inicialización y saltarla en estos chips.

flowchart LR
    A["iBoot (firmware de Apple)"] --> B["m1n1 (bootloader / hypervisor)"]
    B --> C["Device tree minimo: CPU + AIC"]
    C --> D["Kernel Linux (head.S)"]
    D --> E["MMU inicializado"]
    E --> F["UART mapeada y shell disponible"]

Con esos dos bloqueos resueltos, m1n1 lograba iniciar en modo BRINGUP y pasar el control a Linux. Pero el kernel seguía sin dar señales de vida: ningún mensaje aparecía en la consola serial pese a usar el parámetro earlycon, pensado justo para imprimir logs lo antes posible en el arranque.

El debugging por fuerza bruta: bisectar con un printf

Sin salida de consola, no había forma de saber en qué punto exacto fallaba el arranque. La solución fue la más antigua del oficio: tomar la rutina de impresión de caracteres de m1n1 (debug_putc), adaptarla para imprimir una sola letra, e insertarla cada vez más adelante en el código de arranque de Linux, en arch/arm64/kernel/head.S, hasta encontrar el punto donde la letra dejaba de aparecer.

El primer hallazgo fue revelador: la letra se imprimía bien hasta llegar al código de inicialización del MMU (la unidad de gestión de memoria). Ahí se cortaba, pero no porque el MMU fallara. El motivo era más sutil: la UART se accede por memoria mapeada (MMIO), y m1n1 mapea esa región en direcciones virtuales idénticas a las físicas. Linux no hace eso por defecto. Al activar el MMU, cada acceso pasa a resolverse contra las tablas de páginas del kernel, que todavía no tenían mapeada esa dirección. El resultado era un acceso a memoria no mapeada, silencioso desde afuera.

sequenceDiagram
    participant Dev as Desarrolladora
    participant Kernel as Kernel Linux
    participant UART as Consola serial
    Dev->>Kernel: inserta debug_putc("a") en head.S
    Kernel-->>UART: imprime "a" antes del MMU
    Note over Dev,Kernel: tras activar el MMU, silencio total
    Dev->>Kernel: agrega mapeo 1:1 de la region MMIO
    Kernel-->>UART: vuelve a imprimir "a"
    Dev->>Kernel: mueve el print mas adelante
    Kernel-->>UART: se cuelga en un registro del AIC

Agregar ese mapeo 1:1 en las tablas de páginas iniciales de Linux devolvió la salida por consola, y la bisección pudo avanzar: el siguiente corte aparecía durante la inicialización del controlador de interrupciones AIC, en una escritura al registro específico de Apple SYS_IMP_APL_VM_TMR_FIQ_ENA_EL2, vinculado a virtualización. Comentar esa escritura destrabó el arranque hasta una shell funcional. Versiones posteriores de iBoot desbloquearon ese registro, así que el parche dejó de ser necesario.

Quedaba un problema aparte: por qué earlycon no había mostrado nada desde el inicio. La causa era mucho más simple que todo lo anterior: al device tree armado a mano le faltaba la propiedad stdout-path = "serial0". Sin ella, el kernel no sabe cuál de sus nodos serie usar como consola temprana, aunque el hardware esté perfectamente inicializado. Agregarla destapó volcados de registros y stack traces completos en cada fallo posterior.

💭 Clave: el bringup de Linux en hardware nuevo casi nunca empieza leyendo un datasheet. Empieza capturando, con un hipervisor, cada acceso a memoria que hace el sistema operativo original, y después reproduciendo ese comportamiento a ciegas hasta que algo responde.

Núcleos secundarios y el CPU que se olvida

Con un núcleo arrancando, faltaba encender los demás. m1n1 no estaba iniciando los núcleos secundarios porque le faltaba smp_start_offset, un valor hardcodeado sin el cual la rutina smp_init se salta por completo. Reutilizar el offset conocido de los M1 a M3 funcionó también en el M4, y los núcleos extra arrancaron.

Ahí apareció el problema que le da nombre a la historia original: «the forgetful CPU», el CPU olvidadizo. Los Apple Silicon anteriores ya tenían comportamientos particulares alrededor de la instrucción WFI (Wait For Interrupt), que pone a un núcleo en bajo consumo hasta que llega una interrupción. En ciertos estados, un núcleo que entra en WFI puede perder contexto que Linux asume persistente, generando cuelgues que no tienen relación aparente con el código que se ejecutó justo antes. Rastrear ese tipo de falla exige el mismo método que el resto del artículo: aislar la condición exacta con prints y comparar contra el comportamiento documentado (parcialmente) de generaciones previas.

M1-M3 frente a M4: qué cambia para el bringup

Cómo empezar: probar Asahi Linux hoy

Si querés probar Asahi Linux vos mismo, el soporte estable e instalable hoy cubre Mac con M1, M2 y M3; el M4 sigue en desarrollo activo, como muestra todo lo anterior. En una Mac compatible, la instalación se hace desde una sesión de macOS, no desde Windows ni desde Linux, porque el instalador reparticiona el disco interno y coexiste con macOS:

curl https://alx.sh | sh

Ese comando descarga el instalador oficial y guía paso a paso la creación de una partición para Linux junto a macOS. Antes de correrlo conviene tener una copia de seguridad completa: el instalador toca la tabla de particiones del disco interno. La guía de instalación actualizada, con los requisitos exactos de espacio y modelos soportados, vive en la documentación oficial del proyecto.

No hay variante para Windows o Linux como sistema anfitrión porque el objetivo del instalador es justamente reemplazar parte de una instalación de macOS existente, no crear un medio de arranque externo.

Casos de uso reales

Más allá de la curiosidad técnica, tener Linux nativo en Apple Silicon resuelve problemas concretos. Equipos que ya compraron hardware Apple por su eficiencia energética pueden correr cargas de servidor, contenedores o pipelines de desarrollo sin pasar por una capa de virtualización, con acceso directo a la GPU y al Neural Engine según el nivel de soporte de cada generación.

También sirve como terreno de práctica real de ingeniería de sistemas: pocos proyectos exponen tan claramente el proceso completo de llevar un kernel a un SoC cerrado, desde el primer registro que no responde hasta el shell funcional. Universidades y comunidades de sistemas operativos usan el código y los logs públicos de Asahi Linux como material de estudio de bajo nivel.

Errores comunes y buenas prácticas en bringup de hardware nuevo

La historia del M4 deja lecciones que aplican a cualquier port de un sistema operativo a hardware nuevo, no solo a Apple Silicon.

• Mapeo de MMIO temprano: si tu bootloader mapea la UART en identidad y tu kernel no, vas a perder la consola justo cuando más la necesitás, al activar el MMU. Verificá que las tablas de páginas iniciales incluyan la región de periféricos que usás para debug.
• Device tree mínimo pero completo: un device tree «mínimo» que omite stdout-path no es mínimo, es incompleto. Sin esa propiedad, earlycon no tiene forma de saber qué nodo usar.
• Bisección manual cuando no hay otra opción: sin JTAG ni debugger funcional, mover un print línea por línea sigue siendo una técnica válida y rápida para acotar un fallo a una función concreta.
• No asumas que un registro bloqueado necesita más código: a veces la solución correcta es directamente no escribirlo, como pasó con el RVBAR del M4, que ya traía el valor correcto.

Comparativa con alternativas de bringup

El camino de m1n1 (hipervisor que traza el comportamiento de macOS) no es la única forma de portar un sistema operativo a hardware sin documentación pública, pero es la que mejor funcionó en Apple Silicon porque permite comparar byte a byte contra un sistema operativo que sí funciona. Proyectos de bringup en placas ARM de otros fabricantes muchas veces dependen en cambio de documentación parcial del fabricante, datasheets filtrados o colaboración directa con el vendor, algo que Apple no ofrece.

Frente a opciones como coreboot, pensadas para reemplazar firmware en plataformas x86 más abiertas, el caso de Apple Silicon es más cercano a una ingeniería inversa completa desde cero: no hay specs oficiales de los controladores, solo el comportamiento observado de macOS corriendo bajo el hipervisor.

Profundizando: SPTM y GXF por dentro

SPTM es, en esencia, una capa de hardware y firmware que se interpone entre el kernel XNU y las tablas de páginas de memoria, de forma que ni siquiera un XNU comprometido pueda reescribir esas tablas sin pasar por un monitor separado y más privilegiado. Apple documenta el enfoque general de este tipo de protecciones en su guía de seguridad de plataforma. Para Asahi Linux, el efecto práctico es que el viejo truco de correr macOS como invitado bajo m1n1 y mirar qué hace, ya no alcanza sin antes lograr que SPTM acepte un hipervisor distinto al de Apple.

flowchart TD
    A["Nucleos ARM64 del M4"] --> B["SPTM: Secure Page Table Monitor"]
    B --> C["Kernel XNU de macOS"]
    B --> D["GXF: Guarded Execution Framework"]
    subgraph HardwareM4["Hardware del M4"]
    A
    B
    D
    end
    C -. "no puede alterar tablas de paginas sin pasar por SPTM" .-> B

⚠️ Ojo: replicar estos pasos en una Mac real implica deshabilitar protecciones de arranque y editar el firmware de bajo nivel. Un error en el paso equivocado puede dejar el equipo sin arrancar ni siquiera macOS. Esto es trabajo de bringup activo, no un tutorial de uso diario.

📖 Resumen en Telegram: Ver resumen

Tu próximo paso: cloná el repositorio de m1n1 y leé el código de debug_putc para entender, línea por línea, cómo se imprime un carácter antes de que exista cualquier driver de consola.

Preguntas frecuentes

¿Qué Mac puedo usar hoy con Asahi Linux?

Cualquier Mac con chip M1, M2 o M3 tiene soporte estable e instalable. El M4 todavía está en fase de bringup experimental, sin instalador listo para uso diario.

¿Qué es m1n1 dentro del port libre para Mac con chip M?

Es el cargador de arranque e hipervisor que corre antes que Linux, usado tanto para chainloadear el kernel como para capturar el comportamiento de los drivers originales de macOS.

¿Por qué SPTM complica correr Linux en Apple Silicon?

Porque protege las tablas de páginas del kernel XNU con un monitor de hardware separado, lo que impide usar el truco clásico de virtualizar macOS para espiar sus drivers sin adaptar antes el hipervisor a esa nueva capa.

¿Es seguro intentar este proceso en mi propia Mac?

No sin experiencia previa. El proceso implica deshabilitar seguridad de arranque y escribir en registros de bajo nivel; un paso en falso puede dejar el equipo sin arrancar ningún sistema operativo.

¿Cómo se sostiene económicamente el proyecto Asahi?

En buena parte con donaciones al Asahi Open Collective, que financian el tiempo dedicado a este tipo de ingeniería inversa de hardware no documentado.

Referencias

• Blog de Yureka Lilian: relato original y completo del bringup de Linux en el Mac mini M4.
• Asahi Linux: sitio oficial del proyecto, documentación de instalación y hardware soportado.
• Repositorio de m1n1 en GitHub: código fuente del bootloader e hipervisor usado en el bringup.
• Asahi Open Collective: fondo de donaciones que sostiene el desarrollo del proyecto.
• Documentación del kernel Linux sobre device tree: referencia oficial del formato usado para describir el hardware al arrancar.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

Imagen destacada: Foto de BoliviaInteligente en Unsplash