# Extension Interface Model (EIM) ## 定義 Extension Interface Model(EIM)は、ソフトウェア拡張に必要な機能と制限を「リソース」としてモデル化し、ケイパビリティ(capability)によって保護する枠組みである。拡張の「相互接続性(interconnectedness)」と「安全性(safety)」のトレードオフを、拡張入口(extension entry)ごとに細粒度に指定できる。EIM仕様は、アプリケーション開発者が定義する開発時仕様(状態ケイパビリティ、関数ケイパビリティ、拡張入口)と、拡張マネージャが定義するデプロイ時仕様(拡張クラス)の2段階で構成される。(Source: [[@2025__OSDI__Extending Applications Safely and Efficiently]]) ## 横断的知見 - **拡張の安全性は「最小権限のインターフェース設計」で体系化できる**: 従来の拡張フレームワーク(Lua、WebAssembly、LD_PRELOADなど)は固定された権限か全有無の選択しか提供しないのに対し、EIMはホスト関数呼び出し、変数読み書き、ハードウェアリソース消費までを拡張入口単位で指定する。これにより、Nginxの observability 拡張は読み取りのみ、ファイアウォール拡張は特定の書き込みを許可、といった異なるトレードオフを同一ホスト上で共存させられる。(Source: [[@2025__OSDI__Extending Applications Safely and Efficiently]]) - **ケイパビリティモデルはOSアクセス制御からソフトウェア拡張へ降りてきた**: SELinuxやブラウザマニフェストで使われる細粒度アクセス制御の考え方を、ホストアプリケーションと拡張の間の動的なインターフェースに適用した形態。アプリケーション開発者が「提供可能なリソース」を列挙し、運用者が「デプロイで許可するリソース」を選択する分業が、最小権限の運用を実現する。(Source: [[@2025__OSDI__Extending Applications Safely and Efficiently]]) ## 未解決の問い - EIM仕様の生成を、ホストアプリケーションのソースコードやAPI仕様から半自動化する手法は何か。大規模アプリケーションに対する注釈コストをどう抑えるか。 - 複数の拡張が同じ拡張入口にアタッチされる場合、EIMは個別の拡張クラスを合成する仕組みを持たない。dispatcherパターンを超えた、複数拡張間の相互作用の安全性をどう保証するか。 - EIMのケイパビリティ表現力が、ファイルディスクリプタやネットワークソケットなどのOSオブジェクトへどこまで自然に拡張できるか。 ## 関連 - ソース: [[@2025__OSDI__Extending Applications Safely and Efficiently]] - エンティティ: [[bpftime]] / [[Yusheng Zheng]] / [[Tong Yu]] / [[Yiwei Yang]] / [[Yanpeng Hu]] / [[Xiaozheng Lai]] / [[Dan Williams]] / [[Andi Quinn]] - 概念: [[eBPF]] / [[uprobe]] / [[BPF]] - 関連 MOC: [[AI Infra Telemetry - MOC]] / [[structures/000 Index]]