LiteBoxは、ホスト（実行環境を提供する側）との接点を絞るライブラリOS（オペレーティングシステム（OS）の機能を部品として提供する仕組み）です。Platformは実行環境の機能をつなぐ部品です。

userland（通常のアプリが動くユーザ空間）の実装はLinuxとWindowsのx86_64（x86系の64ビット命令セット）向けです。ゲスト（実行されるプログラム）とホストは、同一プロセス（実行中のプログラム単位）のメモリを共有します。ソースは、ゲストコードなどがホストメモリを読み書きできると明記しています。[17, 18]

LiteBoxは開発中であり、API（ソフトウェアが機能を呼び出すための規約）が今後変更される可能性があります。

ホストとの接点と隔離の設計課題

信頼できないプログラムを動かすとき、ホストのどの機能やデータに届くかを確認することが、隔離設計の課題になります。ホストは実行環境を提供する側です。プログラムがOSに処理を求める呼び出しをシステムコールと呼びます。ホストカーネル（OSの中核部分）のAPIや共有機能へ届く経路が増えると、構成が複雑になります。攻撃に使われる面も広がる可能性があります。

共有カーネルが侵害された場合、同じカーネルを使うほかのコンテナにも影響が及び得ます。[6]

コンテナはホストOSの資源を活用する軽量なアプリ実行・展開単位です。ホストのバインドマウント（ホストの指定パスをコンテナ内に接続する仕組み）を使う場合、共有する範囲や書き込み権限によっては、コンテナ内の処理がホスト上のファイルを書き換えられます。どの資源を共有し、何を許可するかが設計上の確認点です。[7, 8]

仮想マシン（VM）は独自カーネルを含むゲストOSを動かし、ゲストOSごとの環境やホストとの強い分離を求める用途に向きます。仮想マシンは、その分、より多くのシステム資源を必要とします。Hyper-V（Microsoftの仮想化基盤）の統合サービス（ゲストOSとホスト間の連携機能）を有効にすると、ホストとの通信、メタデータ（付帯情報）の交換、ファイルコピーなどの接点が生まれます。コンテナとVMは、それぞれの分離と資源の条件に応じて選ぶものです。[8, 9]

後輩境界を決めるときは、方式の名前より実際に共有するものを見るんですね。

先輩そうだね。共有カーネルやマウント、ホスト連携機能を見れば、処理が届く範囲を具体的に考えられるよ。

後輩すると、軽さや分離の強さだけで決めず、必要な接点も選ぶことになりますね。

先輩その通り。用途に必要な資源と境界を先に定めると、方式の比較がしやすくなるね。

v0.1.0の初回リリースとAPI変更の可能性

Microsoftはv0.1.0を「Initial release」（初回リリース）として公開しました。タグ（特定のリリースを示す名前）は、コミット（変更履歴に保存されたソースコードの状態）d8556e3を指しています。リリースページは、今後のリリースに変更履歴を付ける予定も示しています。

公式リポジトリには、このタグより前のコード公開活動も記録されています。記録には、カーネル向け実装のIssue（報告・議論の記録）や、2026年2月のプルリクエスト（コード変更の提案）へのレビューが含まれます。[1, 5]

READMEは、LiteBoxが安定版に向けて開発中で、設計の成熟に伴いAPIやインタフェースが変わる可能性を明記しています。利用する開発者は、この変更可能性を踏まえて対象アプリとの互換性を検証します。[4]

公式のSUPPORT.mdは、バグ報告や機能要望をGitHub Issuesで扱い、利用できるサポート資源を案内しています。READMEは利用例を列挙しています。開発者は、アプリや環境ごとの互換性と本番運用のサポート範囲を、個別の記載で確認する必要があります。[23]

NorthとSouthの役割分担

LiteBoxは、ホストとのインタフェースを減らし、攻撃に使われ得る接点（攻撃面）を縮めることを掲げるライブラリOSです。ライブラリOSは、OSに似た機能をソフトウェア部品として提供する仕組みです。LiteBoxはアプリ側のNorthインタフェースと、実行環境側のSouthに置くPlatformを組み合わせます。

READMEは、プログラミング言語Rustで扱うNorthのインタフェースが、OS機能を呼び出すライブラリnixとrustixに着想を得たと説明しています。[2, 10]

部分担当すること
Northのshimshimはアプリ側の要求を橋渡しする層です。Linux shimはLinux互換ABI（アプリとOSの間のバイナリレベルの呼び出し規約）を受け持ち、システムコール要求を解釈して対応する処理へ振り分けます。[12]
LiteBoxの中核Platform Provider（実行環境の機能を提供する部品）を受け取り、POSIX（Unix系OSの共通API規格）風のインタフェースを提供します。ファイル記述子（開いたファイルを識別する番号）、ファイルシステム、メモリ、ネットワークなどの共通機能を扱います。[11]
SouthのPlatform実行環境ごとの接点です。同期は、複数の処理の順序を調整する仕組みです。IPパケットは、IP（インターネットプロトコル）ネットワークで送るデータ単位です。時刻や中央処理装置（CPU）の命令体系、ポインタ（メモリ上の位置を指す値）も扱います。カーネル向けPlatformは、HostInterface（ホスト機能へのアクセスを仲介するインタフェース）を介して、ホストのページ割り当て（メモリを固定サイズの単位で確保する機能）を利用します。[14]

実行時には、ゲストのシステムコールに応じてPlatformがshimの入口を呼びます。shimは要求を処理し、実行再開または終了を示す値を返します。つまり、Northがアプリ側の要求を受け持ち、Southが実行環境ごとの機能をつなぎ、中核が共通OS機能を提供する構成です。[13]

後輩NorthとSouthを組み合わせられると、環境をまたぐ開発の見通しはよくなりそうです。

先輩要求の受け取り方と実行環境の接続を分けて考えられる設計だね。

後輩ただ、部品を組める設計と、どのアプリも動くことは別の確認ですね。

先輩そうだよ。対象のアプリが使う要求と、選んだPlatformの実装条件を照らす必要があるね。

Linux・Windowsの実行条件と利用例

v0.1.0のuserland Platformは、Linux/x86_64向けとWindows/x86_64向けです。userlandは通常のアプリが動くユーザ空間を指し、x86_64はx86系の64ビット命令セットアーキテクチャです。両方の実装では、ゲストとホストが同じプロセスのアドレス空間（プロセスが使うメモリ上の範囲）を共有します。

ソースは、ゲストコードなどがホストメモリを読み書きできると明記しています。[17, 18]

Linux上でLinuxプログラムを動かすrunner（プログラムを起動するツール）は、入力を既定でホストファイルシステム上のパスから受け取ります。実行時のシステムコール書き換えはunstable（実験段階の機能）扱いの補助機能です。READMEは、実運用では事前書き換えを選ぶ可能性に言及しています。[19]

Windows上でLinuxプログラムを動かすrunnerは、プログラムと依存ファイルをtar（複数ファイルをまとめるアーカイブ形式）にまとめます。さらに、開発者はELF（実行ファイルの形式）バイナリをsyscall rewriter（システムコール呼び出しを書き換えるツール）で事前変換する必要があります。[19, 20]

Linux userland Platformでゲストのネットワークを使うには、初期化済みTUNデバイス（ネットワークパケットを扱う仮想ネットワーク機器）へのアクセスが必要です。デバイス名を指定しない構成ではネットワークが無効になります。こうしたファイルやネットワークの準備も、Platformごとの実行条件に含まれます。[21]

READMEは、Windows上でのLinuxプログラム実行やLinuxアプリの隔離を例に挙げます。Linux上でOP-TEEのプログラムを動かす例も含まれます。OP-TEEは、公式文書で信頼実行環境として説明されるソフトウェア基盤です。これらはプロジェクトが示す利用例です。

開発者は、対象アプリと実行環境の組み合わせごとに、必要なシステムコール、ファイル、ネットワークを確かめます。メモリ境界（読み書きできるメモリの範囲）も確認対象です。[3, 22]

実装と条件に基づく安全性・互換性の評価

メモリ安全性は、プログラムが不正なメモリアクセスをしない性質です。RustのSafe Rust（コンパイラの安全性検査が適用されるコード）には、コンパイル時のメモリ安全性保証があります。unsafe Rust（ポインタ操作などのunsafe操作を含むコード）では、実装者が各unsafe操作の安全性を確認します。[15]

本稿では、ホスト資源へのアクセス制御を評価する際、Platformのポインタ受け渡しとコピー処理を確認する方法を提案します。

v0.1.0のソースにあるLinux kernel Platformには、ポインタがユーザ空間にあるかを検証する処理が未実装とのコメントがあります。ポインタ型には、検証を行わない設定を示すNoValidationが指定されています。これはカーネル向けPlatformの実装に関する確認事項です。[16]

RawPointerProviderのソースコメントは、ユーザとカーネルを分離する実装に、必要なコピー処理を行う型の定義を求めています。実装ごとのポインタ受け渡しも確認対象です。

LiteBoxの設計思想はNorth shimとSouth Platformの組み合わせを可能にします。一方、動作範囲は選んだ実装と準備条件に左右されます。導入を検討する開発者は、対象プログラムのシステムコール、Platform、ファイルとネットワークの接点、メモリ境界を確認し、その構成で動作を検証する必要があります。v0.1.0ではAPI変更の可能性も示されています。

[4, 17, 18, 19, 20, 21]