Una desarrolladora logra arrancar Linux en el Apple M4

Lo esencial

• Una desarrolladora arrancó Linux en un Mac mini M4 comprado en noviembre de 2024, logrando el hito recién en enero de 2026
• El M4 es el primer Apple Silicon que exige SPTM, el monitor que blinda las tablas de páginas del kernel XNU de macOS
• Con la rutina debug_putc bisectó el arranque a mano hasta hallar que el kernel no mapeaba la UART tras activar la MMU
• El registro SYS_IMP_APL_VM_TMR_FIQ_ENA_EL2 frenaba el arranque; Apple lo desbloqueó después en nuevas versiones de iBoot
• El proyecto depende de donaciones vía Asahi Open Collective para seguir portando Linux a cada chip nuevo de Apple

Qué es Asahi Linux y qué cambia el chip M4

Asahi Linux es el proyecto de código abierto que porta Linux a las Mac con chips propios de Apple, desde el M1 hasta el M4. Su meta es que esas laptops y mini Mac corran un kernel Linux completo, con gráficos acelerados y Wi-Fi funcionando, sin depender de macOS.

El M4, lanzado a fines de 2024, rompió la racha de bringups rápidos del proyecto. Fue el primer chip de la familia en exigir SPTM de forma obligatoria, un cambio que afectó directamente al método que Asahi usaba para investigar el hardware.

SPTM: el guardián que Apple sumó para proteger macOS

SPTM (Secure Page Table Monitor) protege el kernel XNU de macOS contra ataques que modifican las tablas de páginas en memoria, una técnica común para escalar privilegios tras explotar una vulnerabilidad. En los chips M1 a M3 ese mecanismo era opcional; en el M4, Apple lo volvió obligatorio.

El problema para Asahi no fue SPTM en sí, sino el método de trabajo que usaban hasta entonces. Analizaban el hardware capturando el tráfico MMIO entre los drivers de macOS y el chip, usando el hipervisor m1n1 para espiar esas interacciones. Con SPTM activo, correr macOS dentro del hipervisor exige cambios mayores en m1n1 que todavía no estaban listos.

Registros bloqueados: GXF y RVBAR

La primera pelea fue con GXF (Guarded Execution Framework), una función de m1n1 que en los chips M4 y posteriores aparece deshabilitada en modo de arranque crudo. Intentar inicializarla provocaba un cuelgue inmediato; la solución fue hacer esa inicialización condicional y saltarla en estas máquinas.

El segundo bloqueo fue el RVBAR (Reset Vector Base Address Register), el registro que le indica a cada núcleo de CPU dónde empezar a ejecutar código al encenderse. m1n1 escribe ahí la dirección de entrada del kernel antes de arrancarlo. En el M4, escribir ese registro también colgaba el sistema, pero resultó que ya tenía el valor correcto: bastaba con no tocarlo.

Debug_putc: imprimir a mano cuando no hay logs

Con el kernel arrancando a ciegas, sin ninguna salida en la consola serial a pesar del parámetro earlycon, la desarrolladora recurrió a la técnica más antigua de la depuración: imprimir a mano, a nivel de assembly. Tomó la rutina debug_putc de m1n1 y la insertó al inicio del arranque de Linux para imprimir un solo carácter.

debug_putc:
    ldr   x1, =UART_BASE
    strb  w0, [x1, #UART_TX_OFFSET]
    ret

Esta rutina escribe directamente el byte en w0 al registro de transmisión del UART, sin pasar por ningún driver. Ver esa letra impresa confirmó que el kernel sí ejecutaba instrucciones; faltaba encontrar dónde se perdía la salida en el resto del arranque.

El bug de la MMU: una UART que deja de existir

Bisectando el código de arranque en arch/arm64/kernel/head.S, el carácter de prueba dejó de imprimirse justo después de inicializar la MMU. La MMU traduce cada acceso a memoria mediante tablas de páginas; una vez activa, el UART deja de estar en su dirección física original y pasa a depender de que exista una entrada virtual que apunte a él.

Pensalo como una mudanza: el cartero deja de encontrar tu casa si nadie actualiza la dirección en el sistema postal. m1n1 sí crea esa correspondencia uno a uno para el espacio MMIO, pero el kernel de Linux no la tenía en sus tablas iniciales. Al activar la MMU, cada escritura al UART caía en una región sin mapear.

Agregar esa entrada a las tablas de páginas iniciales devolvió la salida por consola, y el bisect siguió avanzando hasta el controlador de interrupciones. El propio repositorio de m1n1 en GitHub documenta este hipervisor, la pieza que permitió capturar cada uno de estos fallos paso a paso.

El device tree que faltaba: stdout-path

Con el kernel ya imprimiendo caracteres, faltaba el diagnóstico completo. El parámetro earlycon no mostraba nada útil porque el device tree mínimo armado para la prueba no declaraba qué puerto serial usar como salida estándar.

chosen {
    stdout-path = "serial0";
    bootargs = "earlycon=s5l,0x3ad200000";
};

Agregar la línea stdout-path = "serial0" fue la pieza faltante. A partir de ahí, cada caída del kernel mostró el volcado completo de registros y la pila de llamadas, en lugar de una consola muda.

El registro que frenaba las interrupciones

El siguiente obstáculo fue una escritura al registro SYS_IMP_APL_VM_TMR_FIQ_ENA_EL2, específico de la implementación de Apple y relacionado con virtualización. Comentar esa escritura destrabó el arranque y el kernel llegó, por fin, a una shell funcional.

Apple terminó desbloqueando ese registro en versiones posteriores de iBoot, el firmware de arranque de sus Mac. La escritura que antes colgaba el sistema hoy ya no hace falta comentarla.

Núcleos secundarios, la instrucción WFI y qué sigue

Con un núcleo arrancando, faltaba encender los demás. m1n1 no los inicia si falta smp_start_offset, un desplazamiento fijo en el código que smp_init necesita para saber dónde despertar a cada núcleo. Reusar el valor de los chips M1 a M3 funcionó, y los núcleos secundarios arrancaron.

Las CPU de Apple Silicon tienen particularidades conocidas alrededor de la instrucción WFI (Wait For Interrupt), que pone al núcleo en bajo consumo hasta la próxima interrupción. Versiones anteriores de Asahi ya habían documentado quirks similares en los chips M1 a M3, y resolver el equivalente en el M4 fue el último paso para tener los núcleos secundarios estables.

Vale aclarar el límite real de este logro: lo que arranca hoy es un kernel experimental con drivers mínimos, apenas CPU e interrupciones. Todavía faltan GPU, Wi-Fi y el resto de los periféricos antes de que el M4 llegue al instalador estable de Asahi Linux que usan los usuarios finales.

Cada bringup como este alimenta el trabajo de Asahi Linux, el proyecto que empuja ese soporte hacia el kernel oficial para que cualquier distribución lo herede sin parches adicionales. La propia autora del hallazgo pidió apoyar el trabajo del equipo a través del Asahi Open Collective, la vía con la que financian el tiempo de ingeniería que este tipo de ingeniería inversa exige.

El relato completo, con capturas de los logs de IRC originales y cada paso del bisect, está en el blog de Yureka Lilian.

📖 Versión extendida con más detalle: https://elsolitario.org/2026/10/03/asahi-linux-en-el-apple-m4-arranco-pese-al-sptm/?utm_source=telegraph&utm_medium=instant_view&utm_campaign=programacion