## Memo
- [[2023__arXiv__bpftime - userspace eBPF Runtime for Uprobe, Syscall and Kernel-User Interactions]]のOSDI採録版？
## Memo with LLM
### 論文情報
- **論文のタイトル**: Extending Applications Safely and Efficiently
- **著者と所属**:
- Yusheng Zheng (UC Santa Cruz)
- Tong Yu (eunomia-bpf Community)
- Yiwei Yang (UC Santa Cruz)
- Yanpeng Hu (ShanghaiTech University)
- Xiaozheng Lai (South China University of Technology)
- Dan Williams (Virginia Tech)
- Andi Quinn (UC Santa Cruz)
- **カンファレンス/ジャーナル名**: OSDI (19th USENIX Symposium on Operating Systems Design and Implementation)
- **発表年**: 2025年7月7-9日（ボストン、米国）
### 論文概要
本論文は、ユーザースペースアプリケーションの拡張をより安全かつ効率的に実現するための2つの主要な貢献を提示しています。拡張インターフェースモデル（EIM）とbptimeという新しい拡張ランタイムシステムを組み合わせることで、細粒度のセーフティ・相互接続性トレードオフ制御と[[eBPF]]スタイル検証、ハードウェアベースの隔離、動的バイナリリライティングを通じた効率的な拡張実装を実現しています。
### 詳細解説
#### 問題設定
ソフトウェア拡張は、ブラウザ、HTTPサーバー、テキストエディタ、データベースなど、多くの応用プログラムに使用されています。拡張により、元のアプリケーションを変更せずに新しい機能を追加したり、動作をカスタマイズしたり、セキュリティを強化したり、パフォーマンス監視を実現できます。
問題設定として、入力はホストアプリケーション、拡張プログラム、ユーザーの入力です。必要なデータとしては、アプリケーション開発者がホストアプリケーションに記述するEIM開発時仕様と、拡張マネージャーがデプロイ時に作成するEIM仕様が必要です。出力は、拡張が実行されたアプリケーションの動作結果です。
現在の拡張フレームワークの課題は以下の3つです：
1. **細粒度のセーフティ/相互接続性トレードオフの支援不足**: 拡張は有用な処理を行うために相互接続性が必要ですが、同時にセキュリティと安定性のためにセーフティが必要です。これらは相反する要求です。
2. **隔離の欠如**: ホストアプリケーションのバグから拡張を保護する必要があります。
3. **効率性の不足**: 既存フレームワーク（例：[[WASM|Web Assembly]]、eBPF uprobe）は高い性能オーバーヘッドを導入します。
#### 提案手法
**拡張インターフェースモデル（EIM）**
EIMは、細粒度のセーフティ/相互接続性トレードオフを指定するための新しいモデルです。主なアイデアは、拡張機能をリソース（capabilities）として表現することです。EIM仕様は2段階で構成されます：
1. **開発時EIM仕様（Development-time EIM）**: アプリケーション開発者が作成します。これは、拡張が利用可能な機能を列挙します。以下の3種類を含みます：
- **状態能力（State Capability）**: ホスト内のグローバル変数の読み書き能力を表現します。例：`read(var)`または`write(var)`形式。
- **関数能力（Function Capability）**: ホスト提供の関数呼び出し能力を表現します。プロトタイプと制約条件（前条件・後条件）を指定します。
- **拡張エントリ（Extension Entry）**: 拡張がオーバーライドできるホストアプリケーション内のポイントを指定します。
2. **デプロイ時EIM仕様（Deployment-time EIM）**: 拡張マネージャーが作成します。各拡張エントリに対して、許可される能力のセット（Extension Class）を指定します。これにより、最小権限原則に従い、各拡張が必要な機能のみにアクセス可能になります。
**bpftime拡張フレームワーク**
bptimeは、EIM仕様を効率的に実装するための新しいユーザースペース拡張ランタイムです。主な設計原則は2つです：
1. **軽量な隔離とセーフティ機構**:
- eBPFスタイル検証：実行時オーバーヘッドなしにセーフティを実装
- ERIM風イントラプロセス隔離：Intel Memory Protection Keys（MPK）を使用して拡張とホスト間の隔離を提供
2. **隠蔽された拡張エントリ**: バイナリリライティングを用いて、使用されていない拡張エントリのコストをゼロにします。
**bptimeの実装詳細**:
- **Loader**: 拡張の検証と初期化を行います。
- **Verifier**: eBPFバイトコードに対してEIM制約を追加し、eBPF verifierを使用して検証します。状態能力をプロトタイプ修正で実装し、関数能力をモックkfunc置換で実装します。
- **Rewriter**: Ptrace、Frida、libcapstoneを用いてホストアプリケーションを動的にインストルメント化し、拡張エントリにトランポリンを注入します。
- **Runtime**: 拡張をホストと同一プロセスで実行し、以下を提供します：
- インプロセス隔離：メモリ保護キーを使用して拡張メモリを保護
- bptimeマップ：eBPFマップ互換のシステムコール不要なデータ共有メカニズム
#### 新規性
従来のアプローチとの比較では、EIMとbptimeは以下の面で新規です：
1. **細粒度制御**: 従来のフレームワーク（例：Lua、WebAssembly、NaCl）は、拡張の能力をプログラムレベルでのみ制御できます。EIMは、拡張エントリごとの細粒度な能力制御を実現します。
2. **開発時/デプロイ時分離**: EIM開発時仕様はアプリケーション開発者が作成し、デプロイ時仕様は拡張マネージャーが作成することで、アプリケーションソースコード変更なしに拡張ポリシーを調整できます。
3. **効率性**:
- 検証ベースのセーフティ実装でランタイムオーバーヘッドを排除
- 隠蔽された拡張エントリにより未使用エントリのコストをゼロに
- eBPF互換性により既存ツールとの統合を実現
4. **eBPF互換性**: bptimeはeBPFエコシステムと完全互換であり、既存のeBPFアプリケーション（例：uprobe、bcc、libbpf）の採用を可能にします。
#### 実験設定
使用したデータセットと評価指標：
1. **テストシステム**:
- System A: Intel Xeon Gold 5418Y（24コア、2.00 GHz）、256GB DDR5メモリ
- System B: Intel Xeon E5-2697-v2（48コア、2.7 GHz）、256GB DDR3メモリ
2. **評価指標**:
- **スループット**: リクエスト/秒（RPS）でシステム容量を測定
- **遅延**: 操作完了までの時間（ミリ秒）
- **オーバーヘッド**: ネイティブ実行との比較による相対的パフォーマンス低下率
3. **評価対象のユースケース**:
- Nginxファイアウォール拡張
- [[2023__SIGCOMM__Network-Centric Distributed Tracing with DeepFlow - Troubleshooting Your Microservices in Zero Code|DeepFlow]]マイクロサービス監視ツール
- [[Redis]]耐久性チューニング（batched I/O、delayed-fsync）
- [[FUSE]]メタデータキャッシング
- SSLトラフィック監視（sslsniff）
- システムコール監視（syscount）
#### 実験結果
具体的な数値結果は以下の通りです：
1. **Nginxプラグイン評価**:
- bpftime: 2% オーバーヘッド（4461 RPS）
- Lua: 11% オーバーヘッド（3982 RPS）
- WebAssembly: 12% オーバーヘッド（3975 RPS）
- ERIM: 11% オーバーヘッド（4024 RPS）
- RLBox: 9% オーバーヘッド（4148 RPS）
→ bptimeはLua/WebAssemblyと比較して5-6倍低いオーバーヘッド
2. **Deepflow評価**:
- ネイティブ: 250,000 RPS（小応答）、47,000 RPS（大応答）
- eBPF DeepFlow: 最大54% スループット低下
- bpftime DeepFlow: 最小1.5倍の改善
3. **Redis耐久性チューニング**:
- デフォルト alwayson: 13,000 req/sec
- Batch size 48: 53,000 req/sec（4.17倍改善）→クラッシュ時のデータ損失は24件に制限
- delayed-fsync（fast-notify付き）: 65,000 req/sec（5倍以上改善）→クラッシュ時データ損失5桁削減
4. **FUSE操作遅延**:
- Passthrough fstat: 3.65秒 → 0.176秒（20倍改善）
- LoggedFS fstat: 7.40秒 → 0.184秒（40倍改善）
- LoggedFS openat: 17.0秒 → 0.074秒（230倍改善）
- Passthrough find: 5.1秒 → 1.6秒（3倍改善）
5. **sslsniff性能**:
- ネイティブ: ~19.7kbps（1KBデータ）
- Kernel eBPF sslsniff: 28% スループット低下
- bpftime sslsniff: 7.41% スループット低下（3.79倍改善）
6. **syscount評価**:
- eBPF: 監視プロセス10.3%、非監視プロセス9.6%オーバーヘッド
- bpftime: 監視プロセス3.36% オーバーヘッド、非監視プロセスに影響なし
7. **マイクロベンチマーク比較**:
- uprobe遅延: eBPF 2561.57ns → bpftime 190.02ns（13.5倍高速化）
- uretprobe遅延: eBPF 3019.45ns → bpftime 187.10ns（16.1倍高速化）
- ユーザーメモリ読み書き: eBPF 23.3/23.9ns → bpftime 1.5/1.4ns（15倍以上高速化）
- ハッシュマップ操作: eBPF比で最大5倍高速化
8. **eBPFベースランタイムとの比較**:
- bptimeはubpf、rbpfと比較してマイクロベンチマークで平均1.53-1.72倍高速化
論文内容の重要な洞察：以上の結果から、bptimeはセーフティ、隔離、効率性の3つの要件を同時に満たしており、既存フレームワークと比較して大幅なパフォーマンス向上を実現していることが確認されました。特に、検証ベースのセーフティ実装と隠蔽された拡張エントリの組み合わせにより、ランタイムオーバーヘッドを最小化しながら強い安全保証を提供しています。
## Abstract
本論文は、拡張インターフェースモデル（EIM）とbptimeを提案し、ユーザースペースアプリケーションのより安全かつ効率的な拡張を実現しています。EIMは、拡張の必要な機能をリソースとして扱う新しいモデルで、具体的なハードウェアリソース（メモリなど）と抽象的なリソース（拡張アプリケーションから関数を呼び出す能力など）を含みます。拡張マネージャーがEIMを使用して、拡張がタスクを実行するために必要なリソースのみを指定します。bptimeは、EIM仕様を実行する新しい拡張フレームワークであり、拡張Berkeley Packet Filter（eBPF）スタイルの検証、ハードウェアサポートの隔離機能（Intel MPKなど）、動的バイナリリライティングを使用することで、既存のシステムと比較して効率的です。さらに、bptimeは現在のeBPFエコシステムとの互換性により、既存のワークフローへの採用が容易です。本論文は、セキュリティを向上させ、パフォーマンスを監視し向上させ、設定トレードオフを検討する6つのユースケースを通じて、EIMとbptimeの有用性を実証しています。