2024 未踏ITに採択
当Blogでの報告が遅れたが, 未踏IT人材発掘・育成事業に採択された. IPA公式からの概要については, 未踏IT人材発掘・育成事業：2024年度採択プロジェクト概要（伊組PJ)を参考にしてほしい.
2024年度の未踏IT人材発掘・育成事業に採択されました. Capability-Basedな3rd-gen Microkernelと, POSIX LayerとしてのOS, そしてUser-LevelのBuddy SystemやSLAB Allocatorを実装します. 頑張るぞ〜！https://t.co/p5u3sbc6Cr pic.twitter.com/I3dWDQGPfy
— 𝗵𝗼𝗿𝗶𝘇𝗼𝗻 (@horizon2k38) 2024年6月7日
なにをつくるか
なにをつくるか, 簡単にまとめると:
- Capability-Based MicrokernelであるA9N
- A9NをコアとするPOSIX-CompatibleなOSであるKOTIO
- そのためのUser-Level Memory Management System (ULMM)
これらを実装する.
A9N
A9Nは, ぼくが未踏ジュニア時代から開発しているMicrokernelだ. 未踏ではこのKernelをObject-Capability Modelというセキュリティモデルを用いてCapability-Basedなものへ書き換える. Capabilityというのはオブジェクトに対する操作権限を表すトークンのようなものだ. 従来のセキュリティモデルとは異なり, 最小特権の原則を満たして安全に特権操作できる.
Capabilityを用いたMicrokernel/OSというのは昔から存在する. 古くはHydraやKeyKOS, そして現代においてはTSのseL4やGoogleのZircon, そしてHuaweiのHarmony Kernelなどがある.
KOITO
KOITOはA9N上に構築されるシステムだ. A9NはIPCを主体とするシステム*1であり, UNIXやLinux由来のKernel-Level API : システムコールは持ち合わせていない. そのため, KOITOはそれを扱いやすくするためのWrapper的側面を持つ. POSIXのシステムコールはUser-Levelで実現される. そのため, Hookも自由自在であり柔軟なシステムとなる.
ULMM
既存のシステムであるUNIXやLinuxは, メモリのFrame単位で見ればBuddy Systemを持つ. また, Kernel-Object単位で見ればSLAB/SLOB/SLUBをKernel-Levelで持つ. Kernelに必要なデータをユーザーに漏らさないため, Kernel自体で機構を持つ, というのは自然なことのように思える. 実際, 過去多くのMicrokernelではKernel内でメモリのAllocationを実行していた. これは純粋なMicrokernelでは無いように見えるし, 未踏ジュニア期間中ずっとそのように感じていた.
Capability-Based MicrokernelではKernelの情報を漏らさず, セキュアにFrameやKernel Objectを管理できる. 抽象メモリCapabilityを用意して, それを必要なObjectへ分割する操作を実装すれば良いのだ. この美しい仕組みにより, Buddy SystemやSLAB/SLOB/SLUBなどをServerとしてUser-Levelで実現できる.
思想
結局のところ, 美しく純粋なMicrokernel*2を書きたい, というモチベがこのプロジェクトを始めたきっかけだ. その点においては未踏ジュニアと何も変わらず, 低レイヤー x ソフトウェアアーキテクチャ というアイデアを組み合わせただけに過ぎない. 夢を語るとするなら, いずれLinux Kernelを置き換えられるような存在にしていきたい.
