ハクソク

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

カーネル：マルチカーネルアーキテクチャのサポートを導入

248日前原文(lwn.net)

概要

複数の独立したカーネルインスタンス を1台の物理マシン上で共存・通信させる multikernelアーキテクチャ のRFCパッチシリーズの紹介。 kexecインフラを拡張 し、CPUコア割当やカーネル間通信を実現。 セキュリティ強化、リソース効率化、障害分離 などの利点を提供。 /procインターフェイス による状態監視や、 既存kexecとの互換性維持 も特徴。 現時点では 設計へのフィードバック募集 が主目的で、広範なテストや運用は非推奨。

multikernelアーキテクチャの導入

  • 複数のカーネルインスタンス を1台の物理マシン上で同時稼働
  • 各カーネル が専用CPUコアを担当し、 ハードウェア資源 を共有
  • kexecインフラ を活用したカーネルイメージのロード・管理
  • IPI（Inter-Processor Interrupt）フレームワーク によるカーネル間通信
  • アーキテクチャ固有のCPUブートストラップ機構 （現時点ではx86のみ）
  • /proc/multikernelインターフェイス でインスタンス監視・デバッグ

multikernelアーキテクチャの主な利点

  • ワークロード間の障害分離 による堅牢性向上
  • カーネルレベルでのセキュリティ分離 による安全性強化
  • 従来の仮想化（KVM, Xen等）より高効率なリソース活用
  • KHO（Kernel Hand Over）によるゼロダウンタイムカーネル更新の可能性

実装の概要

  • kexecサブシステム拡張 による複数カーネルイメージの同時ロード
  • x86 SMP INITトランポリン で異なるカーネルへのCPU割当を実現
  • MULTIKERNEL_VECTOR によるx86カーネル間通信経路の新設
  • 汎用multikernel IPI通信フレームワーク でクロスカーネルメッセージング
  • arch_cpu_physical_id() による物理CPU識別子取得
  • kimage管理の動的リスト化 による柔軟なカーネルイメージ追跡
  • /proc/multikernel でロード済みカーネルの状態監視・デバッグ

パッチ内容のまとめ

  • Patch 1/7: kexecによる基本的なmultikernelサポート追加
  • Patch 2/7: x86用SMP INITトランポリンでマルチカーネルCPU起動
  • Patch 3/7: x86向けMULTIKERNEL_VECTORによるカーネル間通信
  • Patch 4/7: 汎用multikernel IPI通信フレームワークの実装
  • Patch 5/7: arch_cpu_physical_id()関数追加でCPU管理強化
  • Patch 6/7: kimage管理の静的グローバルから動的リスト化への変更
  • Patch 7/7: /proc/multikernelインターフェイス追加

重要な注意事項

  • 本パッチはRFC（意見募集）目的 であり、詳細な実装改善が必要
  • 基盤フレームワークのみ提供、今後の拡張や応用はコミュニティに期待
  • 著者の開発環境のみで限定的テスト、広範なハードウェアでの検証が必要
  • 運用用途での利用は非推奨、テスト目的に限定

想定される新たなユースケース

  • リアルタイムカーネルと汎用カーネルの同時稼働
  • セキュリティクリティカルなアプリケーションの分離実行
  • 特定ワークロード専用のカーネルインスタンス提供

Signed-off-by: Cong Wang cwang@multikernel.io

Hackerたちの意見

かなりクールだね、Barrelfish OSができることに似てる気がする。 (https://barrelfish.org/)

└

ティム・ロスコーがOSDI '21で「オペレーティングシステムがハードウェアを再発見する時が来た」という面白い基調講演をしたよ。彼はBarrelfishプロジェクトにも関わってたんだ。 - https://www.youtube.com/watch?v=36myc8wQhLo

CoLinuxみたいだね。Windowsと一緒に「協調Linux」を動かせたやつ。 (http://www.colinux.org/)

└

これ、過小評価されてたね！

└

HPのプリンターも似たような感じだね。二つのコアでLinuxを動かして、もう一つのコアではRTOSを使ってる。

└

確か、colinuxはユーザーモードLinuxに似ていて、ユーザーランドでカーネルをブートするんだ。つまり、カーネルはWindowsのアプリケーションとして動くってことだね。

面白いことに、著者はこの技術に関するスタートアップを持ってるみたい。彼らのウェブページには情報があるよ。 (https://multikernel.io/)

└

著者のCong Wangは、いろんな面白いものを作ってるね。最近、kernelscriptを作ったみたいで、https://github.com/multikernel/kernelscript -- これはCの代替よりもずっと強力なBPF用のDSLで、C BPFの複雑さがないんだ。前はBytedanceにいたから、「プロダクション」の複雑さを理解してることに期待が持てる。

└

なるほど。Xenよりもいいけど、すべてのkvmインスタンスよりもずっと多くのメモリが必要なんだね。聞いたところによると、メモリが大規模ホスティングの本当のポイントで、スピードじゃないらしいから、ちょっと懐疑的だな。共有ハードウェアの同時書き込みや状態をどう扱うのかも理解できないし、kvmやXenと比べるとオーバーヘッドが多い気がする。

exokernelアーキテクチャを思い出すな。[0.5][1.5][2.5] 非CPUリソースの多重化はどう扱われるのか、またはどう扱う予定なのか？ [0.5]: https://en.wikipedia.org/wiki/Exokernel [1.5]: https://wiki.osdev.org/Exokernel [2.5]: 「配列のインデックスは0から始めるべきか1から始めるべきか？私の0.5という妥協案は、適切な考慮なしに却下された。」— スタン・ケリー＝ブートル

└

バレルフィッシュとかNRカーネルに近いね。

DEC AlphaシステムのOpenVMS Galaxyを思い出す。仮想化なしで同じハードウェア上でOSの複数インスタンスを並行して動かせたんだ。 (https://www.digiater.nl/openvms/doc/alpha-v8.3/83final/aa_re...)

└

IBMのメインフレームやPowerサーバーには「パーティション」（LPAR）があるよね。私の理解では、これは実際にはソフトウェアベースの仮想化だけど、ハイパーバイザーはOSじゃなくてシステムファームウェアにあるんだ。一部のファームウェアは起動時にディスクから読み込まれるから、Xenのように「ハードウェア」と呼ぶのはマーケティング的な理由が大きいと思う（IBM内でどのチームが管理しているかにもよるし）。彼らのメインフレームのパーティショニングシステム、PR/SMは、もともとはVM/CMSの簡易版として始まったらしいけど、現在のリリースでPR/SMとz/VMの関係がどれくらい近いのかは分からない。この話は、共有セキュリティドメインで複数のカーネルを動かすことに似ていて、遷移や共有のパフォーマンスコストを減らすけど、適切なVMが提供する信頼性やセキュリティの利点は失われるよね。coLinuxを思い出すな（基本的には、Windows NTのデバイスドライバーとしてのLinuxカーネル）。OpenVMS Galaxyが実際にどう実装されていたのか、詳しい情報を持ってる人いる？ AlphaとItaniumの両方で利用可能だったと思うけど、x86-64にはまだ対応してないし（多分永遠に無理だろうけど…）。

「基盤となるハードウェアリソースを共有しながら」？あまりポジティブすぎると聞こえそうだけど、これが信頼性を持って動くのは地獄が凍るまで無理だと思う。動いているカーネル間でのアクセスを交互に行うのは「簡単」な部分かもしれないけど（DMAやコマンドキューがこれをかなり解決してくれるし）、もっと考えているのはドライバ内で状態保持や直列化に依存しているハードウェアのこと。例えば、普通のUSBやBluetoothのベンダーが「複数のインタリーブされたコマンドシーケンス」をテスト環境に持っているとは思えない。Linuxはこれが機能する前にマイクロカーネルアーキテクチャに移行しなければならないと思う。ハードウェアドライバ用に別々の「プロセス」を持てば、2つのユーザーランドを並行して動かすのは簡単になるはずだ（少なくともカーネルの残りを変換するよりは）。これがどう進展するか楽しみだね。アイデアは好きだけど、もしその方向に進むなら、複数のLinuxカーネルを監視するためにGenodeカーネルみたいなものを選ぶかな。

└

特定のデバイス、例えばBluetoothは共有しない方がいいよ。おそらく「メイン」のカーネルがブートプロセスを管理して、一部のデバイスを独占的に扱うことになると思う。実際の利点は、特定のアプリケーションをCPUのサブセット内で隔離して、専用のカーネルの背後で保護/封じ込めることだと思う。VMの遅延もないし、Dockerの隔離フィルターと戦う必要もないからね。

└

複数のカーネルがHWのドライバーを管理するっていうのは、何か言われてることあるの？ もしかしたら、一つのカーネルがハードウェアを管理して、他のカーネルはメインのカーネルと通信チャネルを使ってやり取りするってこともあり得るよね。それがKHOが存在する理由でもあると思う。ドライバーを管理しているカーネルをシャットダウンするときに、引き継ぎが必要だから。

└

これは実際に実装されて、複数のプラットフォームで使われたもので、一般的にはすべての相互作用するOSの慎重な開発が必要なんだ。マルチプレックスされるリソースは、実行中のカーネル間のIPCを通じて処理されるけど、そうでなければリソースは排他的に所有されることになってた。これにより、実際にはハイパーバイザーや特別なハードウェアサポートを使わずに、安価な「論理的パーティショニング」が可能になったんだ。

└

「クラウドプロバイダー」を考えてみて。今、物理NICを手に入れて、いくつかの仮想NICを作ることができるよ。GPUも同じ。要するに、ハードウェアを持っていて、各カーネル（つまり「仮想マシン」）が以下を得るってことだよね： - 専用のCPU - 物理メモリ - 仮想NIC - ストレージも、場合によっては（専用の場合；ネットワーク経由ならここでは何もなし） - AIのハイプトレイン用の仮想GPU すべてのカーネルは、実際には一部のハードウェアしか扱っていないのに、自分が本物のハードウェアを所有していると思っているんだ（これは多くの場所で見られる仮想化ハードウェアサポートのおかげ）。この機能は、私たちのノートパソコンで使える一般的な機能には見えないね。

一つのコアで侵害されたカーネルが他のコアをハイジャックするのを防ぐものは何？ これってあまりセキュリティの境界になってない気がする。

└

コード実行ができれば、何も防げないよ。でも、役立つのはsyscallやメモリマッピングのエクスプロイトみたいなシナリオで、ユーザープロセスは現在のカーネルに接続されているリソースにしか影響を与えられないんだ。例えば、https://dirtycow.ninja/ みたいな感じで、範囲は限られてる。

逆のこともできた時代があったよね。一つのLinuxカーネルで、クラスタ全体に統一されたユーザースペースを分散させるっていう。https://sourceforge.net/projects/kerrighed/

└

それいいね！似たようなアイデアで、複数のホストにまたがる大きなVMを動かすってのがあるよね。このアイデアは何度も進化してきて、最新のものは今年のKVMフォーラムでの発表だったよ。「GiantVM: A Many-to-one Virtualization System Built Atop the QEMU/KVM Hypervisor」 - ソンタオ・シュー、シーオン・ティエンレイ、ムリアン・ショウ - https://kvm-forum.qemu.org/2025/

└

現代のNUMA対応ソフトウェアが、LinuxのAPIが正しいトポロジーを報告すればこれを活用できるのかな。

これがうまく機能するためには、管理しなきゃいけないハードウェアのシングルトンがいくつかあるんだよね。いろいろ疑問が出てくる。例えば、PCIの列挙はどのカーネルがやるのか、どのカーネルがPCIデバイスの所有権を持つかはどう決まるのか？ACPIは？シリアルポートは？このアーキテクチャは、各カーネル間でRAMの所有権をどうやって移転するのか、あるいは固定構成なのか？NUMA対応はどうなるの？（おそらく、RAMが同じNUMAノードのCPUと一緒になるようにシステムをパーティション分けしたいよね）。一つのカーネルが「ハイパーバイザー」みたいな振る舞いをしないと、他のカーネルにリソースを分配できない気がする。PVM（https://lwn.net/Articles/963718/）がこの場合の好ましい解決策だと思う。ハイパーバイザーリソースを管理するソフトウェアスタックが再利用できるからね。

これを使って新しいカーネルをコンパイルできるかな？（その後、コンパイルしたカーネルが実行できるの？）新しいカーネルは効果（セキュリティ、パフォーマンスなど）に基づいて遺伝的にスコア付けされて、自動的に反復されることができるのかな、例えばAIによって？