ハクソク

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

Asterinas: 新しいLinux互換カーネルプロジェクト

340日前原文(lwn.net)

概要

AsterinasはRustで開発されたLinux互換カーネルプロジェクトで、「フレームカーネルアーキテクチャ」を採用。 安全性と性能を両立する新しいカーネル設計思想を提案。 unsafeコードを最小限に封じ込め、他は安全な抽象化で開発可能。 クラウドやコンテナ用途を主なターゲットとし、形式的検証も目指す。 プロジェクトは初期段階で、今後の発展とコミュニティの反応が注目点。

Asterinasとフレームカーネルとは

  • Asterinas ：Rust製のLinux-ABI互換カーネルプロジェクト
  • フレームカーネルアーキテクチャ ：unsafeを使う部分をライブラリに封じ込め、他は安全なRustで開発
  • 従来のカーネル設計 ：モノリシックカーネルは全てを単一空間で処理、マイクロカーネルは最小限のTCBとユーザ空間サービスで分離
  • フレームカーネルの特徴 ：
    • unsafeコードのカプセル化
    • サービスはカーネル空間内だが、リソースアクセスは制限
    • シンプルかつ高性能な共有メモリ方式維持
    • 安全性と性能の両立
  • 命名の由来 ：unsafe部分をフレームワークで包み、メモリ安全APIで公開する設計思想

関連プロジェクト・先行研究との比較

  • RedLeaf ：Rust製マイクロカーネル、ハードウェア分離は使わず異なる設計思想
  • Tock ：組込み向け、信頼できるコアとunsafe禁止のカプセルで分離
  • Rust for Linux ：LinuxカーネルにRustを導入し、安全なドライバ開発を目指す
  • Asterinasの独自性 ：
    • ハードウェア分離を活用し、汎用性とLinux互換性を重視
    • TCBの最小化と形式的検証を志向

形式的検証への取り組み

  • TCBの小型化 ：形式的検証を現実的にするための重要要素
  • seL4 ：有名な形式的検証済みマイクロカーネル
  • Asterinasの目標 ：
    • 小型で検証可能なTCBとLinux互換の共有メモリアーキテクチャを両立
    • CertiK社と連携し、Verusを用いた形式的検証を推進
    • 監査レポートも公開

ライブラリ・開発ツール

  • OSTD ：Rust製OS開発フレームワーク
    • OS開発の参入障壁低減
    • メモリ安全性の向上
    • コード再利用促進
    • ユーザーモードでのテストによる生産性向上
    • Linux互換やUNIXライクである必要はなし
  • OSDK ：OSTDベースのカーネル開発支援Cargoアドオン
  • Intelのサポート ：TDX（Trust Domain Extensions）などの信頼性強化機能に関心
  • 実装例 ：ネットワークカーネルコンポーネントはDMAやロック等をOSTD経由で安全に利用

現状と今後の展望

  • 開発状況 ：
    • 2024年初頭にMozilla Public Licenseで初公開
    • 主に中国の大学院生とAnt Groupが開発
    • x86とRISC-Vをサポート
    • Linuxシステムコール206種（x86）に対応（Linux 6.7は368種）
    • リリースやドキュメントは限定的
    • OSTDは他プロジェクトでの利用実績なし
    • アプリケーション実行は未対応
  • 初期ディストリビューション計画 ：
    • 独自initramfsと簡易ユーザ空間アプリを用意
    • Docker対応を目指す
    • Nixベースのディストリ構想
    • Linuxカーネルモジュール非対応
  • 短期目標 ：
    • 対応CPUアーキテクチャとハードウェアの拡充
    • クラウド用途（特に中国Aliyun/Alibaba Cloud）での実用性強化
    • コンテナホストOSとしての展開
    • Intelの信頼性機能（TDX等）への対応
    • X11やXfce対応の動きもあり
  • Rust for Linuxとの違い ：
    • Rust for Linux：既存カーネルのドライバ領域のみRust化
    • Asterinas：カーネル全体をRustで再設計、安全・検証可能なコアに集約
    • Asterinasはクラウド・コンテナ用途が主眼、Rust for LinuxはLinux全体の進化を志向

まとめ・今後の注目点

  • 新しいOS設計思想の実験場 ：Rustの安全性と健全性を最大限活用
  • 中国主導の意欲的研究開発 ：実用化はこれから
  • コミュニティの反応や普及の行方に注目 ：Rust for LinuxチームやLinux界隈の評価も今後の焦点

Hackerたちの意見

このIPCはパフォーマンスに影響を与えることが多くて、マイクロカーネルがあまり人気がない大きな理由の一つだね。技術的な人たちが、なぜアプローチやプロジェクトが採用されないのかを誤解しているのを見ると、ちょっと安心する。

└

みんなのためにも、実際にどのようにやっているのか教えてくれたら助かるよ。

このIPCはパフォーマンスに影響を与えることが多くて、マイクロカーネルがあまり人気がない大きな理由の一つだと思う。新しいマイクロカーネルは…それを改善したのかな？忘れちゃったけど、実際にはそんなに悪くない印象があった。ただ、業界がMachにトラウマを抱えているのは確かだね。プロジェクトのウェブサイトから: > 特権のあるフレームワークだけがRustの安全でない機能を使用でき、特権のないサービスは安全なRustでのみ書かれなければならない。これ、逆な気がする。特権のないタスクが安全でないなら、やっぱり特権がないままだよね。その一方で、追加の検証が必要な安全でないコードは…何も守れない部分でしか許可されてないの？

└

特権のないタスクが安全でないなら、やっぱり特権がないままだよね。その一方で、追加の検証が必要な安全でないコードは…申し訳ないけど、ドキュメントがちょっと誤解を招く感じだね。あれは…フレームカーネルの文脈で解釈する必要がある。Rustベースのフレームカーネル全体はカーネル空間で動作するけど、論理的には二つの部分に分かれているんだ。特権のあるOSフレームワークと、特権のないOSサービスね。ここで「特権」とは、安全でないRustカーネルコードを含む安全なコードを指していて、「特権なし」はすべて安全なRustカーネルコードを指す。これはすべてカーネルコードの話で、フレームカーネルはユーザースペースプログラムの言語に制限をかけないよ。

└

これ、逆な気がする。特権のないタスクが安全でないなら、やっぱり特権がないままだよね。その一方で、追加の検証が必要な安全でないコードは…何も守れない部分でしか許可されてないの？特権のないタスクはコアカーネルと同じメモリ空間で動いているから、許可されていないことをしないようにするためのランタイムチェックがないんだ。ランタイムでそれを強制する唯一の方法は、マイクロカーネルアーキテクチャを採用することだよ。ここで提案されている代替アーキテクチャは、コードが安全でない機能を使わないように静的に特権を強制することなんだ。

└

私の理解では、彼らはカーネル空間/ユーザ空間の意味で特権/特権なしを言っているわけじゃないんだ。すべてがカーネルの特権レベルで動いている。ただ、彼らは論理的にRustの安全でない機能を使うことが許可された（小さい）コアライブラリのようなコードのセットを定義していて、それ以外のカーネルの実装コード（ドライバも含む？）はそのライブラリを使って、直接Rustの安全でない機能を使うことが禁止されている（おそらくリンタールールによって）。これは、あなたが一般的な使い方に基づいて合理的に解釈した用語の過剰な重複なんだ。

└

新しいマイクロカーネルは…それを改善したのかな？忘れちゃったけど、実際にはそんなに悪くない印象があった。SeL4はこんな感じのマイクロカーネルだね。彼らはIPCをLinuxよりもずっと積極的に最適化したらしい。sel4 ipcを使ってメッセージを送るのは、Linuxのsyscallよりも1桁か2桁速いらしいよ。ほとんどのプログラムがLinuxよりもsel4の方がパフォーマンスが良いって言われても驚かないけど、実際にどうなのか知りたいな。

└

問題なのは、多くのマイクロカーネル嫌いが、30年前に真実だったことを繰り返している一方で、基本的なタスクのためにたくさんのコンテナを動かしていることだね。

└

安全でないRustで書かれた部分が、他の部分が安全なRustを使えるようにするためのメモリとアクセス管理を実装しているんだ。

└

新しいマイクロカーネルが…それを減らしたと思ってた？直したの？実際、問題の本質は現代のハードウェアで、これがモノリシックカーネルへのシステムコールを高くしてるんだよ。だからio_uringやvirtioがうまく機能するんだ。OSとアプリケーション（またはvirtioのためのハイパーバイザーとゲスト）の間でリクエストと返信をキューイングして、アドレス空間間の遷移を避けてる。将来のどんなOSも、うまく機能するためには何らかのキューイングシステムコールメカニズムが必要になるだろうし、一度それを手に入れれば、OSのコンポーネントをモノリスやマイクロカーネル、あるいは他の何かとして構成することはあまり重要じゃなくなるよ。

これは素晴らしい取り組みだね、ありがとう！スレッドに著者の一人がいるって知って嬉しい。これ、実用性からどれくらい遠いのかな？少なくとも何らかの簡略化されたコンテキストで。これを基にしたサーバーイメージを作って遊んでみたいな。

└

Asterinasは比較的新しいカーネルだから、一般的な用途にはまだまだ粗いところが多い。でも、ターゲットを絞った実世界のサービスを効率的かつ信頼性高く動かすことが目的なら、そのギャップはそんなに大きくないと思う。1年以内にそのマイルストーンに到達できると信じてるよ。Linuxの名前空間やcgroupsのような重要な機能を積極的に実装中だし、Asterinasベースの最初のディストリビューションにも取り組んでる。最初の焦点は、Confidential VMの中でAsterinasをゲストOSとして使うこと。このユースケースはセキュリティを優先していて、Asterinasはメモリ安全性の保証と小さなTCBのおかげでLinuxよりも明らかに優位性があるんだ。

これを思い出すなぁ。https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-... （HNのディスカッション: https://news.ycombinator.com/item?id=41404733）

カーネルを小さな安全でないコアと大きな安全なモジュールに分けるのは新しい開発なのかな？すごく興味深くて期待できるね。マイクロカーネルのハードウェアオーバーヘッドもなく、モノリスの安全性の問題もない。こういうプロジェクトは、明確な安全/不安全の分離ができるシステム言語に依存するのは明らかだね。

└

非常に近いアイデアが『The Birth & Death of JavaScript』で冗談交じりに提案されてたよ[1]。18:07（もっとコンテキストが知りたいなら14:14に戻ってね）[1]: https://www.destroyallsoftware.com/talks/the-birth-and-death...

いいアイデアだと思う。投資したソフトウェアがたくさんあるから、代替の基盤があれば大きなメリットが得られるか、少なくとも技術的な理由で必要なときに代替案が出せるかもしれない。kFreeBSDやGNU/Hurdを思い出すなぁ。

面白いアプローチだね、成功してほしいな。でも、まだ懐疑的だよ。90年代後半か2000年代初頭に、リーナスがテレビでインタビューを受けて、その時の言葉が今でも心に残ってる。競争相手について聞かれたとき、彼は大体こんなことを言ってた。「デバイスドライバーを書くのが好きな人はいないし、若くてハングリーな人がデバイスドライバーを書くのが得意じゃない限り、私は安全だ。」その時点で、彼はドライバーインターフェースを不安定に保つことが自分の防御策だと十分に理解していたと思う。四半世紀後、仮想化されたハードウェアで動くカーネルはたくさんあるけど、実際に使えるオペレーティングシステムは、リアルなハードウェアを抽象化するという伝統的な意味で、まだ片手で数えられるくらいだね。

└

実際に使えるオペレーティングシステムは、リアルなハードウェアを抽象化するという伝統的な意味で、まだ片手で数えられるくらいだね。これは示唆に富んでると思う。ハードウェアの世界には「標準」がたくさんあるけど、その中には（主にUSBのように）「守られている」ものもある。でも、ハードウェアの現実は、決して名目通りには動かないことなんだ。だから、パッチで修正できない癖やエラッタを処理するコードを書くために時間をかける人がいないと、物理的なハードウェアでパフォーマンスやサポートを持って動かすのは非常に難しいよ。

└

ドライバーインターフェースを不安定に保つことが彼の強みかもね。もしかしたら、LinuxドライバーをCからAsterinasの（安全な）Rustに翻訳するAIエージェントを開発したい若くて意欲的なAIシステム研究者が出てくるかもしれない。もう一つの実現可能なアプローチは、何らかの隔離された環境内でLinuxカーネルを実行してLinuxドライバーを再利用することだね。例えば、HongMengカーネルはUser-Mode Linuxを利用してHongMeng上でLinuxドライバーを再利用しているよ。[1] https://www.usenix.org/conference/osdi24/presentation/chen-h...

└

うーん… コンテナとAIを組み合わせたら、「LLMに試行錯誤させてうまくいくまでやらせる」みたいなドライバー開発のアプローチができるかな？

└

逆に、実際のハードウェアで動かすことは、ハードウェアが本物じゃなければあんまり重要じゃないよね！私が触るLinuxの98%は仮想化されてる。デスクトップやノートパソコンでは、Windowsのドライバーを使うためにVirtualboxをフルスクリーンで使ってるか、MacのDocker.appで管理されてるヘッドレスVMだよ。雇い主の生産ワークロードはすべてAWSの仮想マシンだし。私の唯一のLinuxのベアメタルハードウェアはホームサーバーなんだけど、これも近いうちに引退させる予定で、電気代とファンの音を減らすためにeBayのMac miniにVMに置き換えるつもり。もし誰かがもっと安全で同じくらいパフォーマンスの良いLinux互換カーネルを作れるなら、ドライバーが不足してても新しいユーザーベースが採用するのを想像するのはずっと簡単だよね。

└

先行技術にはSPIN OS（Modula 3）、JX OS（Java）、House OSのH-Layer（Haskell）、Verveが含まれる。それぞれが機能を実装するための型安全でメモリ安全な言語を持ってた。通常は、チェックされた関数呼び出しの背後に危険な部分を隔離してる。一部はVMも使ってるしね。パフォーマンスや採用を無視すると、主な弱点は：抽象化、ギャップ攻撃；危険なコードが全体をバイパスすること；コンパイラやJITによる安全モデルの破壊；宇宙線のような一般的なハードウェア障害。これは、危険な言語で書かれたカーネルやユーザーアプリよりもずっと安全だよ。さらに、危険なコードの静的解析を使って、すべての危険な関数が型安全/メモリ安全なインターフェースを尊重するようにしたり、統合中に抽象化の安全性を保つコンパイラや、個々のコンポーネントのための認証済みコンパイラを使うことで改善できる。安全な抽象コンパイルは（a）研究中で、（b）今のところ手動でチェックできるもの以外はすべて生産ツールがあるよ。

└

ドライバーインターフェースを不安定に保つことが彼の強みなんだよね。基本的には、カーネルレベルでのnpm updateみたいなもんだ。

└

彼はその時点で、ドライバーインターフェースを不安定に保つことが自分の強みだってことをすでに分かってたと思う。リーナスは強みを持ってる/持ちたいのかな？彼はテックスタートアップの創業者じゃないし、成功を収めたカーネルハッカーだよ。彼のニーズは、今後何が起ころうともずっと満たされるだろうし。このカーネルの側面を、特定の競争を防ぐための意図的な戦略みたいに語るのは、ちょっと投影してる感じがする。

こういうの、何て呼ぶべきかな？*nux？

MPLのライセンスだよ。まあ、GPLv3みたいな最高のライセンスもあるけどね。

└

彼らは、なぜMPLを選んだのかの理由をドキュメントに書いてるよ。選択はあんまり好きじゃないけど、その理由は理解できる。