En noviembre de 2024, la desarrolladora Yureka Lilian adquirió un Mac mini con chip M4. A juzgar por la rapidez con la que se habían doblegado las generaciones anteriores de Apple Silicon, lograr ejecutar un sistema operativo de código abierto parecía cuestión de tiempo. Sin embargo, hicieron falta 17 meses para que la CPU de esta máquina consiguiera finalmente arrancar con todos sus núcleos hasta una línea de comandos.
Apple ciega las sondas de las máquinas virtuales
Durante los últimos años, la comunidad de código abierto había consolidado una metodología eficaz para la ingeniería inversa de los chips de Apple: ejecutar macOS dentro de una máquina virtual personalizada para capturar las trazas de MMIO (E/S mapeada en memoria) entre los controladores del sistema y el hardware. En esencia, bastaba con observar cómo macOS impartía órdenes al hardware y reproducir esa misma lógica en Linux.
Con el M4, Apple apagó las luces. Esta generación introdujo de forma obligatoria el mecanismo SPTM (Secure Page Table Monitor) para blindar el núcleo del sistema, inutilizando por completo el método tradicional de rastreo en memoria. Conseguir que el sistema funcionara bajo un hipervisor exigía reestructuraciones titánicas de la arquitectura base. La comunidad se vio obligada a medirse cuerpo a cuerpo contra una caja negra carente de toda documentación.
Figura: Publicación de Sven Peter en Mastodon en abril de 2025. Fuente: yuka.dev
Localizando fallos imprimiendo un solo carácter
Inutilizadas las herramientas complejas de reconocimiento, los desarrolladores no tuvieron más remedio que retroceder al ensayo y error más elemental. El cargador de arranque m1n1 en el M4 solo conseguía iniciar en el modo mínimo de BRINGUP. Bastaba con inicializar ciertos periféricos o escribir en la dirección base de reinicio teóricamente correcta para que el equipo colapsara de inmediato.
Yureka Lilian recurrió a rutinas básicas en ensamblador. Modificó el código para que imprimiera únicamente el carácter a y lo insertó en los primeros compases del arranque del núcleo. Moviendo la posición de este fragmento y aplicando búsqueda binaria para estrechar el cerco, localizó finalmente la instrucción exacta que detonaba el fallo. Los registros bloqueados que salieron a la luz durante este proceso no se subsanaron hasta que una actualización de firmware posterior los liberó discretamente.
Figura: Linux arrancando por primera vez en una shell en un Mac mini M4, con hyfetch identificando el equipo como Apple Mac Mini (M4, 2024). Fuente: yuka.dev
El reposo del chip borra forzosamente los registros
Los bloqueos iniciales en el arranque fueron solo el aperitivo. El verdadero escollo para los desarrolladores radicaba en un comportamiento del hardware del M4 que desafía toda lógica arquitectónica.
Las primeras generaciones de la serie M contaban con un interruptor oculto: al ejecutarse una instrucción de espera de interrupción para entrar en reposo, la CPU ponía a cero el contenido de sus 32 registros de propósito general. En aquel momento, los desarrolladores de Linux optaron deliberadamente por habilitar ese interruptor a cambio de un reposo más profundo y un menor consumo energético, encargándose de guardar y restaurar los datos manualmente antes y después de cada suspensión.
Figura: Información del sistema tras arrancar exitosamente todos los núcleos en la shell en el M4. Fuente: yuka.dev
En el M4, sin embargo, Apple convirtió ese borrado en un diseño predeterminado e imposible de desactivar. Esto contraviene frontalmente la especificación oficial de ARM64, que exige de forma explícita que las instrucciones de reposo no conlleven la pérdida del estado arquitectónico. Los desarrolladores necesitaron meses de tanteo a ciegas para constatar la anomalía: en cuanto este procesador se toma un respiro, su memoria en registros queda fulminada.
Sustituir por NOPs para esquivar la barrera de hardware
Ante un diseño de hardware tan implacable, la solución de la comunidad fue sumamente pragmática: en abril de 2026, los desarrolladores reemplazaron todas las instrucciones de reposo del núcleo por instrucciones vacías (NOP). Por fin, todos los núcleos del M4 comenzaron a operar con éxito.
En lugar de aplicar un parche indiscriminado que pudiera comprometer otros entornos, remitieron al núcleo principal de Linux una opción de arranque temprano que permite al sistema esquivar deliberadamente las instrucciones de suspensión en este hardware. Apple convirtió un comportamiento no documentado en un obstáculo infranqueable; la comunidad de código abierto lo descifró a base de perseverancia e impulsó cambios en el núcleo upstream para amparar diseños atípicos. Ante un ecosistema cerrado de silicio, fue una victoria conquistada a pulso de pura paciencia.
Enlaces de referencia:
- Entrada de blog en yuka.dev
- Actualizaciones de la comunidad Asahi Linux
