Contexte et contraintes du SPTM

Le Mac mini M4, lancé en novembre 2024, introduit le Secure Page Table Monitor (SPTM), un mécanisme de durcissement du noyau XNU. SPTM empêche l’accès direct aux tables de pages, rendant impossible l’utilisation des traces MMIO capturées avec le hyperviseur m1n1, méthode qui avait servi aux générations M1‑M3. Cette nouveauté oblige à modifier profondément m1n1 pour pouvoir exécuter macOS sous hyperviseur, sinon le boot échoue dès l’initialisation du GPU (GXF) ou du registre RVBAR.

Adaptations du chargeur m1n1 et premiers pas sous Linux

Pour contourner ces verrous, l’auteur a désactivé le mode de sécurité strict, installé m1n1 comme objet de démarrage via la récupération macOS, puis a récupéré une console série. Deux registres sont bloqués : le module GXF, désactivé en mode raw boot, et le RVBAR, qui contient déjà la bonne adresse de démarrage ; les écritures sur ces registres ont donc été conditionnées ou omises. Après ces ajustements, m1n1 fonctionne en mode « BRINGUP », mais le noyau Linux ne produit aucun affichage.

Generic m1n1 uartproxy v1.4.17-61-ga24ff77

Le premier indice provient d’un test de debug_putc inséré dans le noyau. En imprimant le caractère « a » avant l’activation du MMU, l’auteur a confirmé que le code Linux était exécuté jusqu’au point « Vectoring to next stage ». Le problème suivant était l’accès MMIO au UART après l’activation du MMU : Linux ne crée pas de mappage 1:1 pour la zone MMIO, ce qui conduit à des accès à des adresses virtuelles non mappées et à un plantage.

Correction du mapping MMU et gestion du registre de virtualisation

En modifiant les tables de pages initiales pour ajouter un mappage identique (physique ↔ virtuel) de la zone MMIO, le debug_putc a continué de fonctionner jusqu’à l’initialisation du contrôleur d’interruption. L’étape suivante a révélé une écriture vers le registre propriétaire SYS_IMP_APL_VM_TMR_FIQ_ENA_EL2, lié à la virtualisation. Cette écriture provoquait un crash sur le M4, mais a été débloquée dans les versions récentes d’iBoot, rendant le contournement inutile.

earlycon=s5l,0x3ad200000

L’ajout du paramètre earlycon et de stdout-path = "serial0" dans l’arbre de périphériques a permis d’obtenir des traces de registre et des piles d’appels dès les premiers défauts, facilitant le diagnostic.

Activation des cœurs secondaires et problème du WFI

Initialement, m1n1 ne démarrait pas les cœurs secondaires car le champ smp_start_offset était absent. En réutilisant l’offset employé pour les SoC M1‑M3, tous les cœurs ont pu être lancés, mais un nouveau plantage est survenu lors de l’exécution de l’instruction WFI. Sur les générations précédentes, le « chicken bit » (registre ARM64_REG_CYC_OVRD_ok2pwrdn_force_mask) était désactivé, évitant la perte d’état architectural. Sur le M4, ce bit est verrouillé ou supprimé, et le WFI entraîne la remise à zéro des registres x0‑x31, violant la spécification ARM64. En remplaçant les instructions WFI et WFIT par des boucles d’attente actives, l’auteur a finalement réussi à démarrer Linux avec tous les cœurs actifs en avril 2026.