- KVMベースの単一プロセス・サンドボックス
- 一般的なLinuxプログラムや特定のAPIを使うプログラムをサンドボックス内で実行可能
- ハードウェア仮想化を使ってネイティブ性能を提供
- KVM APIの一部のみを使用 → コードベースが小さく効率的
TinyKVMの設計
- 静的Linux ELFプログラムの実行をサポート
- 動的実行ファイルのサポートは今後追加予定
- 外部HTTPサーバーまたはキャッシュへのアクセスを提供するためにAPIとして拡張することも可能
- 現在はAMD64(x86_64)で動作し、AArch64(64ビットARM)への移植を計画中
- Hugepageサポート
- ゲストページにhugepageを作成可能
- ホスト側でもhugepageを利用可能 → 性能向上の効果
- 例: 2MBページを割り当てた場合、LLVMコンパイル性能が5%向上することを確認
- 高速な関数呼び出し
- ゲストで関数を呼び出す際のオーバーヘッドは2μs
- タイマーなしで実行するとオーバーヘッドは1.2μsまで低下
- リモートデバッグをサポート
- GDBでリモートデバッグ可能
- デバッグ後に通常どおりプログラムを再開可能
- Copy-on-Writeサポート
- 独自のfork機能をサポート → メモリ複製を最小化可能
- 例: 6GBモデルを複製する場合、インスタンスごとに必要なメモリは260MBのみ
- 高速な状態初期化
- ゲスト状態を高速にリセット可能 → セキュリティ強化
- リクエストごとにリセットすれば状態露出リスクを低減
- 簡素化されたコードベース
- KVM APIでは約42k LOCを使用
- TinyKVM自体のコードベースは約9k LOC → 競合ソリューションよりはるかに小さい
- 例: Wasmtime 350k LOC, FireCracker 165k LOC
- 静的ページテーブル生成
- 実行時にページテーブルを変更不可 → セキュリティ強化
- ページテーブルの整合性チェックを実施
- 分離されたプロセスコンテキスト
- KVMゲストは別個のPCID/ASIDを使用 → Spectreなどの投機的実行攻撃に強い
- セキュリティ強化カーネル
- SMEP、SMAPを有効化
- ユーザーモードでCPU例外を処理可能
システムコール処理
- ホストとのAPI接続
- SYSCALL/SYSRETまたはOUT命令を通じてシステムコールを実行
- システムコール実行時にVM exitが発生 → 約1μsを要する
- 小さな呼び出しを減らし、大きな入出力単位のAPI設計を推奨
ベンチマーク
- VM呼び出しオーバーヘッド
- VMリセット時のtail latencyを測定
- リセットなしの単純呼び出しではオーバーヘッドは低い
- メモリ性能
- メモリ性能は正常な水準
- 例: HTTPベンチマークで毎秒1500件のAVIFエンコードが可能
- JPEG → AVIF変換性能
- 毎秒約1582枚の画像を変換可能
- YUV変換経路を使ってロスレス変換が可能
高速なサンドボックス性能の理由
- I/Oおよびドライバーを使わない
- I/O、ドライバー、仮想デバイスがない → 性能低下を防止
- CPUリソースのみを使用 → ネイティブ速度に近い
- Hugepage最適化
- hugepageの使用でページウォークを削減 → 性能改善
- 大規模LLMワークロードで99.7%のネイティブ性能を達成
- 高速なVM呼び出し
- ゲストでの関数呼び出し時のオーバーヘッドを最小化
- ネイティブCPU速度でデータ処理が可能
制約
- vCPU数を減らせない
- KVM APIではvCPU数の削減が不可能
- マルチプロセッシングは複数VMの並列実行で対応可能
- リセット性能低下の問題
- VM状態のリセット時に性能低下が発生する可能性
- ただし状態共有と複製によって解決可能
今後の課題
- Intel TDXおよびAMD SEVサポートの追加
- AArch64への移植
- メモリロック(KVM_MEM_READONLY)機能の追加 → セキュリティ強化
- ユーザーフレンドリーなAPIへの改善
- 動的リンク読み込みサポートの追加 → Varnishとの統合を強化
結論
- TinyKVMは最も小さく高速なサンドボックスソリューションの1つ
- セキュリティ強化と性能最適化の両方を達成
- コードベースが小さく保守しやすい
- オープンソースライブラリとして提供中 → 興味があればコードリポジトリを確認可能
TinyKVMリポジトリ
2件のコメント
ユニークだね
Hacker Newsの意見
これは本当に気に入った。今やっていることをこのまま続けてほしい
Firecrackerに似ているが、ずっと高速だ
元の投稿: リンク
とても興味深い。2.5usのスナップショット復元性能はWasmtimeに匹敵する一方で、ネイティブコードを実行できる大きな利点がある。ただし、相互運用性ははるかに遅いとはいえ、それでもマイクロ秒単位だ
基本的にはlibkrunのようなものでは？ リンク
これはまさに想定用途というわけではないが、Xサーバー（またはWayland）を動かした経験がある人はいますか？
興味深いが、大きな全体像を理解するのに苦労している。これはカーネルなしでVM内のユーザープロセスを実行するということなのか？ すべてのシステムコールはVM終了となってホストへプロキシされるのか？ それともシステムコール自体がないのか？
ユースケースに合うなら本当にすばらしい
本当にすごい
記事にはVarnishの上で動作するとは書かれておらず、実際に著者もそれはVarnishを動かすためのものではないと言っている