アサヒLinux進捗報告: Linux 7.2

2026年8月27日原文(asahilinux.org)

概要

Linux 7.2 リリースとAsahi Linuxの最新進捗報告
Apple Silicon の電源管理とプラットフォーム特有の課題
SPTM による新しいセキュリティ機構とそのLinux対応
M3シリーズ への対応状況と新ハードウェアサポート
各種 ドライバー開発 やリバースエンジニアリングの進展

Linux 7.2リリースとAsahi Linux進捗報告

Linux 7.2 のリリース、Asahi Linuxの最新進展
Apple Silicon の電源管理インフラの複雑さ
- SMC、PMGR、PMPなど複数のハードウェアブロックによる制御
CPUコアのスリープ制御 がバッテリー寿命改善の主要障害
ARMコアの基本的なスリープは WFI命令 による
- WFIは実行停止だが、コアは電源ON・状態保持
- Appleコアには“deep WFI”モードも存在
ベンダー固有の電源管理 が多発
- 標準化のため PSCI （Power State Coordination Interface）を推奨
Apple Silicon はEL3未実装のため、PSCIの標準的な利用不可
- SMCやHVC命令が使えず、カスタムcpuidleドライバが必要
m1n1 をファームウェア的に活用し、UEFI Runtime Services経由のPSCI実装を開発中
- Svenによるパッチが既にRFCとして公開

cpuidleとWFI制御の最新状況

Apple Silicon のWFIループはデフォルトで状態保持しない
- ARM仕様ではWFI時に全状態保持が必須
M1〜M3はchicken bitsでコアごとに状態保持設定が可能
M4以降はAppleがchicken bitsをロック し、微調整不可に
- M4ではWFIでコア状態消失・クラッシュ問題が発生
Yureka がカーネルコマンドラインパラメータでアイドルループ挙動を制御可能に
- 初期化中のクラッシュ防止、cpuidleドライバロード後に状態保存対応

Apple Siliconの新セキュリティ機構SPTM

Apple はプラットフォームセキュリティ強化に注力
SPTM （Secure Page Table Monitor）導入
- メモリ管理をハードウェアレベルで分離・保護
以前の PPL （Page Protection Layer）から進化
- PPLは攻撃者に突破され、SPTMはGXF（Guarded Execution Framework）上で動作
SPTM はGL2で起動し、ページテーブル管理を独占
- XNUカーネルはSPTMとIPCで通信、接続失敗時は即パニック
Asahi Linux 開発チームはm1n1ハイパーバイザでSPTMをエミュレート
- SvenによるSPRRとGXFのリバースエンジニアリング成果
- M4以降でもXNUトレース・新ハードウェアサポート継続可能に

M3シリーズ対応状況

WebカメラISP はM3 Maxで初期化メッセージが1つ追加されたのみ
- chaos_princessがLinuxドライバを修正し、全M3でカメラ対応
内蔵マイク は“High Frequency”デシメータ追加
- 新係数・大きめの初期化メッセージに対応し、全M3でマイク対応
ATCPHY （USB3/DisplayPort/Thunderbolt制御）はN3プロセス対応で初期化手順変更
USBポートコントローラ はM3 Pro/MaxでCD3217（ACE2）からACE3へ
- ACE3はSPMIバス使用、I2Cから移行
- mildsunriseとchaos_princessが逆アセンブルし、USB 3.0/Thunderbolt対応を実現
GPU/ディスプレイコントローラのファームウェアABI も変更予想
- 各世代ごとに特定macOSバージョンをターゲットとする運用

今後の展望とまとめ

Apple Siliconの新機能・仕様変更に迅速対応する Asahi Linux開発体制
リバースエンジニアリング とカーネルパッチ開発による互換性維持
Linux 7.2 とともに、今後も新ハードウェア・機能対応を拡大予定

Hackerたちの意見

いつもすごい進展だね。数人がここ数年でどれだけのことを成し遂げられるかを見るのが楽しいよ。時には不安定な砂の上で作業してるのにね。

そうだね、va-apiはv4l2-requestsには合わないってわかるよ。デコードされたビットストリームをそのままドライバーに渡すんじゃなくて、いくつかのコーデックのために事前に計算したりするから、v4l2-requestsは主にビットストリームから解析された元の情報を期待してるんだ。

mildsunriseとchaos_princessの協力のおかげで、ACE3はCD3217とほぼ同じレジスタセットを持っていることがわかったよ。ただ、I2Cでアドレス指定される代わりにSPMIインターフェースでラップされてるんだ。SPMIインターフェースとACE3自体は今、Asahi Linuxで動いていて、M3シリーズの全デバイスにUSB 3.0とThunderboltのサポートをもたらしているよ。M3 Pro MBPを手に入れたとき、最終的にはLinuxをインストールするつもりで買ったんだ。振り返ってみると、部分的なLinux互換性を得るために必要な努力を本当に過小評価してたな。それだけに、Asahiの貢献者たちの仕事には感謝しかないよ！iOS開発のためにmacOSはインストールしたままにするけど（これは近いうちにやる予定）、それ以外はウェブブラウザとGhostty、そして良好なバッテリー寿命があれば十分なんだ。

このプロジェクトは本当に印象的でワクワクするね。リバースエンジニアリングと機能が確立されたら、電力管理が重要な課題になることを願ってる。バッテリー寿命は日常のMacBook使用にとって大きな差別化要因になるし、伝統的にLinuxはプロプライエタリで高度に調整されたドライバーが不足してるせいで、そこがひどかったからね。

└

こういう調整がこれらのデバイスの実用的な寿命内に起こる可能性はどれくらいあるんだろう？もう何年も経ってるし、Linuxは新しいモデルでは機能が完全じゃないからね。AppleのOSSに対する無関心は、あまり希望を持たせてくれないよ。

M3のブートローダーがAsahiのデバッグセットアップといろいろ非互換だったことが、M1やM2よりもずっと遅くなるんじゃないかと心配してたんだ。でも、どうやらそうじゃなかったみたいだね。少なくとも、もうそうならないみたい。

└

一度それを乗り越えたら、あまり悪くなかったみたいだね。もっとたくさんの非互換性が待ってたかもしれないのに。

└

デバッグの非互換性があったプロセッサのバージョンはM4だったと思います。

Asahiチームの素晴らしい仕事には本当に尊敬してるけど、IntelやAMDが電力効率で追いついてきてるペースを考えると、Mシリーズのノートパソコンで本当にLinuxを使わなきゃいけない人がいるのか疑問に思うよ。Appleシリコンが他のどれよりも圧倒的に優れていた頃は明確な理由があったけど、Panther Lakeが出てきた今、AppleのリードがフルLinuxハードウェア互換性がリバースエンジニアリングされるまで数年待つ価値があるほど大きく続くのか、ちょっと疑問だね。

└

Appleがどれだけデバイスをサポートするかによるよね。サポートがデバイスの寿命に合ってれば、Asahiは必要ないかも。今、すべてのIntel Macは最後のmacOSバージョンを受け取ったから、そろそろAppleがM1世代について決断する時期だと思う。M1 Pro、Max、Ultra（あるいは16GB RAMのM1でも）まだまだ良い年数が残ってると思うよ。

└

でも、電力効率がAppleハードウェアにLinuxソフトウェアを使いたい主な理由じゃないんだ。ディスプレイの質、トラックパッドの質、全体的なフォルムファクター、そしてノートパソコンのRAM容量が多いことがAsahi Linuxを選ぶ主な理由だね。

└

でも、IntelとAMDが電力効率で追いついてきてるペースはどうなの？ほんとに？ Linuxが動くAMDやIntelのノートパソコンがM4 AirやM4 Max Proに匹敵するものってあるの？本当に気になるんだけど、見つけられなかったんだよね…

Hacker Newsで議論の続きを見る

ハクソク