- Rustで書かれたLinux ABI互換カーネルで、「フレームカーネル(framekernel)」アーキテクチャを採用し、モノリシックカーネルとマイクロカーネルの長所を組み合わせることを目指している
- すべてのunsafeコードを限定されたライブラリ内部にカプセル化し、残りのカーネルサービスは安全なRust抽象化で開発できるよう設計することで、メモリ安全性と単純な共有メモリ構造を同時に実現
- RedLeaf、Tock、Rust for Linuxなど既存のRust OSとの違いは、ハードウェア分離のサポート、汎用目的、Linux互換ABI、ユーザー空間での多様な言語実行
- TCB（信頼できる計算基盤）の最小化と形式検証（Verus活用）の推進、Intel TDXなどの信頼実行環境ハードウェアのサポート、OSTD/OSDKなどのOS開発フレームワークも別途提供
- まだ初期開発段階で、x86/RISC-V対応と206個のシステムコール実装、Docker/コンテナ/クラウド環境に注力しているが、X11/Xfceなどデスクトップ拡張も試みている
What's Asterinas?
- AsterinasはRustで開発されたLinux ABI互換の新しいカーネルプロジェクト
- 「フレームカーネル(framekernel)」アーキテクチャとは、unsafe Rustコード（メモリ安全でない区間）をフレームワークライブラリに限定して安全なAPIで包み、残りのカーネルサービスはすべて安全なRustで開発できるよう設計するもの
- モノリシックカーネルの単純さ・高性能な構造と、マイクロカーネルのTCB（信頼できる計算基盤）最小化・安全性を同時に追求している
- カーネル内部でサービス群が同一アドレス空間内で分離されて動作し、各サービスはcoreライブラリから付与された資源だけを利用できる
フレームカーネル(framekernel)アーキテクチャの説明
既存のRust OSおよびフレームカーネルとの比較
- RedLeaf: Rustベースのマイクロカーネルで、ハードウェア分離は使用しない
- Asterinas: 汎用OS、ハードウェア分離を活用、Linux ABI互換、多様な言語のユーザー空間実行をサポート
- Tock: 組み込みSoC向け、コア（unsafe許可）とカプセル（安全コード）を分離する構造、ハードウェア分離は未サポート
- Rust for Linuxプロジェクトも、カーネルインターフェースを安全抽象化で包み、kernel driverをRustで安全に書けるようにすることを目的としている
形式検証とセキュリティ
- TCBを減らす主な目的は、形式検証(formal verification) を現実的に可能にするため
- AsterinasはseL4のような小さく検証可能なTCBとLinux ABI互換、共有メモリ構造を同時に目標とする唯一の事例
- セキュリティ監査の専門企業CertiKと協業し、Verusベースの形式検証作業を進めている
- CertiKのセキュリティ評価レポートで、プロジェクトの監査ポイントと発見された問題を公開している
ライブラリと開発ツール
- カーネル本体のほかにOSTD（Rust OSフレームワーク）とOSDK（Cargoベースの開発ツール）を提供
- OSTDの主な目標:
- OS開発への参入障壁を下げ、イノベーションの基盤を整える
- Rustオペレーティングシステムのメモリ安全性強化と低レベルAPIの抽象化
- Rust OSプロジェクト間でのコード再利用を促進
- ユーザーモードで新規コードをテスト可能にする（開発生産性向上）
- OSDおよびOSTDベースのカーネルはLinux互換である必要はなく、x86ハードウェア制御、仮想メモリ、マルチプロセッシング（SMP）、タイマーなどの高レベルなメモリ安全APIを提供
- Intelがスポンサーとして参加しており、とくにTrust Domain Extensions(TDX) と仮想マシン分離関連技術との親和性が高い
開発状況と主要スポンサー
- 2024年初頭にオープンソース（MPLライセンス）として初公開され、現在45人が貢献、主な貢献者は中国のSUSTech、北京大学、復旦大学の博士課程学生とAnt Group
- x86、RISC-V対応、Linuxシステムコール206個を実装（全368個中）
- まだアプリ実行は不可で、初期ディストリビューション開発・コンテナ（Docker）サポートを目標にしつつ、Nixベースの配布も試みている
- Linuxカーネルモジュールのロードはサポートせず、恒久的に導入する計画もない
今後の計画
- より多様なCPUアーキテクチャとハードウェア対応の拡大、およびクラウド環境での実運用性を短期の優先課題としている
- Linux virtioデバイス対応を完了し、中国クラウド市場（Alibaba Cloud、Aliyun） を主要ターゲットとしている
- 安全で縮小されたTCBとIntelの信頼計算機能サポートを備えた、コンテナ向けhost OSの開発が中心目標
- Rust for Linuxと目的は似ていても、Rust for Linuxが既存カーネル内のDriverのRust化に限定される一方、Asterinasはカーネル全体の新規設計とTCB最小化を追求する
- 現在はX11、Xfceサポートなど多様な方向の実験も進めており、OSTD自体も一般のOS開発者から注目される可能性がある
Rust for Linuxとの違い
- Rust for Linux: 既存LinuxカーネルにRustで安全なドライバのみを導入、カーネル全体はCベース
- Asterinas: 新しいカーネルを最初からRustで実装し、unsafeを厳格に限定、形式検証を推進、クラウド/コンテナ環境に集中
総括と展望
- Asterinasはメモリ安全性、形式検証、クラウド環境での実用性などで革新的なアプローチを試みている
- まだ実運用例や広いコミュニティでの検証はないが、OS研究・クラウド・セキュリティ分野で関心を集めている
- OSTDフレームワークなどは、今後のRust OS開発エコシステムで活用される可能性がある
Asterinas関連LWNコメントの主要論点まとめ
- Singularity OSと言語ベースのセキュリティ境界をめぐる論争
- AsterinasのframekernelはMicrosoftのSingularity OSに似ているが、Rustのborrow checkerを活用してメモリ安全性を高めている
- 言語自体（例: Rust、Java、WASM/JS）のセキュリティ境界でシステムを守るアプローチについて、「完全な信頼は不可能で、実際にはハードウェア/OSレベルのサンドボックスと併用される」という批判と、「欠陥防止や形式検証には利点がある」という意見が対立している
- WASM、JS、Javaなどもセキュリティ性をめぐる議論があるが、実サービスでは言語サンドボックスだけでは信頼されず、実際にはハードウェアやOSサンドボックスを必ず併用する事例が一般的
- オペレーティングシステム開発トレンドと地政学的背景
- ここ数年で多様な新規OSプロジェクトが登場し、OSイノベーションの雰囲気が広がっている
- 中国は米国の技術制裁やサプライチェーンリスクに対応するため、Linux代替OS開発を加速している
- 米国の制裁やGPLなどオープンソースのグローバルガバナンス論争、そして中国・欧州など各国が独立した技術エコシステムを追求すべきだという政治的議論が激しく続いている
- Linuxのフォーク維持と完全新規カーネル開発の難しさ、コミュニティの知識やノウハウへの依存、言語障壁なども論争のテーマ
- Linux互換性/システムコール数をめぐる論争
- 「Linuxシステムコール数で互換性を測るのは不適切」という意見が多数
- 単一のシステムコール（
ioctlなど）が多数の詳細APIを内包するため、実質的な互換性にはカーネルテストスイートなど実アプリの動作確認が重要
- 初期にPOSIX互換性確保のためsystem callを1つずつ実装していたLinuxの発展史を例に、主要なsyscallの99%だけでもかなり多くのソフトウェアが動く可能性があるという現実的な意見もある
- ライセンスとRustエコシステム
- AsterinasがMPLを選んだことに関する議論: Rustのcrateエコシステムとモジュール型ライセンスにMPLがよく合うという肯定的な意見
- GPLが常に最適とは限らず、企業支援を受けるなら企業フレンドリーなライセンス（MPLなど）を採用し得るという見方
- プロジェクト依存関係/セキュリティ
- RustベースOSで多数の外部crateを使うのは安全かという疑問と、
cargo deny/vetなどによるサプライチェーンセキュリティ・監査自動化の必要性が提起されている
- 実際にはlockfileだけでは依存関係の表面積を把握しにくく、Rustエコシステム特有の推移的依存関係やOS別依存関係などの複雑さも言及されている
- 技術的インスピレーション/類似アーキテクチャ
- framekernelの概念が90年代のUniversity of WashingtonのSPIN OSアーキテクチャに似ていると指摘
- SPINも強いモジュール性と、コンパイラによるインターフェース/アクセス制御を重視していた
- コミッター構成をめぐる論争
- 45人の貢献者のうち、多数のコミットが少数の博士課程学生中心であることへの言及
- 博士課程学生主導の貢献は実質的コミッターとして価値が低いという誤解を指摘し、研究主導の革新プロジェクトとしても意味があるという意見
- 政治/歴史論争とオフトピック指摘
- OS議論が米国、欧州、中国の地政学/政治/歴史論争に広がり、編集者によって「オフトピック」との警告が何度も出された
- オープンソース・FOSSエコシステムも地政学的環境の変化から影響を受け得ると一部利用者が強調している
- その他
- WASMセキュリティに関する学術論文の共有
- カーネル開発状況に対する肯定的・批判的見方が混在している
2件のコメント
こういう試みは本当に良さそうです。
近いうちに死なないカーネルが出てくるのかも、という気もします。
Hacker News の意見
興味深いアプローチだと思うし、成功してほしい立場ではある。ただ、それでもなお疑問は残る。90年代後半か2000年代初頭に、Linus が TV インタビューで競合について触れていた内容を今でも覚えている。Linus は「ドライバを書くのを楽しむ人はいない、若くてハングリーな誰かが優秀なドライバエンジニアとして現れるまでは安泰だ」といった趣旨のことを言っていた。すでに当時から、ドライバインターフェースを不安定に保つことが防御策になると認識していた。25年が経った今、仮想化ハードウェア上で動くカーネルはごく一般的になったが、それでも実機ハードウェアの抽象化に成功した、実用的で使える OS はまだほんのわずかしかない
「ドライバインターフェースを不安定に保つことが防御策」という点については、今後は若くてハングリーなシステム研究者や AI が現れて、AI エージェントが C で書かれた Linux ドライバを安全な Rust 製の Asterinas ドライバへ翻訳してくれる方向に可能性があると思う。もう1つの現実的なアプローチは、Linux カーネル自体を何らかの隔離環境に入れて再利用することだ。たとえば HongMeng カーネルは User-Mode Linux を活用してドライバを再利用している。Asterinas にも同様の戦略を適用できる。参考: https://www.usenix.org/conference/osdi24/presentation/chen-haibo
Linus が本当に「防御壁」を望んでいたり意図していたのかは疑問だ。彼は技術スタートアップの創業者ではなく、もともとただのカーネルハッカーであり、すでに一生食べていける基盤もある。カーネル内のドライバインターフェースの不安定さを、意図的な競争阻止戦略だと解釈するのは少し投影が過ぎる
過去にも SPIN OS(Modula 3)、JX OS(Java)、House OS(Haskell)、Verve といった先例がある。いずれも型安全・メモリ安全な言語でカーネル機能を実装していた。一般には危険な部分をチェック済みの関数呼び出しの裏に隠す構造で、一部は VM も活用していた。性能や採用の問題を除けば、主な脆弱性は抽象化の隙間、unsafe コードによる回避、コンパイラ/JIT による安全性モデルの崩壊、そして一般的なハードウェア障害（例: 宇宙機での宇宙線）だ。それでも unsafe な言語で書かれたカーネル/アプリよりははるかに安全だ。さらに先へ進むなら、unsafe コードの静的解析、すべての unsafe 関数が型・メモリ安全なインターフェースに従うことの保証、統合時に抽象化の安全性を保持するコンパイラ、コンポーネントごとの認証済みコンパイラも活用できる。生産性ツールの大半はすでに存在しており、足りないのは「完全に安全に抽象化されたコンパイル」くらいで、これは現在研究中だが手作業で検証することも可能だ
実用的に使える OS の数がごくわずかであることには理由がある。ハードウェアの世界にはインターフェースの「標準」があふれているが、実際のハードウェアが標準どおりにまともに動くことはほとんどない。ドライバが各種の癖や修正不可能な欠陥（エラッタ）に対応するコードを書くための時間をかけられなければ、実際の物理ハードウェア上で性能とサポートを両立するのは本当に難しい
一方で、実際に自分が扱う Linux の 98% は仮想化環境で動いている。デスクトップ/ラップトップでは Virtualbox をフルスクリーンで回し、Windows 用ドライバは本当に必要なときだけ使い、Mac では Docker.app が管理するヘッドレス VM を使っている。会社の全運用ワークロードは AWS の VM だ。自宅で使っている唯一の Linux ハードウェアもホームサーバーだが、近いうちに eBay で買った Mac mini 上の VM に置き換える予定だ。もし Linux と互換性があり、より安全で性能も同程度のカーネルが出てくるなら、ドライバが少なくても今の時代は代替を選びやすいと思う
最近のマイクロカーネルは IPC 性能の問題をかなり改善したと聞いている。実際どの程度改善されたのかははっきり覚えていないが、Mach による業界のトラウマが大きかったのだと思う。プロジェクトサイトを見ると、むしろ Framework（特権モード）だけが Rust の unsafe を使え、Services（非特権）は安全な Rust しか使わないという構造になっている。どこか違和感がある。非特権コードが unsafe なら、たとえ非特権でも危険なのではないか？ 逆に、本当に検証が必要な unsafe コードは無制限に使える側に集められているのか？ そしてライセンスを見ると、Asterinas は Mozilla Public License(MPL) 2.0 を主に使い、一部コンポーネントはより寛容なライセンスだという説明だ。GPL でも BSD でもない、中間くらいの印象だ
「非特権でも unsafe なら危険だし、本当に検証が必要なコードを特権側に集めるのが変だ」という質問については、この構造は framekernel の文脈で理解すべきだ。Rust ベースの framekernel 全体はカーネル空間で動作するが、論理的には特権 OS フレームワークと非特権 OS サービスの2つに分かれる。特権側には safe + unsafe Rust のカーネルコードが含まれ、非特権側には safe Rust のカーネルコードしか含まれない。このポリシーはすべてカーネルコードに対するものだ。framekernel ではユーザープログラムの言語に制約はない
最近のマイクロカーネルの多くは IPC 性能を劇的に改善していると思う。代表例として SeL4 は IPC を非常に積極的に最適化しており、Linux の一般的な syscall より IPC のほうがずっと速い。たいていのプログラムは SeL4 上のほうがむしろ速く動く可能性がある。実際の性能比較データが気になる
最新のマイクロカーネルが IPC の問題を改善しているのは確かだ。実のところ、より根本的な問題は、現代のハードウェアではモノリシックカーネルの syscall ですら非常に遅いという点だ。そのため io_uring や virtio のようなインターフェースが高い性能を出せるのは、システムとアプリ（またはハイパーバイザとゲスト）の間で要求と応答をキューで処理し、アドレス空間の切り替えを避けているからだ。今後の OS は、どんな構造であれ「キューイング」ベースの syscall メカニズムが必須になる。そしてこの方式を採れば、OS をモノリシック/マイクロカーネル/その他の構造に分けても、性能面で大きな差はなくなる
Framekernel における privileged/unprivileged の分離は、カーネル/ユーザースペースという意味ではない。OS 全体がカーネル特権レベルで動作する。ただし論理上は、コアライブラリコード（unsafe の使用が許可される privileged）と、それ以外のカーネル構成コード（ライブラリを利用し、unsafe を直接使えない unprivileged）に分かれる。おそらく linter などの静的チェックで強制しているのだろう。用語の重複使用のせいで混乱しやすい構造だ
非特権 task もカーネルコアと同じメモリ空間で動作するため、ランタイムで安全でない動作を防ぐ方法はない。実際にランタイムで特権を分離するにはマイクロカーネル構造が必要になる。ここでは特権はランタイムではなく静的に、つまり unsafe コードを禁止することで実装されている
カーネルを小さな unsafe コアと大きな safe モジュールに分離するという概念が、新しい試みなのか気になる。マイクロカーネルのハードウェアオーバーヘッドはなく、モノリシックの安全性問題も避けつつ、システム言語の safe/unsafe の区別をうまく活かしたプロジェクトという点でとても興味深く、期待している
Drew DeVault の Rust in Linux レビュー を思い出した。HN の議論も関連している https://news.ycombinator.com/item?id=41404733
本当にすごい試みだと思うし、作者がこのスレッドにいるという点にも感動した。どのレベルまで usable なのか気になる。たとえ一部の限定環境だけでも、サーバーイメージをビルドして試してみたい
マイクロカーネルの IPC が遅いから人気がない、という説明を見て、技術的に優秀な人でも実際の採用理由やその過程で誤解することがあるのだと分かって安心した
ライセンスが MPL なのは、個人的にはもっと良いライセンス（GPLv3 など）もあると思う
本当に良いアイデアだと思う。すでに多くのソフトウェアが構築されていて、代替となる基盤があれば、技術以外の理由からも大きな利点や選択肢が生まれうる。kFreeBSD や GNU/Hurd を思い出す
こういうカーネルは何と呼べばいいのか悩む。*nux?