Apple Silicon の紹介
2025/3/9時点のintroductionの翻訳
訳注: - プロジェクトページへのリンクは対応する日本語訳ページへのリンクに置き換え - Appleの用語はAppleセキュリティ文書の訳語に従います
はじめに¶
この文書は、Apple Silicon (M1 以降) Mac のブートエコシステム (以下『AS Mac』) について、オープン OS とどのように相互運用するかについて 説明することを目的としています。
これは、LinuxやBSDやその他の OS ディストリビューションやブート関連コンポーネントの開発者やメンテナ、およびこのプラットフォームに 興味を持つユーザを対象としており、その目標は過剰な技術的詳細を掘り下げることなく全体像をカバーすることにあります。詳細については、 他のページに任せます。また、macOS にのみ関係する詳細 (カーネル拡張がどのように動作しロードされるかなど) は省略します。
ここに書かれている情報は、システムファームウェアと macOS バージョン 12.0 (Monterey) 以降でどのように動作するかに基づいています。 M1 Macの発表から1年間は急激なデザインチェンジが繰り返されてきました。11.x以前のファームウェアも使用可能ですが、時代遅れで様々なバグがあり、 これらの変更を網羅しようとすると、物事があまりにも混乱することになります。オープンOSを実行したいユーザーは、実用上の理由から、macOS 12.1以降の システムファームウェアを実行することを期待しています（ただし、macOS自体は古いバージョンがインストールされているかもしれません）。
一般的な質問やフィードバックがある場合は OFTC の #asahi に、開発者で技術的な議論をしたい場合は #asahi-dev に ping してください (より詳しい情報)。
設計目標¶
AS Macは以下の設計目標を掲げています:
- macOSのために製造
- 他のOSへの開放
- セキュアブートの義務化（ユーザー制御可能）
- 物理的にアクセスできる攻撃者に対しても安全
- サプライチェーン攻撃耐性
- 深層防護（コプロセッサ/ファームウェアを盲信しない）
- 後方互換性のあるネイティブデュアル/マルチブート
- brick-proof(訳注:brick(起動不能状態、いわゆる文鎮化)しないようにする)
- リカバリー可能なセキュリティ（ユーザーが既知の良好な状態に復元可能）
この設計目標はこのドキュメントを読み進める中で心に留めておいてください。システムアーキテクチャに採用された多くの決定事項を 説明するものだからです。サードパーティ製OSに対するAppleのアプローチは、基本的に『楽しめ(have fun)』です。私たちは、 彼らからの直接的なサポートや文書提供、追加的な開発努力は期待していませんし、彼らが意図的にサードパーティ製OSの邪魔をしようと することもありません。Appleはこれらのマシン上でサードパーティ製OSとブートローダを安全に実行する能力を明示的に開発しており、 あとは私たちに任せています。
Apple はそのセキュリティ設計の多くを プラットフォームセキュリティガイド に記録しており、これらのプラットフォームに関する権威ある参考文献と見なすべきです。それでも、このガイドは システムの細かい技術的な点には踏み込んでおらず、私たちは実験とリバースエンジニアリングによってさらに多くの詳細について学びました。
これらのシステムは、macOSを動かすために設計されており、他のOSをサポートするための明確な許容はしていません。 カスタムカーネルを起動する機能は、macOS カーネル の セルフコンパイルビルドの 公式対応とみなすことができ、非 macOS OS はプラットフォームの他の部分との相互作用に関して macOS と同様に動作する必要があります。言い換えれば、ブートとファームウェアの相互作用のあらゆる側面におけるABIの仕様は、『macOSがすることなら何でも』なのです。 macOSの実際の使い方を強制するようなことは一切なく（邪悪なチェックやその種のものはない）、macOSブートABIに従う限り、 どんなOSにも開かれたシステムになっているのです。
セキュアブート、ユーザーコントロール、ライセンスについて¶
ユーザーコントロールと信頼性の観点からこれらの機器の位置づけを簡単に説明しないのは不注意でしょう。Apple Silicon機器は、 何よりもまず、Appleが署名したmacOSを実行する一般的なエンドユーザーに安全な環境を提供するために設計されています。 サードパーティからの攻撃に対するユーザーのセキュリティを優先する一方で、政府の要請に直面した際の責任を軽減するために、 Apple自身の機器に対するコントロールをある程度制限しようと試みているのです。また、サードパーティ製のOSがインストール されている場合でも、セキュリティが保たれる設計になっています。アーキテクチャ全体は複雑で、細部は微妙だが、いくつかの ポイントをまとめると以下のようになります:
- ブートコンポーネントは署名付きで不透明（暗号化）
- ランタイムコンポーネント（ファームウェアやmacOS本体など）は署名付きで透過的（平文）
- ただし、SEP（Secure Enclave Processor、TPMに相当）はオプションでデフォルトでは無効化
- そして単に付随的に暗号化されている2つの小さなブロブ（SMCとPMU）。Apple にこれらを開示させるのは良いことだが、 これらはかなり小さな I/O 面を保持
- brick回復/トータルシステムフラッシュ（DFU）はphone home(訳注:Appleのサーバーと通信すること)が必要
- OSのインストールを含む通常の操作は、物理的なユーザーの立会いがあればオフラインで可能。ネットワークに接続することなく、 箱から出したばかりのMacにLinuxをインストールすることが可能。
- 初回起動時に所有権を主張（macOSのセットアップフローを経て最初のadminユーザを作成することでマシンの所有者となる)
- 通常のブートローダのフローは最小限であり攻撃対象が小さい（USB、ネットワークなどなし）
- ランタイムブロブはシステム全体にアクセスできるように設計されていない（ME、PSP、TrustZone、その類のものはない）。 ほぼすべてのブロブはGPUファームウェア*を除いてIOMMUまたは同様のファイアウォールの内側で実行。メインCPU上で 動作するすべてのコードはOSの制御下
このため、ファームウェアとブートコンポーネントを自由に交換できるという点で、x86 PC と Talos II のような libre-first システムの中間に位置します。 システムを起動するために多くのブロブが必要ですが、それらのどれにも OS を乗っ取ったりブート後にセキュリティ侵害 (compromise)する能力はありません（つまり、最近のシステムの Intel ME や AMD PSP、あるいは old ThinkPad にさえ存在する不透明ブロブで動く LPC バスの DMA 可能チップなどとは異なります）。
AS機器は、それぞれが特定の目的に特化し、別のCPUコアで動作する多数の補助ファームウェアブロブを使用します。 これは(Intel MEのような)少数の台所のようなブロブを持つよりも良いことです。なぜなら、各ブロブは特定の サブシステム(たとえば、ディスプレイ、ストレージ、カメラ)にしか影響を与えることができず、複数のブロブが共謀して、 ユーザーを意味のある方法で危険にさらすことが難しくなるためです。例えば、キーボードコントローラー内で動作するブロブは、 WiFiカード上で動作するブロブと通信するメカニズムを持っていないため、キーロガーを密かに実装することはできません。 ディスプレイコントローラー上で動作するブロブも同様に、ネットワークと通信する手段を持っていないため、秘密の スクリーンスクレーパーを実装することはできないのです。
セキュリティの観点からは、これらの機器はサードパーティ製OSをサポートする一般向けコンピュータの中で所有者以外からの 攻撃に対する耐性という点で最も安全であると言えるかもしれません。もちろん、これはアップル社に対するある程度の信頼が前提 ですが、どんなシステムでもメーカーに対するある程度の信頼は必要です（どのマシンでもハードウェアバックドアが存在しない こと証明する方法はないので、これは最初に思われるほど厄介な点ではありません）。
この設計により、ユーザがサードパーティ製OSをインストールするのは、他のプラットフォームで慣れているよりもいくらか 厄介になります（これはマルウェアやユーザが自分のマシンを危険にさらすような誤解から守るための標準的な方法）。 これについてはこのガイドの残りの部分で説明します。
ライセンス面:
- 機器を使用するためにアップルのEULAをクリックする必要あり
- AppleはEULAの中でユーザーが独自のOSを実行することを明示的に許可
- アップルはユーザーにシステム・ファームウェアの再配布を不許可
- だが、Apple は現在および過去のすべてのバージョンの完全なシステムイメージ（ファームウェアと macOS）を よく知られた非認証の HTTPS CDN で提供
- AppleのEULAはすべてのMac所有者にこれらのイメージを使用するライセンスを付与
すべてのEULAと同様に、AppleのEULAにも意味不明な点がありますが（弁護士は常に実際の製品の方向性や設計と同期していないらしい）、 行間を読むと私たちが行っていることはすべて実用上問題ないと思われます。
* システムに特権アクセスをする一つの例外ブロブがあります（とはいっても何か明確に疑問のあることをしたりはしない)。
GPUファームウェアです。これはGPU ページテーブルの一部（これは自分自身のものでもあります）の管理を担当していて、
他のコプロセッサのように、GPU コプロセッサの前面に別のアップストリーム IOMMU が存在しないからです。これにより、
システムへのセキュリティ侵害の表面は広がりますが、このファームウェアは特に大きくなく、プレーンテキストで出荷され、
いくつかのシンボルさえあること、疑わしいインターフェース（ネットワークなど）を介して会話する機能を持たないこと、
オプションでありOS起動時には実行しない（OSが明示的に起動する必要がある）ことは指摘しておく必要があります。
そのため、GPU機能を見送ることを望むユーザーは、使用しないことを選択することができます。このファームウェアはまた、
PPL と同様の緩和策を実装しており、たとえ （GPU コマンドなどを
通じて）GPU のページテーブルが悪用されたとしても保護します。ただし、このメカニズムは現在、効果的な緩和策として十分に
強化されているとは考えていません。更新：macOS 13.0では、GPUファームウェアが大幅に強化されています
（一部はCVE-2022-32947のLinaの発見と報告のおかげ）。~~まだAsahi用の13.0+ファームウェアを出荷していませんが、
近々出荷する予定です。~~Asahiは現在ファームウェア 13.5 を出荷しており、システムのこの部分に対する信頼性を大幅に高めています。
とはいえ、現時点では、使用している既存の 12.3/12.4 のファームウェアにバックドアが存在していたり、 Linux からそれを
悪用することが可能であると信じるに足る根拠はありません。
ストレージ¶
ASプラットフォームには大きく分けて2種類のストレージがあります。NORフラッシュとNVMeです。
NOR は raw 領域としてフォーマットされ、以下のものが含まれています:
- 第一段階のブートローダ（iBoot1/LLB)
- システムグローバルファームウェア
- プラットフォーム設定データ（syscfg、読み取り専用）
- ファクトリーテストログ
- NVRAM（設定変数、読み書き可能）
NVMeはGPTボリュームで内容は以下の通りです:
- システムグローバルストレージ（iBoot System Container; iSC）を含む
- ブートポリシー(ブート設定と同じだが安全) (Preboot)
- SEPセキュアストレージ(xARTS)
- その他のシステム設定データ
- 1つまたは複数のAPFSコンテナパーティション
- コンテナを共有する1つまたは複数の起動可能なOSを含み、それぞれが以下を含む
- Prebootボリュームサブフォルダ
- 第2段ブートローダー(iBoot2)
- Apple DeviceTree
- OSと対になるファームウェア
- OSカーネル(XNU)
- OSと対になるrecoveryOSイメージ（Recoveryボリューム内）
- OSごとのrootおよびdataファイルシステムボリューム（空でも可）
- Prebootボリュームサブフォルダ
- コンテナを共有する1つまたは複数の起動可能なOSを含み、それぞれが以下を含む
- システムグローバルなrecoveryOSイメージ(+オプションのフォールバック)
追加のパーティションやタイプに制限はなく、Appleのツールでは無視されます。
なお、EFIシステムパーティションは使用しません（EFIも動作しません）。OSの選択は、特定のレイアウトでファイルを 含むAPFSコンテナとサブボリュームを中心に設計されています。
AS Macはbrick-proofになるように設計されています。NORやNVMeが破壊されても、USBケーブルを使ってROMから起動すれば、 他のマシンから復旧することができます（※NOR破壊は未検証）。これは別のMacを使った 公式文書です。 Linux等で動作する代替のオープンソースツールもあります。
この設計の特筆すべき点は、インストールされた各OSが、OSローダーと同様に、コプロセッサー上で動作するシステムファームウェアの 大きなサブセットも一緒に持ってくるということです。このため、古いOSとの後方互換性を維持することが容易になりますが、 逆に言えば、これらのコプロセッサのファームウェアABIは、安定性を全く保証していないことになります。
用語解説：ここでいう『OSカーネル』とは、XNUカーネルイメージまたは同等の類似物を指します。このセクションでは、 iBoot2によってロードされるすべてのものを記述するためにこの用語を使用します。サードパーティ製 OS を起動する場合、 これは通常 m1n1 のような後続のブートローダステージとなるでしょう。
ブートフロー¶
プラットフォームが定めるブートフローをまとめると、以下のようになります。
- SecureROM。
- NORからiBoot1の読み込み/認証
- 失敗すると USB DFU モードに入る
- iBoot1:
- NORからシステムグローバルファームウェアを読み出し/検証
- いくつかのコプロセッサをブートストラップ
- アップルロゴの表示とブートチャイムの再生
- ブートポリシーの選択と検証
- 選択した OS コンテナから NVMe 上で iBoot2 を読み込み/検証
- iBoot2:
- OSと対になるファームウェアをNVMeから読み出し/検証
- ファームウェアの一部をロードしてロックし、ディスプレイコプロセッサを再起動
- NVMeからApple Device Treeを読み込み/検証
- OSカーネルをNVMeから読み出し/検証
- いくつかのコプロセッサーをスリープ
- OSカーネルにジャンプ
OSカーネルはブートフローの中でAppleに署名されていないコードを実行することができる最初のポイントです。
注目すべきは、このプロセスでは、画面やスピーカーや電源ボタンや（ラップトップの）特定のキーが押されたことを確認する
以外のI/Oは、どの時点でも初期化されないという点です。これらの機器のブートローダのフローには、外部ストレージの
ブートサポートは ありません。裏側では、外部ドライブから macOS を起動することは、/boot を内部ストレージに
コピーすることと振る舞いとしては同等であり、root/dataファイルシステムだけが実際に外部ストレージに存在することになります。
また、ブートメニューもありません（ただし読み進めてください）。
recoveryOS と 1TR¶
recoveryOSは、ユーザーがこれらのマシンでリカバリやインストール作業を行うための環境を提供するために使用されるmacOSイメージです。また、これらのマシンではブートピッカーメニューとしても機能します。
recoveryOSは、再起動時にNVRAM変数経由で要求することも、一定回数の起動失敗の後に自動的に呼び出すこともできます。 これは最小限の macOS イメージで、システムセキュリティ設定の変更、ディスクのパーティション設定、ウェブブラウザの起動、 rootターミナルの起動、macOS の再インストールなどを可能にするリカバリメニューをユーザに提示します。 ネットワークアクセスに対応しています。
さらに、『特別な』ブートフローがあり、追加機能を付与しています。電源ボタンを押してマシンの電源を入れると、現在アクティブな デフォルトブートOSボリュームと対になったrecoveryOSがロードされ（システムのものにフォールバックする）、最初に ブートピッカーが表示されて、起動するOSを選択できる（オプションでデフォルトにすることもできる）ようになっています。
ユーザーが『オプション』を選択すると、上記のようにrecoveryOSのメニューが表示されます。この方法で起動した場合、 『One True recoveryOS』（1TR）と呼ばれ、SEP（セキュアエンクレーブ）ファームウェアによって、さらに権限が付与されています。 さらに、このrecoveryOSは、所属するOSコンテナと『対』とみなされ、そのOSに対して特定の操作を行うことができるようになります。 特に、カスタムOSカーネルをインストールする場合には、このモードが必要です。
SEP（Secure Enclave Processor, セキュアエンクレーブプロセッサー）¶
SEPは、MacのTPMに相当するもので、ブートポリシーの作成・変更の検証など、セキュリティ上重要な処理をすべて担当します。 1TR、plain recoveryOS、通常のOSブートなど、システムのセキュリティ状態を把握してしています。
SEPはブートプロセスで使用されますが、OSカーネルがブートされる前にスリープ状態になります。OSはSEPファームウェアを再ロードし、 それを使用できるように再ブートストラップする必要があります（暗号化されたファームウェアブロブは、iBootによってOSにメモリ 領域で提供されます）。つまり、サードパーティ製OSにとってSEPは完全にオプションであり、必要ない場合は無視することができます。
SEPが提供する便利な機能には、ユーザー認証、Touch ID、安全な鍵の保管/使用、U2Fのサポートなどがあります。例えば、 ブルートフォース耐性のあるパスワード/タッチログインとフルディスク暗号化を提供したり、SSH鍵を保持し、それを使用するために パスワードまたはタッチを要求するために使用することができます。
SEPは、メインCPU（AP）と相互に隔離された設計になっており、どちらも他を侵害することはできません。また、物理的な攻撃（ グリッチなどの環境攻撃）に対しても強化されていると思われます。
セキュリティモード、ブートポリシー、機器の所有権¶
AS MacにインストールされたOSは、それぞれ関連するブートポリシーを持っています。ブートポリシーには、OSのセキュリティ状態が 記述されています。これらのBoot PolicyはSEP経由で作成され、内部のマシンキーで署名されているため、外部で変更することはできません。
トップレベルのセキュリティモードは、OSごとに3つの状態のいずれかにすることができます。
- 完全なセキュリティ(Full Security)
- 低セキュリティ(Reduced Security)
- セキュリティ制限なし(Permissive security)
完全なセキュリティはデフォルトで、OSが完全にAppleの署名入りで、すべてのセキュリティ機能が有効であることを意味します。 完全なセキュリティモードでOSをインストールするためには、システムがアップル社に電話をかけて、OSが信頼できるものであることを 検証しなければなりません（これは、攻撃者が既知の脆弱な古いOSをインストールして、それを使ってシステムを危険にさらすことを 防ぐためです）。
低セキュリティでは、特定のセキュリティ機能を無効にし、Appleの署名があるOSであれば、どのバージョンでもインストールすることが できます。このモードではOSをインストールするためにphone home(訳注:ネットワーク接続のことかと)は必要ありませんが、 このモードへのダウングレードやブートポリシーの作成には、recoveryOS上であることと機器所有者認証が必要です。
セキュリティ制限なしでは、〜すべてのセキュリティ機能を無効にし、サードパーティ製のカーネルをインストールすることができます。 phone homeは必要ありません。セキュリティ制限なしにダウングレードするには、関係する特定のOSとペアになった1TRでブートし、 機器所有者の認証情報を使用して認証する必要があります。
SEPは、機器所有者ユーザーのデータベースを維持します。そのような最初のユーザーは、ユーザーが工場出荷時の状態から （またはDFUワイプの完全な後）最初に起動する際にmacOSブートフローを通過する際に作成されます。後続の機器所有者は、 既存の所有者の認証情報を使用して認証することによってのみ作成することができます。
OSごとにセキュリティ状態を設定できるのは、これらのマシンに特有のもので、フルセキュアなmacOS（DRMサポートを含む、4Kでの NetflixやiOSアプリの実行）とLinuxのデュアルブートなどが可能です（Androidデバイスのブートローダーのアンロック、 UEFIシステムでのセキュアブートの無効化や署名キーの変更などは、グローバルオペレーションとなるのと対照的）。
低いセキュリティレベルでは、OS ブート引数のフィルタリングが行われるかどうか、カーネルコードが RAM 内で読み取り専用に ロックされるかどうかなど、より細かいセキュリティ設定をブートポリシーで指定する機能のロックが解除されます。
ブートポリシーは macOS/recoveryOS/1TR の bputil コマンドで管理できます（各モードの制限に従います）。
完全非信頼型 OS (fuOS)¶
fuOSとは、Appleが提唱するサードパーティ製OSカーネルの呼称です。fuOSブートを設定するためには、まず既存のOSを
セキュリティ制限なしにダウングレードし、その後カスタムカーネルイメージをインストールする必要があります。イメージは
kmutil コマンドを使ってインストールされ、ブートポリシーを変更してそのハッシュを挿入し、それによって
セキュアブートチェーンを維持します。iBoot2 はこの特定の fuOS イメージのみをロードします。この操作には
機器所有者認証が必要です。
カスタムカーネルイメージはフラットな ARM64 実行可能イメージで、エントリーポイントと (仮想的でほとんどの場合意味のない) ロードアドレスはイメージを設定するときに指定します。以前は Mach-O バイナリが必要でしたが、Apple は 12.1 で この機能を追加し、私たちの活動を楽にしたようです (Mach-O ファイルフォーマットの要件がそのバージョンで変わり、 私たちの既存のツールが壊れたため)。
ブートピッカー¶
内蔵のブートピッカーは、recoveryOS下で動作するmacOSアプリケーションで、内部および外部ボリュームをスキャンして、 起動可能なOSを探します。リストに表示されるのは2つです。OSインストールとOSインストーラです。OSインストールは、 予想されるOSのレイアウトに従ってAPFSコンテナに存在します（1つのAPFSコンテナに複数のOSが存在することがあります）。
iBootには外部デバイスから起動する仕組みがないため、起動する外部OSを選択すると、ブートピッカーはそのOSのPreboot構造を NVMeにコピーし、それ用のBoot Policyを作成し、iBoot1がそこから起動するように構成します。コピーされるのは、iBoot2や ファームウェアなど、XNUカーネルそのものまでを含みます。つまり、外部ストレージはXNUがすでに起動しているときにのみ 初期化され、NVMeから起動した後は、そこからルートファイルシステムをマウントするだけとなります。このプロセスでは 新しいブートポリシーを作成する必要があるため（適切なセキュリティ状態にはならず、ペアリング要件のため、その時点では それに入れることもできません）、この方法で外部ドライブにインストールしたfuOSカーネルのブートに使用できないことに 注意してください（少なくともさらなる手動操作なしではできませんが、これが全く可能かどうかは不明です）。
OS のインストーラは、ボリュームのルートにある .IAPhysicalMedia というmagic plistで識別され、対応する
ファイルシステム (APFS と FAT32 の両方) のボリュームに 存在する可能性があります。この plist は、起動する
ボリュームに存在する macOS アプリケーションバンドルを指定します。ボリュームが選択されると、ブートはメインの
recoveryOS 環境に進み（有効な場合FileVault によって強制された認証を含む）、アプリケーションバンドルが
自動的に起動します。これは、ブートピッカーが適切な電源ボタンホールドジェスチャーによって呼び出された場合、1TR
モードで発生します。この機能は、現在 Asahi Linux のインストーラで、よりユーザーフレンドリーな方法で第二ステージを
起動するために使われており、サードパーティのインストーラを USB インストールイメージとして出荷するために使用できます
（ただし、再頒布不可能な Apple コンポーネントを必要とするので、完全にオフラインでそのまま使用できるものではありません）。
ブートピッカーが裏で macOS アプリケーションとして実装されていることの結果として、VoiceOver を含む完全なアクセシビリティ サポートを備えていることが挙げられますが、これはかなり独自です。
ARM64 XNUブートプロトコル¶
ブートプロトコルは非常にシンプルで、ブートローダサービス（例：EFIサービス）やその類は一切ありません。OSイメージは、 iBootによってロードされ、ジャンプされます。カーネルイメージは、様々なポインタチェーンを介して、以下の情報を受け取ります。
- ブート時のフレームバッファ情報 (詳細ブートフラグを含む)
- コマンドライン引数（NVRAMからの
boot-args）、ブートポリシーフラグによってフィルタリング - RAMベース/サイズ情報
- Apple DeviceTree
- SEPファームウェアブロブ
イメージは常に下位RAM（KASLR）のランダムなオフセットにロードされるため、再配置可能である必要があります。イメージ・テキストは、 セキュリティ上の理由から、オプションでメモリ・コントローラ内で読み取り専用としてロックされます。さらに、CPU0 のリセット ベクターはイメージ内の計算されたオフセットにロックされるため、スリープモードからの復帰には、そのアドレスにコードが存在 することが必要です。
Apple DeviceTree¶
Appleは、組み込みLinux/BSDシステムで標準となっているOpen Firmwareデバイスツリーと同様のデータモデルを持つ、特注の DeviceTree形式（FDTよりシンプル）を使用しています。DeviceTreeは、テンプレート、システム構成情報、および動的データから iBoot2によって構築されます。DeviceTreeのスキーマはOSのバージョンによって厳密には安定していませんが、大きな変更は ほとんどありません。
OSはADTを解析して、マシンおよびブート固有の重要な情報を抽出する必要があります。
ファームウェアの概要¶
既知のファームウェアブロブの簡単な概要（注:ここでの詳細は未検証）:
| 名称 | Chip | 説明 | 暗号化 | ストレージ | 何によってロードされるか | 何によって開始されるか | 大きさ(約) |
|---|---|---|---|---|---|---|---|
| iBoot1 | SoC (AP) | 第一段階ブートローダー | いいえ *2 | NOR | SecureROM | SecureROM | ~600-1000 KB (圧縮) |
| iBoot2 | SoC (AP) | 第ニ段階ブートローダー | いいえ *2 | Preboot | iBoot1 | iBoot1 | ~450-800 KB (圧縮) |
| SMC | SoC*1 | システム管理コントローラー | いいえ *2 | iBoot1 内蔵 | iBoot1 | iBoot1 | ~200 KB (圧縮) |
| PMU | PMU | 電源管理ユニット | いいえ *2 | iBoot1 内蔵 | iBoot1 | iBoot1 | ~10 KB |
| SEP | SoC | セキュアエンクレーブプロセッサ | はい | iSC | iBoot1+OS | iBoot1+OS | ~7.5 MB |
| ANS | SoC | NVMeコントオーラー | いいえ | NOR | iBoot1 | iBoot1+2+OS | ~800 KB (圧縮) |
| CIO | SoC | Type-C/Thunderbolt I/O | いいえ | NOR | iBoot1 | OS | ~170 KB |
| TMU | SoC | Thunderbolt関連 | いいえ | NOR | iBoot1 | OS | ~10 KB |
| DCP | SoC | ディスプレイ制御プロセッサ | いいえ | NOR & Preboot | iBoot1+2 | iBoot1+2+OS | ~9.5 MB (~2.5 MB 圧縮) |
| ANE | SoC | Appleニューラルエンジン | いいえ | Preboot | iBoot2 | OS | ~5 MB (~180 KB 圧縮) |
| AGX | SoC | Appleグラフィックス (GPU) | いいえ | Preboot | iBoot2 | OS | ~2.5 MB (~150 KB 圧縮) |
| ISP | SoC | イメージシグナルプロセッサ (カメラ) *3 | いいえ | Preboot | iBoot2 | OS | ~12 MB (~2.5 MB 圧縮) |
| SIO | SoC | Smart I/O (UART/I2C/SPI DMA) | いいえ | Preboot | iBoot2 | OS | ~1 MB (~50 KB 圧縮) |
| AOP | SoC | 常時接続(Always-On)プロセッサ *4 | いいえ | Preboot | iBoot2 | OS | ~1.2 MB (~300 KB 圧縮) |
| PMP | SoC | 電源管理プロセッサ | いいえ | Preboot | iBoot2 | OS | ~400-920 KB (~100 KB 圧縮) |
| AVE | SoC | Apple Video Encoder | いいえ | Preboot | iBoot2 | OS | ~1.2 MB (~300 KB 圧縮) |
| AVD | SoC | Apple Video Decoder | いいえ | XNU内蔵 | OS | OS | ~40 KB |
| SECDIS | SECDIS | セキュアマイク/カメラ無効化FPGA *5 | いいえ | オンチップフラッシュ | 自身 | 自身 | 設計上アップグレード不可 |
| IPD | IPD | 入力機器 (タッチパッド/キーボード) *5 | いいえ | Preboot/フラッシュ *6 | 自身 | 自身 | ~900 KB (~384 KB 圧縮) |
| MT | DFR | タッチバー (DFR) マルチタッチ *7 | いいえ | Preboot | OS | OS | ~60 KB |
| XHCI | ASM3142 | PCI xHCI USB コントローラ *8 | いいえ | XNU組み込み | OS | OS | ~128 KB |
| WLAN | WLBT | Wi-Fi (Broadcom FullMAC) | いいえ | OSファイルシステム | OS | OS | ~1.4 MB (~700 KB 圧縮) |
| BT | WLBT | Bluetooth (Broadcom) | いいえ | OSファイルシステム | OS | OS | ~470 KB (~280 KB 圧縮) |
| SE | SE | セキュアエレメント | はい | オンチップフラッシュ | 自身 | 自身 / SEP? | ~4.5 MB |
| S5E | S5E | NAND (SSD) コントローラ | いいえ | オンチップフラッシュ | On-chip ROM? | ANS | ~700 KB (~300 KB 圧縮) |
| ACE2 | ACE2 | USB-PD コントローラ | いいえ | 専用フラッシュ | On-chip ROM | OS? | ~500 KB (~170 KB 圧縮) |
| TCON | TCON | ディスプレイタイミングコントローラ *9 | いいえ | オンチップフラッシュ | 自身 | DCP | ~1.3 MB (~20 KB 圧縮) |
| DP2HDMI | MCDP29XX | DisplayPort to HDMIブリッジ *10 | いいえ | 専用フラッシュ | 自身 | DCP | ~500 KB (~280 KB 圧縮) |
注意事項
- 『SoC』の位置は、メインのシステムオンチップの一部を意味し、それ以外は外部チップ
- macOS Sequoia以降はプレーンテキスト(訳注: 平文とプレーンテキスト)
- コプロセッサは存在するがカメラのないマシンでは未使用
- ひどい名前で実際には常時接続ではない(OSが起動するときにも接続されていない)
- ラップトップのみ
- フラッシュから起動するが、ファームウェアはPrebootに保存され、必要に応じてOSのFUDデーモンによってアップグレード
- J293のみ（MBP 13" M1）
- J456 (4ポートiMac)のみ
- 組込みディスプレイ搭載機のみ
- HDMI端子搭載機のみ
多くのファームウェアのサイズは圧縮されています（多くのファームウェアには大量のパディングがあり、非圧縮のサイズはコードの 量を測るのにあまり有用ではありません）。大きなファームウェアが非圧縮で保存されている場合、比較しやすいように圧縮された サイズも示しています。サイズはあくまで目安です。