M4 Mac miniへのLinux導入：セキュリティ機能SPTMが大きな壁に

2024年11月、筆者はM4 Mac miniを購入し、Asahi Linuxによる迅速なサポートを期待していました。しかし、M4チップはM1〜M3世代とは異なり、SPTM（Secure Page Table Monitor）が必須化された初のApple Silicon世代であることが判明し、Linuxの導入は予想以上に困難な道のりとなりました。

SPTMはmacOSのXNUカーネルにおける脆弱性に対する堅牢化を提供する機能であり、これにより従来のM1n1ハイパーバイザを用いたMMIOトレースによる解析が困難になりました。

これまでのLinuxブートアップは、macOSのドライバとハードウェア間のやり取りを解析するためのMMIOトレースに大きく依存していました。しかし、SPTMの導入により、m1n1がmacOSをハイパーバイザ下で動作させるには大規模な変更が必要となり、これは個人のエンジニアにとって非常に高いハードルだったと筆者は述べています（Hacker News）。

予期せぬレジスタロックとデバッグの道のり

SPTMという大きな壁に直面しながらも、筆者はLinuxの起動を試みました。厳格なブートセキュリティを無効化し、m1n1をカスタムブートオブジェクトとしてインストール。シリアルコンソールを通じてログを検査するアプローチを採用しました。

初期の段階では、m1n1がBRINGUPモードでしか起動せず、GXFの初期化を試みると即座にクラッシュするという問題が発生しました。これはM4+ SoCにおいて、GXF機能が「raw boot mode」で無効化/ロックされているためであることが判明しました。同様に、CPUコアが起動時に実行を開始するアドレスを決定するRVBAR（Reset Vector Base Address Register）への書き込みもクラッシュを引き起こしましたが、これは正しい値が既に設定されていたため、書き込みをスキップすることで解決しました。

問題の特定には、debug_putcルーチンを使った「printlnデバッグ」という古典的な手法が用いられ、Linuxのブート初期段階、特にMMU初期化コードに問題があることが突き止められました。

数ヶ月間の試行錯誤の末、筆者はM4 Mac miniで動作するUSBプロキシの状態を確認することに成功。その後、最小限のデバイスツリーを作成し、Linuxカーネルをロードしたものの、出力が得られない状態が続きました。そこで、アセンブリルーチンを調整して特定の文字を出力させる「printlnデバッグ」を導入し、MMUの初期化コードに原因があることを特定しました（Hacker News）。

MMUとUARTアクセス：仮想アドレスの壁

MMU（Memory Management Unit）の初期化がCPUクラッシュの原因ではないかという推測がされましたが、実際には少し違いました。UART（Universal Asynchronous Receiver/Transmitter）はメモリマップドI/O（MMIO）を通じてアクセスされます。MMUが有効になると、全てのメモリアクセスは仮想アドレスを経由し、ページテーブルを通じて物理アドレスにマッピングされます。

m1n1はMMIOアドレス空間を同一の仮想アドレスで公開するためのマッピングを作成しますが、Linuxカーネルは独自のMMU初期化プロセスを持っており、この連携がうまくいかなかったようです。筆者の試行錯誤により、最終的には「Vectoring to next stage」の後に'a'が出力されるようになり、MMU初期化後のコード実行に成功したことが示されています。これは、MMUの初期化自体が問題なのではなく、その後のメモリアクセスやUART制御の方法に課題があったことを意味します。

MMUが有効になった後の仮想アドレスから物理アドレスへのマッピングが正しく行われないと、UARTへのアクセスが失敗し、デバッグ出力が得られない状況が発生します。

参考記事によると、Asahi Linuxの開発者であるSven Peter氏は、M4の「デバイスツリー」とMacBook Neoへの基本的なサポートのためのプルリクエストをLinux 7.4向けに送ったとのことです。これにより、M4デバイスにカーネルをインストールできる程度のサポートが提供される見込みですが、GPUサポートなど、OSを実用的にするためのさらなる開発が必要とされています（AppleInsider）。

エンジニア目線で見ると：M4への移行は従来の知識が通用しない可能性

今回のM4 Mac miniでのLinux起動成功は、特にローカルでLLMを動かすような用途を検討しているエンジニアにとって朗報だと感じます。GPUサポートがまだ不十分とはいえ、CPUベースでの動作確認は、将来的なAI推論環境としての可能性を示唆しているのではないでしょうか。しかし、SPTMの導入は従来のApple Silicon向けLinux開発のアプローチを大きく変えるもので、M1/M2/M3で培った知識やノウハウがM4世代ではそのまま通用しない可能性があると感じます。

特に、MMIOトレースに依存していた手法が使えなくなったことで、ハードウェアを直接制御するための低レベルな解析がより重要になります。これは、新しいSoCが出るたびに同様の課題に直面する可能性があるため、長期的な視点でのツールや手法の開発が求められるでしょう。

現状ではまだ実用段階ではありませんが、個人的なプロダクトでM4 Mac miniを活用する場合、まずはCPU中心の処理からスタートし、GPUサポートの進展を待つ形が良いのではないかと思います。Pythonバインディングなどが提供されれば、手持ちのAIモデルを動かしてみたいと強く思います。

懸念点としては、SPTMのようなセキュリティ機能が今後も強化され続ける可能性があり、オープンソースコミュニティによる解析がさらに難しくなるリスクも考えられます。Appleとしてはセキュリティ強化は当然の施策ですが、開発者としてはもう少し情報公開が進むことを期待したいところです。