> [!abstract] 概要(Abstract 日本語訳) > ユニカーネルは、起動時間、スループット、メモリ消費量などの指標で優れた性能を提供することで知られている。しかし、その性能を引き出すことは難しく、非常に時間がかかるうえ、アプリケーションをユニカーネルへ移植するには大きなエンジニアリング作業を要することで悪名高い。本論文は、(1) OS プリミティブを完全にモジュール化してユニカーネルのカスタマイズと関連コンポーネントだけの組み込みを容易にし、(2) 開発者が高性能を得やすい、合成可能で性能志向の API 群を公開する、新しいマイクロライブラリ OS である Unikraft を導入する。 > nginx、SQLite、Redis などの既製アプリケーションを用いた評価では、Unikraft 上で動作させると Linux ゲストに対して 1.7〜2.7 倍の性能向上を得られる。これらのアプリケーション向け Unikraft イメージは約 1 MB で、実行に必要な RAM は 10 MB 未満であり、VMM の時間を除けば約 1 ms で起動する(合計起動時間は 3〜40 ms)。Unikraft は Linux Foundation のオープンソースプロジェクトであり、ソースコードは www.unikraft.org で公開されている。 ## 論文情報 - タイトル: Unikraft: Fast, Specialized Unikernels the Easy Way - 著者: Simon Kuenzer、Vlad-Andrei Bădoiu、Hugo Lefeuvre、Sharan Santhanam、Alexander Jung、Gaulthier Gain、Cyril Soldani、Costin Lupu、Stefan Teodorescu、Costi Răducanu、Cristian Banu、Laurent Mathy、Răzvan Deaconescu、Costin Raiciu、Felipe Huici - 所属: NEC Laboratories Europe GmbH、University Politehnica of Bucharest、The University of Manchester、Lancaster University、University of Liège - 媒体: EuroSys '21、2021年4月26〜29日、オンライン開催 - DOI: https://doi.org/10.1145/3447786.3456248 - Artifact repository: https://github.com/unikraft/eurosys21-artifacts - プロジェクト: https://www.unikraft.org ## 概要 Unikraft は、単一アドレス空間と単一保護レベルを前提に、OS の各機能とその API を交換可能なマイクロライブラリへ分解するユニカーネルである。既存アプリケーションを POSIX 互換層から動かせるだけでなく、性能が重要な経路では低レベル API へ接続し、ネットワーク、メモリ、ブート、ファイルシステムをアプリケーション向けに選択できる。 従来のユニカーネルが抱える「高性能化に専門家の大きな作業が必要」「POSIX 非互換で移植が難しい」という二つの問題に対し、Unikraft は完全なモジュール化、性能志向 API、musl と syscall shim、静的リンクを組み合わせる。論文の評価は、変更なしのアプリケーション、手動移植したアプリケーション、低レベル API へ特殊化したアプリケーションを分けて行う。 ## 問題設定 標準 OS は、複数プロセス、複数アドレス空間、ユーザー・カーネル保護境界、汎用スケジューラ、階層的なネットワーク・ストレージ API などを一つのカーネルに含める。単一アプリケーションを仮想マシンで実行する場合、これらの一部はハイパーバイザーが提供する分離と重複する。 論文は、単一アプリケーション向けには、保護ドメイン切り替え、複数アドレス空間、スケジューラ、汎用ネットワークスタック、VFS とファイルシステム、カーネル内メモリアロケータのいずれも不要または過剰になりうると整理する。例えば RPC サーバーは単一の run-to-completion イベントループで処理でき、UDP アプリケーションは DPDK 型のドライバ API を直接使え、ストレージ集約型アプリケーションは NVMe に直接アクセスできる。 解くべき問題は、アプリケーションごとに最適化された OS を作りながら、OS 関連の開発量を制限し、既存アプリケーションの移植を容易にすることである。 ## 設計原則と解空間 Unikraft の設計原則は次のとおりである。 - 単一アドレス空間: 単一アプリケーションを対象にし、必要なら複数アプリケーションをネットワーク通信で接続する。 - 完全なモジュール化: OS プリミティブ、ドライバ、プラットフォームコード、ライブラリ、API を追加・削除できるようにする。 - 単一保護レベル: 仮想化環境ではハイパーバイザーが分離を提供するため、ユーザー・カーネル間の保護切り替えをなくす。 - 静的リンク: Dead Code Elimination(DCE) と Link-Time Optimization(LTO) により不要コードを自動削除する。 - POSIX サポート: 既存アプリケーションと言語環境を受け入れつつ、POSIX の下で特殊化する。 - プラットフォーム抽象化: 複数の VMM、ハイパーバイザー、CPU ターゲット向けのイメージを生成する。 Linux カーネルのコンポーネント依存関係は密で、単一コンポーネントを削除・置換するにも多数の依存関係を理解して修正しなければならない。Figure 1 はその依存グラフを示し、Figure 2 と Figure 3 は nginx と Hello World の Unikraft 依存グラフを対比する。 ![[_attachments/2026_Unknown_Unikraft/fig01-linux-dependency-graph.png]] (Figure 1. Linux カーネルコンポーネントの強い相互依存性。コンポーネントの削除・置換を難しくする依存関係を示す。Source: 論文 Figure 1。) ![[_attachments/2026_Unknown_Unikraft/fig02-nginx-dependency-graph.png]] (Figure 2. nginx Unikraft イメージの依存グラフ。Linux 全体より少数のコンポーネントへ縮約されている。Source: 論文 Figure 2。) ![[_attachments/2026_Unknown_Unikraft/fig03-helloworld-dependency-graph.png]] (Figure 3. Hello World の最小 Unikraft 依存グラフ。ukboot、nolibc、ukalloc などだけで構成される。Source: 論文 Figure 3。) ## 提案手法 ### マイクロライブラリとビルドシステム Unikraft は、同じ API を実装する交換可能なマイクロライブラリと、Kconfig ベースのビルドシステムからなる。マイクロライブラリは依存関係を最小化した小さなソフトウェア部品であり、スケジューラ、メモリアロケータ、ネットワークスタック、ブートコードなどを実装する。同一 API に複数実装を用意でき、同じイメージ内で複数のアロケータを使うこともできる。 ビルドシステムは利用するマイクロライブラリ、対象プラットフォーム、CPU アーキテクチャ、各ライブラリの設定を選択し、依存関係を解決してリンクする。Hello World の最小構成は KVM で 200 KB、Xen で 40 KB となり、プラットフォームのブートストラップと nolibc だけを必要とする。 Figure 4 は、アプリケーションから libc、POSIX 互換層、OS プリミティブ、プラットフォーム層までを API 境界で接続する全体構成を示す。番号は、アプリケーションを POSIX 層から低レベルのネットワーク・ブロック API へ段階的に接続する特殊化の位置を表す。 ![[_attachments/2026_Unknown_Unikraft/fig04-unikraft-architecture.png]] (Figure 4. Unikraft アーキテクチャ。黒い箱が API であり、複数レベルの API と複数実装を選択できる。Source: 論文 Figure 4。) ### uknetdev API uknetdev はデバイスドライバとネットワークスタックまたは低レベルネットワークアプリケーションを分離する。ドライバはネットワークスタック固有にせず、アプリケーションがドライバを初期化して利用する。API はポーリング、割り込み、混合モード、複数キュー、ゼロコピー I/O、パケットバッチ処理をサポートする。 パケットバッファ `uk_netbuf` の配置はアプリケーションが所有する。これにより、性能を優先するアプリケーションは事前確保したバッファプールを使い、メモリ効率を優先するアプリケーションは通常ヒープから割り当てられる。送受信 API は `uk_netdev_tx_burst` と `uk_netdev_rx_burst` で配列を受け取り、キューへ投入・取得できたバッファ数を返す。 ### ukalloc、uksched、uklock ukalloc は POSIX 互換の外部 API、内部割り当て API、バックエンドアロケータの三層で構成される。musl、newlib、nolibc が外部 API を提供し、内部 API は呼び出し側がアロケータを選択できる `uk_malloc(struct uk_alloc *a, size_t size)` などを持つ。 論文時点で利用できるアロケータは buddy、TLSF、tinyalloc、Mimalloc、Oscar であり、ブート用には bootalloc を使える。uk_slab のように複数領域を分けて同一イメージ内で異なるアロケータを使えるため、ブート、アプリケーション、ガベージコレクションなどの性質に応じた選択が可能になる。 スケジューリングは任意であり、協調型・先取り型スケジューラを選べる。単一スレッドまたは run-to-completion のイメージではスケジューラを削除してゲスト内ジッタを避けられる。uklock はスレッド有無とマルチコア対応の有無に応じて、不要な同期プリミティブをコンパイルから除外する。 ## アプリケーション支援と移植 ### システムコールと POSIX 互換 Unikraft は既存バイナリを実行時に書き換える方式を採用せず、アプリケーションのネイティブビルドシステムで静的オブジェクトを生成し、Unikraft の最終リンクへ接続する。musl は glibc 互換性が比較的高く資源効率もよいため、musl を Unikraft へ移植した。musl の Linux システムコール依存は syscall shim マイクロライブラリで処理し、システムコールハンドラを登録して libc レベルの呼び出しを通常の関数呼び出しへ変換する。 Table 1 は、Intel i7-9700K 3.6 GHz と Linux 5.11 で測定した no-op 呼び出しのコストを示す。 | Platform | Routine call | #Cycles | nsecs | |---|---|---:|---:| | Linux/KVM | System call | 222.0 | 61.67 | | Linux/KVM | System call (no mitigations) | 154.0 | 42.78 | | Unikraft/KVM | System call | 84.0 | 23.33 | | Both | Function call | 4.0 | 1.11 | (Table 1. バイナリ互換性・システムコールのコスト。セキュリティ緩和策の有無を含む。Source: 論文 Table 1。) 実行時 syscall 変換を使う Unikraft のシステムコールは Linux より 2〜3 倍速いが、関数呼び出しより約 10 倍遅い。したがって OSv、Rump、HermiTux のようなバイナリ互換性は移植作業を減らす一方、Unikraft の静的な syscall shim より性能上の不利を持つ。 Table 2 は、外部でビルドしたアーカイブを musl または newlib 経由でリンクしたときの自動移植結果である。`std` は標準層、`compat. layer` は glibc 互換層を使う場合、`glue code LoC` は追加接着コードの行数を表す。 | Library | musl Size (MB) | musl std | musl compat. layer | newlib Size (MB) | newlib std | newlib compat. layer | glue code LoC | |---|---:|:---:|:---:|---:|:---:|:---:|---:| | lib-axtls | 0.364 | × | ✓ | 0.436 | × | ✓ | 0 | | lib-bzip2 | 0.324 | × | ✓ | 0.388 | × | ✓ | 0 | | lib-c-ares | 0.328 | × | ✓ | 0.424 | × | ✓ | 0 | | lib-duktape | 0.756 | ✓ | ✓ | 0.856 | × | ✓ | 7 | | lib-farmhash | 0.256 | ✓ | ✓ | 0.340 | ✓ | ✓ | 0 | | lib-fft2d | 0.364 | ✓ | ✓ | 0.440 | × | ✓ | 0 | | lib-helloworld | 0.248 | ✓ | ✓ | 0.332 | ✓ | ✓ | 0 | | lib-httpreply | 0.252 | ✓ | ✓ | 0.372 | × | ✓ | 5 | | lib-libucontext | 0.248 | ✓ | ✓ | 0.332 | × | ✓ | 0 | | lib-libunwind | 0.248 | ✓ | ✓ | 0.328 | ✓ | ✓ | 0 | | lib-lighttpd | 0.676 | × | ✓ | 0.788 | × | ✓ | 6 | | lib-memcached | 0.536 | × | ✓ | 0.660 | × | ✓ | 6 | | lib-micropython | 0.648 | ✓ | ✓ | 0.708 | × | ✓ | 7 | | lib-nginx | 0.704 | × | ✓ | 0.792 | × | ✓ | 5 | | lib-open62541 | 0.252 | ✓ | ✓ | 0.336 | ✓ | ✓ | 13 | | lib-openssl | 2.9 | × | ✓ | 3.0 | × | ✓ | 0 | | lib-pcre | 0.356 | ✓ | ✓ | 0.432 | × | ✓ | 0 | | lib-python3 | 3.1 | × | ✓ | 3.2 | × | ✓ | 26 | | lib-redis-client | 0.660 | ✓ | ✓ | 0.764 | × | ✓ | 29 | | lib-redis-server | 1.3 | × | ✓ | 1.4 | × | ✓ | 32 | | lib-ruby | 5.6 | × | ✓ | 5.7 | × | ✓ | 37 | | lib-sqlite | 1.4 | × | ✓ | 1.4 | × | ✓ | 5 | | lib-zlib | 0.368 | ✓ | ✓ | 0.432 | × | ✓ | 0 | | lib-zydis | 0.688 | ✓ | ✓ | 0.756 | × | ✓ | 0 | (Table 2. 外部ビルドアーカイブの自動移植結果。Source: 論文 Table 2。) Unikraft は論文時点で 146 個のシステムコールを実装していた。Debian 人気コンテストから選んだ 30 個のサーバーアプリケーションの解析では、必要なシステムコールの半数以上が人気アプリケーションには不要であり、未実装の約 60 個も、単一 CPU ならスタブ化できるもの、既存機能から実装できるもの、epoll や eventfd のように作業中のものへ分けられる。 Figure 5 は 30 アプリケーションが必要とするシステムコールと Unikraft の対応状況を、Figure 7 は各アプリケーションの対応割合を示す。 ![[_attachments/2026_Unknown_Unikraft/fig05-syscall-heatmap.png]] (Figure 5. 30 個のサーバーアプリケーションが必要とするシステムコールと Unikraft の対応状況。Source: 論文 Figure 5。) ![[_attachments/2026_Unknown_Unikraft/fig07-server-app-syscall-support.png]] (Figure 7. 上位 30 サーバーアプリケーションのシステムコール対応割合。多くのアプリケーションは未対応システムコールが残っていても実行可能である。Source: 論文 Figure 7。) Table 3 は論文時点のアプリケーション、フレームワーク、言語の対応範囲を示す。 | Category | Supported software | |---|---| | Applications | NGINX, SQLite, Redis, memcached, Click modular router, lighttpd (ongoing) | | Frameworks | Intel DPDK, TensorFlow Lite, PyTorch | | Compiled Languages | C/C++, Go, Web Assembly (WAMR), Lua, Java/OpenJDK (ongoing), Rust (ongoing) | | Interpreted Languages | Python, Micropython, Ruby, JavaScript/v8 (ongoing) | (Table 3. Unikraft が対応するアプリケーション、フレームワーク、言語。Source: 論文 Table 3。) ### 手動移植 自動移植できず、性能が重要でバイナリ互換性を選べない場合は手動移植を行う。マイクロライブラリが共通コードベースを提供するため、過去のユニカーネルのようにアプリケーションごとに数か月かかる作業より短い。約 70 人の OSS コミュニティ開発者への調査では、依存ライブラリと OS・ビルドシステムのプリミティブに要する作業が、2019 年第 2 四半期から 2020 年第 1 四半期にかけて減少した。 ![[_attachments/2026_Unknown_Unikraft/fig06-porting-effort-survey.png]] (Figure 6. ライブラリ本体、依存関係、欠落 OS プリミティブ、ビルドシステムプリミティブを含む移植作業量の開発者調査。Source: 論文 Figure 6。) ## 実験設定 基本評価では KVM を主な仮想化基盤とし、Xen とベアメタルは性能評価の対象外とした。実験機は約 €800 の Shuttle SH370R6、Intel i7-9700K 3.6 GHz(ターボ時 4.9 GHz、8 コア)、RAM 32 GB である。Hyper-Threading を無効化し、4 コアをホスト用に分離し、VM、VMM、クライアントツールを別コアへ固定し、CPU ガバナを performance に設定した。DPDK 実験では同一構成の 2 台を 10 Gbit/s の直接ケーブルで接続し、Intel X520-T2(82599EB)を用いた。 評価対象は Hello World、nginx、Redis、SQLite である。比較対象には Linux、Docker、Linux microVM、MirageOS、OSv、Rump、Lupine、HermiTux などを含め、アプリケーションのバージョンと設定を可能な範囲で揃えた。 ## 実験結果 ### 資源効率 Figure 8 は DCE と LTO の組み合わせによるイメージサイズ、Figure 9 は他の OS・ユニカーネルとのイメージサイズ比較、Figure 10 は VMM 別の起動時間を示す。 ![[_attachments/2026_Unknown_Unikraft/fig08-image-sizes-configurations.png]] (Figure 8. DCE と LTO の有無による Unikraft アプリケーションのイメージサイズ。すべて 2 MB 未満である。Source: 論文 Figure 8。) ![[_attachments/2026_Unknown_Unikraft/fig09-image-sizes-os-comparison.png]] (Figure 9. Unikraft と他 OS のイメージサイズ比較。strip 済みで LTO と DCE は含めない。Source: 論文 Figure 9。) ![[_attachments/2026_Unknown_Unikraft/fig10-boot-time-vmm-comparison.png]] (Figure 10. VMM 別の Unikraft イメージ起動時間。Solo5 と Firecracker の合計起動時間は約 3 ms、QEMU microVM は約 10 ms、QEMU は約 40 ms である。Source: 論文 Figure 10。) Unikraft のイメージは対象アプリケーションで 2 MB 未満となり、Linux ユーザー空間バイナリと同程度で、他のユニカーネルより小さい。ゲストに必要なメモリは Figure 11 のように 2〜6 MB であり、VMM のオーバーヘッドを除くゲスト起動時間は QEMU と Solo5 で数十〜数百マイクロ秒、Firecracker で 1 ms 未満となった。 ![[_attachments/2026_Unknown_Unikraft/fig11-minimum-memory.png]] (Figure 11. 各 OS 上で複数アプリケーションを動かすための最小メモリ量。Unikraft のゲストは 2〜6 MB である。Source: 論文 Figure 11。) ### ファイルシステム性能 永続ストレージ向けに、Unikraft は virtio-9p をトランスポートとする 9pfs 実装を提供する。9pfs デバイスの有効化は KVM の起動時間に 0.3 ms、Xen の起動時間に 2.7 ms を追加する。4、8、16、32 KB の読み書きで測定した Figure 20 では、Linux VM より低い読み出し・書き込みレイテンシを示す。 ![[_attachments/2026_Unknown_Unikraft/fig20-9pfs-latency.png]] (Figure 20. Linux と比較した 9pfs の読み書きレイテンシ。Source: 論文 Figure 20。) ### アプリケーションスループット 手動移植した nginx と Redis を、ネイティブ Linux、Docker、Linux microVM、複数ユニカーネルと比較した。Figure 12 と Figure 13 のワークロードは Redis が 30 接続・100,000 要求・パイプラインレベル 16、nginx が wrk の 1 分間・14 スレッド・30 接続・612 バイト静的ページである。 ![[_attachments/2026_Unknown_Unikraft/fig12-redis-performance.png]] (Figure 12. QEMU/KVM と Firecracker における Redis の GET/SET 性能。Source: 論文 Figure 12。) ![[_attachments/2026_Unknown_Unikraft/fig13-nginx-performance.png]] (Figure 13. wrk による nginx と Mirage HTTP-reply の性能比較。Source: 論文 Figure 13。) Unikraft はコンテナより 30〜80%、Linux VM より 70〜170% 高速で、ネイティブ Linux よりも 10〜60% 高速だった。QEMU/KVM 上の Lupine と比べて Redis と nginx で約 50%、OSv と比べて Redis で約 35%、nginx で約 25% 高速だった。結果は KPTI、協調型スケジューラ、Mimalloc の利用、各システムの残存コード量などの影響を受ける。 ### 自動移植とアロケータ選択 SQLite を独自のビルドシステムで静的ライブラリ化し、musl を通じて Unikraft へリンクする自動移植では、60,000 件の INSERT に要する時間が手動移植版より 1.5% 遅いだけであった。Figure 17 は Linux native、newlib native、musl native、musl external を比較する。 ![[_attachments/2026_Unknown_Unikraft/fig17-sqlite-porting-performance.png]] (Figure 17. 60,000 件の SQLite INSERT に要する時間。musl external は自動移植版である。Source: 論文 Figure 17。) nginx に buddy、Mimalloc、bootalloc、tinyalloc、TLSF を組み合わせると、ゲスト起動時間は bootalloc の 0.49 ms から buddy の 3.07 ms まで変化した。実行時スループットは buddy、TLSF、Mimalloc が近く、tinyalloc が低かった。 ![[_attachments/2026_Unknown_Unikraft/fig14-nginx-boot-allocators.png]] (Figure 14. アロケータ別 nginx の Unikraft ゲスト起動時間。Source: 論文 Figure 14。) ![[_attachments/2026_Unknown_Unikraft/fig15-nginx-throughput-allocators.png]] (Figure 15. アロケータ別 nginx スループット。Source: 論文 Figure 15。) SQLite の実行速度はクエリ数により最適アロケータが変わり、tinyalloc は 1,000 件未満で 3〜30% 高速だが、要求数が増えるとメモリ圧縮の影響で不利になる。Mimalloc は高負荷時に 20% の性能向上を与える。Redis でもアロケータ選択による性能差は最大 2.5 倍に及ぶ。 ![[_attachments/2026_Unknown_Unikraft/fig16-sqlite-speedup-allocators.png]] (Figure 16. Mimalloc を基準とした SQLite のアロケータ別相対実行速度。Source: 論文 Figure 16。) ![[_attachments/2026_Unknown_Unikraft/fig18-redis-throughput-allocators.png]] (Figure 18. アロケータ別 Redis スループット。GET と SET、30 接続、100,000 要求、パイプラインレベル 16 の結果。Source: 論文 Figure 18。) ### ネットワークとファイルシステムの特殊化 uknetdev をポーリングモードで使い、lwIP とスケジューラを削除した UDP キーバリューストアは、DPDK と同程度の性能を 1 コアで達成した。Figure 19 では vhost-user を使う uknetdev が Linux VM 上の DPDK と同様の送信スループットを示す。Unikraft の特殊化版は 1.4 MB のイメージで 80 ms で起動し、DPDK 版の約 1 GB、数秒起動、2 コア使用より資源効率がよい。 ![[_attachments/2026_Unknown_Unikraft/fig19-uknetdev-dpdk-throughput.png]] (Figure 19. vhost-user と vhost-net における Unikraft と Linux VM 上の DPDK の送信スループット比較。Source: 論文 Figure 19。) ブートコードの特殊化では、静的に初期化済みの 1 GB ページテーブルを使うと 30 マイクロ秒でブートできる。動的ページテーブルでは、必要メモリに比例して起動時間が増え、32 MB で 46 マイクロ秒、3 GB で 114 マイクロ秒となった。 ![[_attachments/2026_Unknown_Unikraft/fig21-page-table-boot-time.png]] (Figure 21. 静的・動的なページテーブル初期化による Unikraft の起動時間。Source: 論文 Figure 21。) VFS 層を除去し、SHFS という専用ハッシュベースファイルシステムへアプリケーションを直接接続すると、標準 VFS 経路より 5〜7 倍の削減が得られ、Linux よりも高い性能となった。 ![[_attachments/2026_Unknown_Unikraft/fig22-filesystem-specialization.png]] (Figure 22. 専用ファイルシステムと VFS 層の削除による性能。Source: 論文 Figure 22。) Table 4 は UDP ベースのインメモリキーバリューストアの結果である。 | Setup | Mode | Throughput | |---|---|---:| | Linux baremetal | Single | 769 K/s | | Linux baremetal | Batch | 1.1 M/s | | Linux guest | Single | 418 K/s | | Linux guest | Batch | 627 K/s | | Unikraft guest | DPDK | 6.4 M/s | | Unikraft guest | LWIP | 319 K/s | | Unikraft guest | uknetdev | 6.3 M/s | | Unikraft guest | DPDK | 6.3 M/s | (Table 4. Unikraft と Linux における特殊化 UDP ベース・インメモリキーバリューストアの性能。Source: 論文 Table 4。) ## 考察 Unikraft は、変更なしのアプリケーションにも syscall overhead、イメージサイズ、メモリ消費の削減を与え、API に合わせた小さな変更を加えたアプリケーションには低レベル経路への接続による追加性能を与える。性能向上の源泉はユニカーネルという単一アドレス空間だけではなく、アプリケーションが API の抽象化レベルを選べることにある。 一方、性能と移植容易性には交換関係がある。musl と syscall shim を使う自動移植は移植量を抑えられるが、uknetdev、DPDK、専用ファイルシステムのような経路へ移るにはアプリケーションの構造変更が必要である。バイナリ互換性は移植を容易にするが、実行時変換のコストで関数呼び出しの利点を損なう。 セキュリティについて、ユニカーネルの小さな Trusted Computing Base は利点になりうるが、過去のユニカーネルが標準 OS のスタック保護、ページ保護、ASLR などを欠いていた点は実装上の課題である。Unikraft は CFI、Address Sanitisation、Intel MPK によるハードウェア区画化などを今後の拡張候補として挙げる。 ## 強み / 弱点・課題 - **強み**: OS プリミティブと API の完全なモジュール化、POSIX 互換と低レベル API の併存、既存ビルドシステムを利用した自動移植、複数プラットフォーム対応、アプリケーションごとのアロケータ・スケジューラ・ネットワーク・ファイルシステムの選択。 - **弱点・課題**: マルチプロセスと `fork()`・`exec()` をサポートしない。現行のマルチコア対応は作業中であり、汎用 OS が提供する標準セキュリティ機構も不足する。低レベル API の採用にはアプリケーションの手動変更が必要で、評価の大部分は KVM と特定のハードウェア構成に依存する。 - **今後の方向**: syscall 互換性を拡大し、メモリーセーフまたは静的検証可能な言語でマイクロライブラリを実装し、リンク後の区画化によって安全性を維持する。 ## 出典 - [[.raw/papers/2026_Unknown_Unikraft.pdf]] - [[.raw/papers/2026_Unknown_Unikraft.txt]] - [[Unikraft]] - Kuenzer et al., “Unikraft: Fast, Specialized Unikernels the Easy Way,” EuroSys '21, DOI: https://doi.org/10.1145/3447786.3456248