Im November 2024 kaufte die Entwicklerin Yureka Lilian einen Mac mini mit M4-Chip. Gemessen an der Geschwindigkeit, mit der frühere Generationen von Apple Silicon erschlossen wurden, schien die Portierung eines quelloffenen Betriebssystems nur eine Frage der Zeit zu sein. Doch es dauerte 17 Monate, bis die CPU des Rechners endlich mit allen aktiven Kernen bis zur Befehlszeile durchstartete.
Apple kappt die Diagnosefähigkeiten der virtuellen Maschine
In den vergangenen Jahren hatte die Open-Source-Community eine bewährte Strategie für das Reverse Engineering von Apple Silicon entwickelt: macOS lief in einer maßgeschneiderten virtuellen Maschine, um die MMIO-Zugriffe (Memory-Mapped I/O) zwischen den Systemtreibern und der Hardware aufzuzeichnen. Man beobachtete gewissermaßen, welche Befehle das System erteilte, und bildete dieses Verhalten in Linux nach.
Beim M4 drehte Apple jedoch das Licht ab. Diese Chip-Generation setzt zwingend auf SPTM-Mechanismen (Secure Page Table Monitor), um den Systemkernel abzusichern. Damit war das bisherige Verfahren des MMIO-Tracings schlagartig nutzlos. Um das System wieder in einer VM analysieren zu können, wären tiefgreifende Umbauten an der zugrunde liegenden Architektur nötig gewesen. Der Open-Source-Community blieb nichts anderes übrig, als sich an einem völlig undokumentierten Blackbox-System abzuarbeiten.
Abb.: Beitrag von Sven Peter auf Mastodon im April 2025. Quelle: yuka.dev
Fehlersuche Zeichen für Zeichen
Nachdem die komplexen Diagnosewerkzeuge lahmgelegt waren, blieb den Entwicklern nur der Rückzug auf elementarstes Trial-and-Error. Der Bootloader m1n1 ließ sich auf dem M4 lediglich im minimalen BRINGUP-Modus starten. Jeder Versuch, bestimmte Hardwarekomponenten zu initialisieren oder die korrekte Reset-Basisadresse zu beschreiben, führte zum sofortigen Absturz des Systems.
Yureka Lilian behalf sich mit einfachen Assembler-Routinen. Diese wurden so modifiziert, dass sie lediglich ein einzelnes Zeichen a ausgaben, und in die allererste Phase des Kernel-Starts eingeschleust. Indem die Position dieses Codes schrittweise verschoben und der Bereich per binärer Suche eingegrenzt wurde, ließ sich der auslösende Befehl schließlich lokalisieren. Gesperrte Register, die bei dieser Fehlersuche zutage traten, wurden erst durch spätere Firmware-Updates stillschweigend behoben.
Abb.: Linux bootet erstmals in eine Shell auf dem M4 Mac mini; hyfetch zeigt den Host als Apple Mac Mini (M4, 2024) an. Quelle: yuka.dev
Erzwungenes Löschen der Register beim Wechsel in den Ruhezustand
Die anfänglichen Boot-Abstürze waren nur die erste Hürde. Das eigentliche Hindernis war ein Hardware-Verhalten des M4-Chips, das allen architektonischen Konventionen widerspricht.
Frühere Chips der M-Serie verfügten über einen versteckten Schalter: Sobald ein Befehl zum Warten auf einen Interrupt ausgeführt wurde, löschte die CPU die Daten aller 32 universellen Register (General Purpose Registers). Um einen tieferen Ruhezustand und damit bessere Energieeffizienz zu erreichen, hatten die Linux-Entwickler diese Option damals bewusst aktiviert und die Registerinhalte vor und nach dem Schlafen manuell gesichert und wiederhergestellt.
Abb.: Systeminformationen nach dem erfolgreichen Booten aller CPU-Kerne in die Shell auf dem M4. Quelle: yuka.dev
Beim M4 machte Apple dieses Löschverhalten jedoch zum unveränderlichen Standard, der sich nicht mehr deaktivieren lässt. Dies verstößt unmittelbar gegen die offizielle ARM64-Spezifikation, die unmissverständlich vorschreibt, dass Wartebefehle keinen Verlust des Architekturzustands verursachen dürfen. Erst nach zahllosen Versuchen im Trüben konnten die Entwickler bestätigen: Sobald diese CPU ein kurzes Nickerchen macht, wird ihr Registergedächtnis gnadenlos ausradiert.
NOP-Befehle umgehen die Hardware-Barriere
Angesichts dieser eigensinnigen Hardware-Architektur fiel die Antwort der Community bemerkenswert pragmatisch aus: Im April 2026 ersetzten die Entwickler im Kernel sämtliche Ruhe-Befehle durch No-Operation-Befehle (NOP). Endlich starteten alle Kerne des M4 wie gewünscht durch.
Statt einen groben Patch zu wählen, der andere Systeme beeinträchtigen könnte, reichten sie beim Linux-Mainline-Kernel einen frühen Boot-Parameter ein, mit dem das System Ruhe-Befehle gezielt umgehen kann. Apple hatte undokumentiertes Verhalten als Hürde aufgebaut; die Open-Source-Community entschlüsselte das Rätsel durch unermüdliche Beharrlichkeit und erwirkte sogar Upstream-Patches für das proprietäre Design. Gegenüber einer geschlossenen Chip-Insel war dies ein Triumph, der allein durch Geduld errungen wurde.
Weiterführende Links:
- Blogbeitrag auf yuka.dev
- Neuigkeiten aus der Asahi Linux-Community
