En novembre 2024, la développeuse Yureka Lilian a fait l’acquisition d’un Mac mini équipé de la puce M4. Au vu du rythme auquel les générations précédentes d’Apple Silicon avaient été apprivoisées, voir tourner un système d’exploitation libre semblait à portée de main. Il aura pourtant fallu 17 mois pour que le processeur de la machine parvienne enfin à démarrer l’ensemble de ses cœurs jusqu’à une interface en ligne de commande.
Apple neutralise les sondes des machines virtuelles
Ces dernières années, la communauté open source avait rodé une méthode efficace pour rétroconcevoir les puces Apple : faire tourner macOS au sein d’une machine virtuelle sur mesure afin d’intercepter les traces MMIO (entrées/sorties projetées en mémoire) échangées entre les pilotes du système et le matériel. Il suffisait alors d’observer les instructions transmises par macOS pour les reproduire sous Linux.
Avec le M4, Apple a éteint la lumière. Cette génération applique obligatoirement le mécanisme SPTM (Secure Page Table Monitor) pour verrouiller le noyau du système, rendant inopérante l’ancienne méthode de traçage mémoire. Faire tourner le système dans un hyperviseur aurait exigé des refontes architecturales colossales. La communauté open source n’a eu d’autre choix que d’affronter une boîte noire dépourvue de la moindre documentation.
Figure : Publication de Sven Peter sur Mastodon en avril 2025. Source : yuka.dev
Déminer le terrain en affichant un seul caractère
Une fois leurs outils d’analyse sophistiqués hors service, les développeurs ont dû se rabattre sur la méthode empirique la plus élémentaire. Le chargeur de démarrage m1n1 ne pouvait s’exécuter sur le M4 que dans son mode BRINGUP le plus dépouillé. La moindre tentative d’initialisation de certains composants ou d’écriture dans l’adresse de base de réinitialisation entraînait un plantage immédiat.
Yureka Lilian a alors fait appel à une routine assembleur minimale, modifiée pour n’afficher qu’un unique caractère a, injectée aux tout premiers instants du démarrage du noyau. En déplaçant ce fragment de code et en procédant par dichotomie, elle est parvenue à isoler l’instruction exacte à l’origine du crash. Les registres verrouillés mis en évidence par ce procédé n’ont été discrètement débloqués que lors de mises à jour ultérieures du micrologiciel.
Figure : Linux démarrant pour la première fois sur un shell sur Mac mini M4, hyfetch affichant Apple Mac Mini (M4, 2024) comme hôte. Source : yuka.dev
La mise en veille efface brutalement les registres
Les crashs initiaux au démarrage n’étaient qu’un préambule. Le véritable obstacle résidait dans une particularité matérielle de la puce M4 défiant le bon sens architectural.
Les puces Apple Silicon précédentes intégraient un commutateur discret : lorsqu’une instruction de mise en veille en attente d’interruption était exécutée, le processeur écrasait les données de ses 32 registres d’usage général. À l’époque, les développeurs Linux avaient délibérément activé cette option pour bénéficier d’un sommeil plus profond et réduire la consommation, en prenant soin de sauvegarder et restaurer manuellement l’état des registres.
Figure : Informations système après le démarrage réussi de tous les cœurs vers le shell sur M4. Source : yuka.dev
Sur le M4, Apple a transformé cette remise à zéro en un comportement figé par défaut, impossible à désactiver. Cela viole directement la spécification officielle ARM64, qui stipule explicitement que les instructions de veille ne doivent en aucun cas entraîner la perte de l’état architectural. Les développeurs ont tâtonné longuement dans le noir avant d’en avoir la certitude : dès que ce processeur s’assoupit, la mémoire de ses registres est purement et simplement effacée.
Contourner le mur matériel à coups de NOP
Face à une conception matérielle aussi déroutante, la parade trouvée par la communauté s’est révélée d’une redoutable simplicité : en avril 2026, les développeurs ont remplacé toutes les instructions de veille du noyau par des instructions sans effet (NOP). Tous les cœurs du M4 ont enfin pu s’animer.
Plutôt que d’appliquer un bricolage risquant d’impacter d’autres environnements, ils ont soumis au noyau Linux principal une option d’amorçage précoce permettant au système de contourner les instructions de veille. Apple avait dressé un comportement non documenté en barrière infranchissable ; la communauté open source en a percé les arcanes à force de ténacité, allant jusqu’à faire accepter au noyau officiel des correctifs pour ces caprices matériels. Face à une puce hermétique et isolée, c’est une éclatante victoire de la persévérance.
Liens de référence :
- Billet de blog sur yuka.dev
- Actualités de la communauté Asahi Linux
