Apple Exclavesについて

 (medium.com/@randomaugustine)
1 ポイント 投稿者 GN⁺ 2025-03-10 | 1件のコメント | WhatsAppで共有
  • AppleのExclavesは、XNUカーネルが侵害されても一部の機微なリソースを別領域に残しておくための分離機能であり、M4・A18向けXNUソースの公開によって構造の一部が明らかになった
  • XNUはMachベースだが、実際のシステム機能は同じ特権範囲に集約されており、モノリシックカーネルのように動作する。Exclavesは、Secure Enclave、PPL、SPTMへと続く防御の多層化の流れの上にある
  • Exclavesは起動時に定義されるドメインとリソースで構成され、共有メモリバッファ、オーディオバッファ、センサー、Conclave、サービスなどを、SPTMの新しいページタイプによってXNUから保護する
  • Secure Kernel(SK) はXNUと同じアプリケーションプロセッサ上で動作し、ソース上の手がかりからseL4系およびARM TrustZoneのsecure worldを使用している可能性があるが、内部実装のかなりの部分は公開されていない
  • 実際のセキュリティ効果は、どの構成要素がExclavesへ移されるかに左右される。現時点のビルドイメージは、カメラ・マイクのセキュリティインジケータ、Apple Neural Engineの一部、一部ドライバ、Secure Enclave通信コンポーネントの利用を示している

モノリシックカーネルとAppleの分離強化の流れ

  • 現代のオペレーティングシステムは通常、ユーザーモードとカーネルモードという2つの保護ドメインで動作する
    • アプリケーションは、ファイルアクセスやネットワーク通信のような強い権限を要する処理を直接実行できず、システムコールを通じてカーネルに要求する
    • カーネルはアクセス権を確認したうえで、開かれたファイルを表すハンドルのような結果をユーザーモードへ返す
  • ほとんどのオペレーティングシステムはモノリシックカーネル構造を採用しており、カーネルはハードウェア、メモリ、ユーザーデータ全体に無制限のアクセス権を持つ
    • カーネルが大きくなるほど、脆弱性が生まれる可能性も高くなる
    • カーネル脆弱性の悪用は、システム全体の侵害につながりうる
  • マイクロカーネルは、カーネル内部の機能を減らし、ほとんどの処理を別個の非特権プロセスへ移すことで、セキュリティ分離を改善できる
    • 一方で、性能面の問題とアプリケーションソフトウェアの複雑化は欠点として残る
  • iOS、macOS、tvOS、visionOS、watchOSが共有するXNUはMachマイクロカーネルベースだが、実装上は複数のシステム機能が同じ特権範囲にあり、実質的にはモノリシックカーネルのように動作する

Exclaves以前のAppleのセキュリティ分離

  • 2013年のiPhone 5sではSecure Enclaveが導入された
    • 専用の強化CPUコア上で、SepOSというマイクロカーネルベースOSが動作する
    • SepOSのカーネルは、AppleのL4-embeddedカスタム版であるcL4
    • 暗号鍵やFace IDのような生体情報の保護に使われる
    • iOSカーネルが侵害されても、Secure Enclave自体を狙う追加のエクスプロイトがなければ、一般には影響を受けにくい
    • Secure EnclaveとSecure Exclavesは別物である
  • 2017年、A11ベースのiPhone 8・iPhone XではPage Protection Layer(PPL) が導入された
    • カーネルの一部にのみメモリページテーブルの変更権限を与え、残りのカーネルは直接変更できないようにする
    • 攻撃対象領域が小さいため回避はまれだったが、残りのカーネルは依然としてデータ侵害に必要な多くの権限を保持していた
  • 2021〜2023年のA15とiOS 17ではSecure Page Table Monitor(SPTM) がPPLを置き換え・改善した
    • 追加のメモリ機能を保護し、小さなカーネル構成要素単位で分離する
    • Apple署名かどうかを確認するコード署名検証も分離された
    • この時期のXNUソースにはexclavesへの間接参照が現れ、当時はSPTMが管理するサブシステムと推定されていた

2024年、XNU Exclavesの登場

  • M4・A18ベースシステムをサポートするXNUソース公開により、Exclaves構造の一部が明らかになった
    • iPhone 16のようなシステムが対象
    • 以前のプロセッサではExclavesは有効化されない
  • ExclavesはXNUから分離されたリソースを指し、カーネルが侵害されても保護される領域として設計されている
    • リソースはOSビルド時にあらかじめ定義される
    • 名前またはIDで識別される
    • タイプを持ち、起動時に初期化される
    • 固有のドメインで構成される
  • SPTMはExclave専用ページタイプにより、ExclaveメモリをXNUから保護する
  • 確認されたリソースタイプは、XNUとExclaveの境界がどこに生じるかを示している
    • XNUとExclaveがともにアクセスできる共有メモリバッファ
      • XNU側からは読み取り専用または読み書き可能に設定できる
    • カメラ・マイクのアクセス表示のような機能の保護に使われるオーディオバッファとセンサー
    • 複数のリソースを独自のセキュリティドメインに束ねるConclaveとConclave Manager
    • XNUスレッドが呼び出した際に、Exclave空間でコードを実行できるサービス

Secure Kernelとsecure world

  • ExclaveサービスをXNUから分離した状態で実行するため、AppleはSecure Kernel(SK) を導入した
  • SKイメージファイルには「cL4」のバージョン文字列が含まれる
    • IPC構造は、元のSepOS cL4のL4-embeddedよりもseL4に近いように見える
    • SK文字列には、capability、frame、untyped memory、mintingといったseL4系の用語が頻出する
    • Appleは2024年4月にseL4 Foundationへの参加を公表した
  • SepOSが専用プロセッサ上で動作するのに対し、SKはXNU/iOSと同じ高速アプリケーションプロセッサ上で動作する
  • この構造には追加のプロセッサ特権レベルが必要であり、基盤候補として仮想化拡張、Apple独自のSPTM追加機能、ARM TrustZoneが挙げられている
    • XNUソースにはTrustZoneのsecure world切り替えに関する参照がある
    • XNUとiOSはinsecure worldで、SKはsecure worldで動作する構成と解釈できる
  • SKはExclave、リソース、サービスに限定された実行環境を提供する
    • ARMが提案したTrusted Applicationsの設計パターンとは異なる
    • ExclaveサービスとSecure Kernelの攻撃対象領域は限定的であり、secure worldから脱出してXNUを侵害するのは、insecure worldからXNUを直接攻撃するよりもはるかに難しい可能性がある
  • XNUソースではsecure world切り替えはRINGGATEと呼ばれている
    • SPTMが切り替えを管理している可能性は推測の域を出ず、関連部分はオープンソースではないためバイナリ解析が必要となる

ドメイン、リソース、Conclave

  • XNUは起動中に発見したExclaveリソース情報を保持するため、2段階のカーネルテーブル構造を初期化する
    • root_tableは名前でドメインを識別する
    • 各ドメインは、そのドメインのリソースを格納する第2段階テーブルを参照する
  • 確認されたドメイン構造は次のとおり
    • com.apple.kernel
      • Conclave launcher、デバッグサービス、セキュリティインジケータ用ExclaveIndicatorController、ログサービス、ExclaveKit起動に使われるFrameMintなどを含む
      • Exclaveサービスがupcallを通じてXNU空間でファイルI/Oを行う際に使う共有メモリバッファ com.apple.storage.backend も含む
      • Conclaveごとに1つ存在するConclave Managerリソースを含む
    • com.apple.darwin
      • オープンソースコンポーネントでは利用例がない
    • com.apple.conclave.name
      • Conclaveごとに1つのドメインが存在する
      • サービス、オーディオバッファ、共有メモリバッファなどを含みうる
    • com.apple.driver.*name*
      • デバイスドライバごとのドメインとして、コメントに基づき存在が言及されているが、オープンソースコードでは実際には確認されていない
  • Conclaveは、複数のリソースを収容できるリソースタイプであると同時に、サービスとリソースが相互に共有アクセスを持つためのセキュリティ単位でもある
    • Mach taskが呼び出せるConclaveは制限される
    • 各Conclaveには、kernelドメインに配置されたConclave Managerがある
    • Conclaveにはattach、launch、stop、detachといったライフサイクルがある
    • launching、stoppingのような遷移状態も存在する

Conclaveの生成、接続、実行

  • XNUのposix_spawn()はtask_add_conclave()を呼び出し、taskとConclave Managerリソースを接続できる
    • 関係は1対1
    • 1つのtaskは1つのConclave Managerにしか接続されず、その逆も同様
  • Conclaveをspawnできる主体はlaunchdまたはcom.apple.private.exclaves.conclave-spawn entitlementを持つtaskである
    • com.apple.private.exclaves.conclave-host entitlementは、新しいtaskをspawnするというより、自分自身をattachする権限に近いと解釈される
  • カーネルは対象Conclaveに接続されたConclave Managerリソースをcom.apple.kernelドメイン内で探す
    • その後、Conclaveリソース構造体にConclave Manager endpointへ向かうTightbeam endpointを保存する
    • TightbeamはExclaveコンポーネント間通信のためのRPCフレームワークと見られる
  • Conclaveの実行は、接続されたConclave Manager task上で行われなければならない
    • ExclavesがEXCLAVES_BS_BOOTED_EXCLAVEKIT状態まで完全に起動するまで、launch試行は待機する
    • 新しいMach trapは_exclaves_ctl_trap()関数に入り、EXCLAVES_CTL_OP_LAUNCH_CONCLAVEがConclave実行に使われる
    • production環境では、launchされたConclave hostがtainted状態になる可能性があり、その後のexit()がカーネルパニックを引き起こす場合がある

Exclaves向けの新しいMach trap

  • _exclaves_ctl_trap()はExclave機能を処理する新しいMach trapである
    • operationパラメータに応じて複数の動作を行う
    • 通常、呼び出されたoperationに必要なentitlementを検証する
  • EXCLAVES_CTL_OP_BOOTはシステム起動中に2回呼び出される
    • Exclaves boot stage 2の開始
    • ExclaveKitの起動
    • 呼び出し元はlaunchdであるか、com.apple.private.exclaves.boot entitlementを持っている必要がある
  • そのほかの主要operationは、少なくとも現在のtaskがcom.apple.private.exclaves.kernel-domain entitlementを持つか、関連するConclave Manager taskである必要がある
    • EXCLAVES_CTL_OP_LOOKUP_SERVICES: 現在taskのExclaveドメインでサービスを探し、失敗した場合は権限に応じてDarwinドメインとkernelドメインも確認する
    • EXCLAVES_CTL_OP_ENDPOINT_CALL: 現在taskドメインのExclaveサービスendpointを呼び出し、現在のスレッドをsecure worldへ切り替えて特定のコードを実行する
    • named bufferの作成とcopyin/copyout
    • audio bufferの作成とcopyout
    • sensorの作成、start、stop、status
    • notification resource lookup

DowncallとUpcall

  • Downcallはsecure world内のExclaveサービスendpoint呼び出しであり、secure worldコード実行の開始地点となる
  • Downcallは現在のスレッドをsecure worldへ切り替え、secureコードのentry pointから実行を開始する
    • 別スレッドに処理を委ねる方式ではない
    • 呼び出しtaskはkernel domain entitlementを持つか、対象サービスConclaveに接続されたConclave Manager taskでなければならない
    • Conclaveは呼び出し可能なサービスを最大128個持つ
  • XNUはsk_enter()を通じてスレッドをSecure Kernelへスケジューリングしているように見える
    • SKが独立したスレッドを持たず、XNUがsecure world内のすべてのスレッドスケジューリングを担当している可能性がある
    • secure worldで実行中のスレッドは、yield、wait、suspend、interruptのような通常のスケジューラ動作を行える
    • この場合、スレッドはsecure worldを離れてXNUカーネルコンテキストへ戻り、その後Exclaveスケジューリングコードによって再びsecure worldへスケジュールされる
  • DowncallのIPC構造は、secure worldへ入る前にrequest・responseバッファとして設定される
    • 最終的なIPC request構造を準備し、sk_enter()を呼び出している間は割り込みとプリエンプションが無効化される
    • これはこの構造がCPUコアごとに1つしかないためである
    • Downcall responseは、中断、upcall、yield、再スケジューリングのため、別CPUのper-core response bufferへ返ることがある
  • Upcallはsecure worldで実行中のスレッドがXNUの支援を必要とするとき、Tightbeamを通じてExclaves upcall handlerを呼び出す方式である
    • 許可された特定のXNU関数に限定される
    • upcall中のスレッドはユーザーモードへ戻れない
    • secure worldへ再度downcallして再入することも許されない
    • スレッドはupcallを実行した地点のsecure worldコンテキストへ戻らなければならない
  • ソースで確認されたupcallカテゴリは、メモリ、ファイルストレージ、DriverKit、DriverKit Apple Neural Engine、Conclave制御である

XNUProxyと起動段階

  • XNUProxyへの参照は多いが、正確な位置と役割は確定していない
    • 独立したExclaveドメインの可能性がある
    • com.apple.kernelドメイン内で特定のdowncallを処理するサービスまたはサービス群の可能性がある
    • secure worldへdowncallを行うSPTMサブシステムである可能性もある
  • Exclaves_L4.h のコメントには、XNU Proxyが複数のExclaveをreachableにすると記されている
    • user appテンプレート
    • audio driver
    • ExclaveDriverKit
    • Always On ProcessorとDisplay Coprocessor向けSecureRTBuddy
    • Conclave control、Conclave debug など
  • Exclavesの起動はinsecure worldとsecure worldの協調を必要とし、問題が起きると通常はpanic()につながる
  • 起動は3段階に分かれる
    • Stage 1はオープンソースでは見えず、SKをメモリへロードし、コード署名を検証したうえで実行可能にするsecure boot工程である可能性が高い
    • Stage 2ではupcall server初期化、secure kernel起動情報の収集、Exclave scheduler初期化、XrtHostedXNU kext初期化、multicore初期化、XNU Proxy初期化、静的Exclaveリソースの発見、Conclave Manager endpoint生成などを行う
    • Stage 3ではcom.apple.service.FrameMintサービスを探し、framemint_framemint__init()、framemint_framemint_populate()関連呼び出しを実行した後、EXCLAVES_BS_BOOTED_EXCLAVEKIT状態になる

SPTMメモリタイプと残る限界

  • SPTMはサブシステムごとのアクセス制御のため、メモリページにタイプを割り当てる
    • 既存タイプにはXNU_USER_EXEC、XNU_USER_DEBUG、XNU_USER_JIT、XNU_ROZONE、XNU_KERNEL_RESTRICTED、TXM・DART関連タイプなどがある
  • Exclavesは新たなSK関連タイプを追加する
    • SK_DEFAULT: SK専用、XNUからはアクセス不可
    • SK_IO: SK専用、XNUからはアクセス不可
    • SK_SHARED_RO: SKとXNUで共有するが、XNUは読み取り専用
    • SK_SHARED_RW: SKとXNUで共有し、XNUは読み書き可能
  • Exclavesは、Appleオペレーティングシステムにdefence in depthを追加するための大きな投資と見なせる
    • 機微なリソースを分離し、潜在的な攻撃対象領域を縮小する
    • 単一のカーネル侵害の影響を抑える方向である
  • 実際にどの構成要素がカーネルからExclavesへ移されるかは、直接には分析されていない
    • ビルドイメージは、セキュリティ用カメラ・マイクインジケータ、Apple Neural Engineの一部機能、一部デバイスドライバ、Secure Enclaveと通信する構成要素の利用を示している
    • 今後さらに多くの構成要素がExclavesへ移される可能性がある
    • Exclaves外のXNU領域は依然として攻撃対象である
  • 分析はApple Open Source XNU build 11215に基づいている
    • ExclaveKit、ExclaveDriverKit、XNUProxyの正確な位置、XNUのsecure world切り替え方式、Secure Kernel、secure world userspaceは今後の追加分析が必要な領域として残っている

関連記事

1件のコメント

 
GN⁺ 2025-03-10
Hacker Newsの意見

  • 最近のAppleのスマートフォン／ノートPC向けSoCにはネストされた仮想化のハードウェアサポートが搭載されており、カメラLEDにexclaveを使うM4 iPad Proも含まれる
    次のApple Platform Securityガイド改訂版で、SK exclaveとWi‑Fiレーダー検知のためのベースバンド緩和策を扱ってくれることを期待している: https://help.apple.com/pdf/security/en_US/apple-platform-sec...
    AppleのSPTM追加機能については、SPTMのリバースエンジニアリング記事もある: https://www.df-f.com/blog/sptm3
    XNUはマイクロカーネルに着想を得た構造へとリファクタリング中で、コードベースを減らしつつ、セキュリティ上重要な処理を外へ移す方向にある。メモリ空間の分離はSecure Page Table Monitor(SPTM)が支援し、コード署名・権限検証・Developer Mode・Restricted Execution Modeのような処理はTrusted eXecution Monitor(TXM)が担う
    TrustZone関連のCVEは150件を超える: https://www.cve.org/CVERecord/SearchResults?query=trustzone
    Googleも数年前にPixelで、ハードウェアによるネストされた仮想化を使うpKVMを実装し、pKVM L0に比べてTrustZoneの権限を協調的に下げるコードまでLinuxメインラインに入れた。ただしDebian “Linux Terminal” VM以外では、pKVM/AVFを活用した防御機能を発表してはいない

    • TrustZone CVEの大半は、メーカーがTrustZoneの保護環境に入れた脆弱なソフトウェアに関係するものだ。そうしたソフトウェアの中にはひどいものも多く、ハードウェア自体の脆弱性報告は非常に少ない
    • 筆者が続編記事と修正済みの図を公開した: https://randomaugustine.medium.com/more-speculation-on-excla...
      当初はTrustZoneの使用を推測していたが、exclaveは既存のSPTMとGXF(Guarded Execution)の権限レベルを使う可能性もありそうだ。だとすれば、RAM要件と開発工数を除けば、iPhone 13以降でもサポートできない根本的な理由はないかもしれない。もちろんAppleにとっても大変な作業であることは間違いない

  • Steveは本気で「ノートPCは個人の日記帳」であり、Appleにはそれを守る責任があると信じていたように思う
    TimもSteveと同じ信念がなければCEOにはなれなかった気がする。変に聞こえるかもしれないが、Steveが本当に恋しい
    https://www.youtube.com/watch?v=Ij-jlF98SzA

    • 産業用・科学用機器を作る立場からすると、Appleの消費者向けデバイスはまったく役に立たない。十分に有能なコンピューティング装置をここまでロックダウンしてしまうのは無駄に見える
      デバイスの所有者が変わった後も、Appleが機器とソフトウェア市場を支配するやり方も気に入らない。こうしたエコシステムは徹底的に避けているし、なぜ多くのいわゆる「ハッカー」たちが、ボンネットを溶接して閉じてしまったようなシステムに熱狂するのか分からない
    • Jobsは評価が分かれる人物で、しょっちゅう気難しかった。そもそもなぜテック億万長者を恋しがる必要があるのか、と思うところもある。それでも、Mac、iPod、iPadのような好きな製品を作るのに貢献したJobsとAppleの人たちには恩があるように感じる
      Jobsの言葉には、今でも響くものが多い。最近Appleが「classic Mac」スクリーンセーバーを出したが、元のMac GUIがどれほど丁寧に設計されていたかを示している。アプリのバグがOSを落としていた時代を懐かしむ人はいないだろうが、Appleには今でも当時と同じくらいディテールにこだわっていてほしい
    • Jobsに向けられる心からの感情を見ると、人々がLLMを使い体験するときにも、似た何かが働いているのか気になる
      少し露骨に言えば、そこには神秘的、あるいは宗教的な要素があるように思う。奇跡、神託、美しい製品と儀式、なめらかで豊かで永遠の未来を提供してくれる、神のように思いやりのある男性を切望しているように感じる。一種の精神的な「穴」が埋められる感じだ
      JobsやLLMに好感を持つ人を貶めるつもりはなく、単に観察したことを共有しているだけだ
    • exclaveの記事がSteveについての考えを思い起こさせたのは分かるが、どうやって一方がもう一方につながったのかはよく分からない。説明してもらえるだろうか

  • 関連スレッド: “Apple rearranged its XNU kernel with exclaves” https://news.ycombinator.com/item?id=43314171

    • その記事の要約を見ると、exclaveはメインカーネルであるXNUから分離された特定のリソースを指し、カーネルが侵害されてもアクセスできないと説明している
      また、macOSの中間リリースに次のメジャーバージョンに備えた機能が入ることは珍しくないが、Sonoma 14.4とiOS 17.4、iPadOS 17.4、watchOS 10.4に追加された最も根本的で重要な機能がexclaveかもしれない、としている
      https://eclecticlight.co/2024/08/20/sonomas-unfinished-busin...

  • 物理カメラのLED制御にセキュアなexclaveを使うのはかなり驚きで、単純なことのために過度に複雑な設計をしているように見える
    カメラモジュールにごく小さな専用ハードウェアロジックを入れるだけで十分だったように思う。デジタル入出力やカメラ電源をゲートし、カメラロジックを素早くオン・オフする攻撃を防ぐために、LEDが毎回最低数秒は点灯するようパルスストレッチャーを置けばよい
    マイクにも似た回路と別色の物理LEDを用意するとよさそう。画面上にソフトウェアで表示される点だけでは不十分

    • 思ったより複雑。 “カメラ”は複数の部品の集合体。CMOSセンサーの電源を基準にしたくなるが、スタンバイ・省電力・アイドルのような複数の電力段階がある。だからハードウェア回路は電圧だけでなく電流も把握する必要がある可能性が高い。あるいはもっと上位でI2Cのようなメッセージをパースして電源モード変更を読む必要があるかもしれない
      LEDドライバも画面輝度や環境光センサーの情報を知る必要がある。直射日光の下でも見えるほど明るくなければならないが、その明るさは暗い環境では不快で、通常のカメラ利用を妨げることもある
      SKが安全だと信じるなら、それを使うほうがより単純で、しかもうまくできる。SKが安全でないと見るなら、いずれにせよすべての前提が崩れる
    • 過剰設計ではない。こうした研究やCharlie Millerのような他の研究者の成果があるために必要なもの
      Appleは概して、正当な理由なしにわざと複雑にすることはない
      https://news.ycombinator.com/item?id=42260379
    • 過剰設計なのか、それとも膨大な数のスマートフォンを出荷する中で見つけた何かへの解決策なのか気になる。カメラをセキュリティベクターとして考えたことはなかったが、Appleはそう見ているのかもしれない
    • 関連する背景はこちらにより詳しくある: https://news.ycombinator.com/item?id=42260379
    • カメラLEDだけでなく、アプリがマイク・カメラ・画面録画にアクセスするときにメニューバーに出るオレンジ・緑・青の点のような画面上のインジケーターも関係しているように思う

  • この書き手が誰なのか気になる。非常に緻密でよく書かれた文章で、exclaveを追っていた立場から見てもよく整理されている

  • これがLinuxのVirtualization Based Securityとどう比較されるのか気になる
    動画のあるページによると、このセキュリティ機能はカーネルを強化し、カーネルが侵害されても重要なカーネルリソースが改ざんされないことを保証できる。VBSはハードウェア仮想化とハイパーバイザーであるHyper‑Vを使って、より高い信頼レベルであるVirtual Trust Level 1(VTL1)で動作する隔離された仮想環境を作り、VTL1はGuestカーネルから分離された独自のカーネルであるSecure Kernelを持つ
    https://lssna24.sched.com/event/1aIeD/linux-virtualization-b...

    • Exclaveは並列的な信頼レベルで実行される

  • Exclaveは重要だが、中間段階に見える。AppleはXNUのリスクをより小さくしようとしているが、マイクロカーネル構造を完全に受け入れるというより、まだ防御的に動いている段階
    賭けるなら、exclaveはより大きな変化への橋渡しだと思う。Fuchsiaのようなよりモジュール化されたOSかもしれないし、メモリ安全性をハードウェアレベルで強制するCHERI式セキュリティモデルかもしれない
    Appleはコンシューマー向けOSセキュリティで先行しているが、exclaveはシステム設計を完全に考え直した結果というより、パッチワーク的な改善に近い。それでも過去10年の主流OS設計における最大のセキュリティ変化である可能性が高く、全体への影響が見えてくるまでには数年かかるだろう

    • 昔のマイクロカーネルへ戻る方式に見える。ただし現代的な解法と新しい要件を反映した形
      Machが作られた頃は、セキュリティは今ほど大きな関心事ではなかった。現在のマシンは性能が非常に高くなっているので、マイクロカーネルのプロセス間通信が生むオーバーヘッドは無視できる程度になっているのかもしれない

  • このレベルの内容には慣れていないが、見たところenclave自体を攻撃して、カーネルより高い権限へ昇格できるように見える。このハードウェア片が補助プロセッサのようなものなのか気になる

    • Exclaveはハードウェアではなく、カーネルにアクセスさせたくない特定の機微な処理を扱う隔離されたソフトウェア
      なのでこれをエクスプロイトすれば、カーネルにはないアクセス権を得ることになるのはその通り。ただし、それこそが意図。目的は、カーネルが破られてもその機微な領域にはアクセスできないようにすること

  • Appleの文書によるとSPTMは使われていないとされており、これがmacOSのセキュリティにどう影響するのか気になる: https://support.apple.com/guide/security/operating-system-in...
    今のところ、カメラインジケーターを表示する既存のexclaveのようなものは、MacBookには専用ハードウェアがあるのでmacOSには大きく適用されないように思う。ただし今後はmacOSにも適用されるexclaveが出てくるかもしれない

    • その脚注を読み直す必要がある。Page Protection Layer(PPL)とSecure Page Table Monitor(SPTM)は、macOSを除くすべてのプラットフォームで、署名され信頼されたコードの実行を強制すると書かれている。macOSは任意のコードを実行するよう設計されているため。ページテーブル保護を含む他のセキュリティ属性は、サポートされるすべてのプラットフォームに存在する
      つまりmacOSがSPTMを使わないという意味ではない。macOSが未署名コードの実行を防ぐ目的でSPTMを使わないという意味。macOSでは、ユーザーがいくつかの手順を踏めば未署名コードも実行できなければならないから

  • アプリ開発者が Exclave を使えるのか気になる。Apple は社内では驚くような新機能を作っておきながら、開発者には完全に閉ざしていることがあり、それが不満。その結果、銀行アプリ、ウォレット、セキュアメッセンジャーのようなものは、引き続きセキュリティの弱いユーザー空間で動かなければならない

    • 必ずしもそうではない。Apple のユーザー空間も継続的により安全になってきている
      簡単な例として、最近の macOS は、アプリが明示的に選択しなくてもすべてのアプリをサンドボックス内で実行する。このサンドボックスはアプリ同士が互いのファイルを変更するのを防ぐが、以前はこの部分がセキュリティシステムの大きな弱点だった。バンドル署名は初回実行時にしか確認されず、実行のたびに確認されるわけではなかったためだ
    • 現在の設計ではできないと理解している。Exclave はオペレーティングシステム全体に統合され、起動プロセスの一部として開始されるため、比較的静的なものだ。セキュリティ上の理由から、これらのコンポーネント間の関係も静的に定義されている可能性が高い
      現時点ではカーネル対カーネルの構造でもあるため、サードパーティ対応があるとしても、セキュリティデバイスドライバのようなものを実装する程度に限定される可能性が高い。しかし Apple は、サードパーティ製ドライバをハイパーバイザではなくユーザー空間へ押し出そうとしてきた。この移行が exclave の開発と並行して進んでいる点を見ると、サードパーティのドライバ開発者に exclave を使わせる方向へ転換するようには思えない
      Apple がこうしたカーネル強制型のプラットフォーム機能を外部に公開する前に、社内ではるかに安定化させることはよくある。arm64e の ポインタ認証も似た例だ
    • 現在はできない