ハクソク

世界を動かす技術を、日本語で。

Show HN: CoWメモリフォークを使用したサブミリ秒VMサンドボックス

69日前原文(github.com)

概要

  • Zeroboot は、 AIエージェント向けサブミリ秒VMサンドボックス を実現
  • Firecracker を活用し、 コピーオンライト(Copy-on-Write)フォーク による高速起動
  • 各サンドボックスは 本物のKVM仮想マシン で、ハードウェアレベルのメモリ分離を実現
  • APIやSDK を通じてPythonやTypeScriptから利用可能
  • 現状は プロトタイプ であり、プロダクション運用には未対応

サブミリ秒VMサンドボックスの仕組みと特徴

  • Firecracker でVMを一度だけ起動し、Pythonやnumpyなどランタイムを事前ロードした状態で スナップショット 取得

  • 新しい実行ごとに KVM VMをコピーオンライトでフォーク し、スナップショットメモリを MAP_PRIVATE でマッピング

  • 各サンドボックスは 独立したKVM VM として起動、 ゲストカーネル・メモリ・ページテーブル も完全に分離

  • コード実行後は即終了、 超高速なサンドボックス起動 を実現

    • 起動レイテンシ(p50): 0.79ms（従来のDaytonaやE2B microsandboxと比較して圧倒的に高速）
    • 起動レイテンシ(p99): 1.74ms
    • サンドボックスごとのメモリ消費: 約265KB
    • Pythonでのfork+exec時間: 約8ms
    • 同時1000フォーク時の合計時間: 815ms

  • ハードウェアレベルのメモリ分離 により、セキュリティ・アイソレーションを確保

  • LinuxのCoW機能 により、メモリ効率も抜群

API・SDKによる利用方法

  • API エンドポイント例
    • curlコマンドでPOSTリクエスト送信し、コードを即時実行
  • Python SDK
    • from zeroboot import Sandbox
    • sb = Sandbox("zb_live_your_key")
    • result = sb.run("print(1 + 1)")
  • TypeScript SDK
    • import { Sandbox } from "@zeroboot/sdk";
    • const result = await new Sandbox("zb_live_your_key").run("console.log(1+1)");

アーキテクチャと現状

  • Firecracker でテンプレートVMを一度だけ起動し、 スナップショット を取得
  • 新規リクエストごとに KVM VMをフォーク し、 CoWメモリ を利用しつつCPU状態も復元
  • 完全なVM分離 によるセキュリティ
  • Rust で実装、 Apache-2.0ライセンス
  • プロトタイプ段階 であり、商用運用前の状態
  • 興味があれば GitHub Issue で問い合わせ可能

技術的な工夫点

  • 毎回新規VMをブートせず、スナップショットから即時復元
  • CoW自体よりも、スナップショットVMの正しい再開処理が難関
  • 各サンドボックスは 本物のKVM VM であり、 コンテナとは異なる完全分離
  • 書き込み時は個別ページを自動複製、高いセキュリティと効率性

まとめ

  • AIエージェントやコード実行基盤 に最適な、 超高速・高セキュリティなサンドボックス基盤
  • 従来技術と比較して圧倒的な起動速度・省メモリ
  • 今後の本番運用やOSS貢献にも期待

Hackerたちの意見

特定のバージョンのファイアクラッカーでしか動かないの？それに、1つのvCPUのVMだけ？サブミリ秒の起動時間よりも、VMごとに258KBのRAMが必要なのが大きいね。

└

現在はフォークごとに1つのvCPUだね。マルチvCPUも可能だけど（vCPUごとの状態をループで復元する感じ）、フォーク時間が増えちゃう。Firecrackerのバージョンについては、v1.12でテストしたけど、vmstateパーサーがオフセットを自動検出するから、ハードコーディングせずにバージョンを跨いで動くはずだよ。

これがうまくいくのを見るのはいいね！exe.devを立ち上げる前にこれを試してみたんだけど、VM自体はすごく良く動いたよ。ただ、ネットワークを機能させるためのセットアップが結構大変だった。結局、我々のターゲットは~1秒の起動時間を気にしないユースケースだから、毎回クリーンなsystemdスタートをする方が楽だったんだ。それでも、最小限のもの、例えばPythonインタープリターのためにVMを使いたい人たちのユースケースもいくつか見たことがある。これはまさに彼らが使うべきアプローチだね。すごく期待してる、どこまで進められるか楽しみ！

└

simonwはいつもあなたが言ってることを求めてるみたいだけど、もっとwasm向けかもね。

└

みんなが見落としがちなのは、CoWが輝くのは基本イメージを更新する必要がないときだけで、更新が必要になると古いメモリやホットパッチで手間がかかるってこと。スナップショットは魔法のようなブートを提供してくれるけど、数百のフォークにセキュリティ修正を展開しなきゃならなくなったら、神様助けてって感じだよ。素早いスタートはいいけど、「信頼できるコードベースで普通のPythonを実行する」っていうワークロードなら勝てるけど、複雑になるとメンテナンスの負担が増えて、結局は無駄な作業に戻っちゃう。

これを本番環境でやるのは、ノード間でサンドボックスをクローンするのが難しいんだよね。常駐メモリやファイルシステム（またはrootfsの上にあるCoWレイヤー）をスナップショットして、データをノード間で移動させる必要がある。

└

これ、関係ある？ https://codesandbox.io/blog/how-we-clone-a-running-vm-in-2-s...

└

そうだね、ノード間の連携が次の難しいステップだね。今のところ、シングルノードの密度でも意外と進むよ。$50のボックスで1000のサンドボックスが同時に動くからね。マルチノードが必要になったら、userfaultfdを使ってリモートページを取得するのが有力な道だと思う。

└

各ノードに起動を待っているウォームアップ済みのVMがあるなら、ノード間でクローンする必要はないね。

あなたの書き込みを見て思い出したのがこれだよ: https://codesandbox.io/blog/how-we-clone-a-running-vm-in-2-s... 似たようなことある？

これ、パススルーが必要なの？それとも、パススルーなしのクラウドVM/VPSでPVMを活用できるかも？

└

何を聞きたいのか正確にはわからないけど、Firecrackerは/dev/kvmにアクセスする必要があるから、VMでネスティングを有効にしないといけないよ。

エントロピーを忘れないで！ランダム数生成器の同一コピーを2つ作っちゃったから、セキュリティにはすごく悪影響があるかもしれないよ。ファイアクラッカーチームは、スナップショットサポートを追加したときにこれに対処するための良い論文を書いてた。

└

RNGの再シードは簡単そうだけど、ASLRの再配置はめんどくさそうだね。（でもPythonには関係ないかもね）

└

いい指摘だね。スナップショットの前にエントロピーをシードしてgetrandom()をブロックしないようにしてるけど、フォークしたらCSPRNGの状態は共有されちゃうんだ。Firecrackerのドキュメントによると、正しい修正はフォークのたびにRNDADDENTROPYとRNDRESEEDCRNGを使うこと、あとnumpyみたいなユーザースペースのPRNGも別に再シードすることだね。これ、ロードマップに載ってる。

Linux用のサンドボックスツールがたくさん出てきてるのに、Windowsは全然遅れてるのがイライラするよね。Windows Sandbox（https://learn.microsoft.com/en-us/windows/security/applicati...）なんて、カスタマイズ可能なネットワーキングのホワイトリストすらないんだから。ネットワーキングをオンオフできるだけで、それ以上の細かい設定はできない。だから、デスクトップのWindows関連のことをやってる私たちは、エージェントを安全なボックスに簡単に入れる方法がないままなんだよね。

└

Windows Sandboxではウェブブラウザがちゃんと動かないんだ。1年以上パッチが当たってないバグがあって、ウェブブラウザがGPUを使ってページをレンダリングできないから、表示されるのは真っ白なページだけなんだ。ユーザーはvGPUをオフにする設定ファイルを作って、それからWindows Sandboxを起動しなきゃいけない。

└

これを宗教戦争にしたくはないけど、正直言って、Windowsが徐々に消えていくことで人類にどんな利益があるのか、時々考えちゃう。これはMicrosoftが過去にやった良いこと（Windows 9*のUIとか、Win32 APIの数十年にわたるサポートとか）を評価している人間として言ってるんだけどね。

└

Microsoftに連絡するか、オープンソースソフトウェアを使うか、どっちか忙しくしてみては？

└

わかるよ。だから、デイトナではWindowsとmacOSのサンドボックスサポートに積極的に取り組んでるんだ。適切な隔離、エージェントツール、動的リサイズなど、単なる「ネットワークのオン/オフ」レベルのコントロールじゃなくてね。Windowsでエージェントを構築してるなら、早期アクセスを希望するなら連絡してね。

└

デイトナでWindowsのサンドボックスにアクセスできるよ。ここに記入して教えてね！ https://www.daytona.io/docs/en/computer-use/

いいね！俺も似たようなことに取り組んでるけど、スナップショットの復元時間じゃなくてLinuxのブート時間を短縮する方だよ。もちろん、俺の解決策は重いランタイムには効かないけどね。

本当に素晴らしい仕事だね。CoWフォークによるサブミリ秒のコールドスタートはかなり賢いアプローチだと思う。ただ、エージェントサンドボックスでいつもぶつかる難しい部分は、コード実行はその一部に過ぎなくて、エージェントはファイルシステムアクセス、メモリ、git、pty、他にもいろんなツールが必要で、それらがすべて接続されて隔離されている必要があるってこと。ここがすぐに厄介になるところなんだよね。