BlogAboutContactDashboard
目次↑

【開発レポ①】Exokernel OS 初期化からユーザ空間起動

みなさん、こんにちは。今回は「Exokernelベースの独自OS開発」について、ここまでの進捗をまとめてご報告します。

古民家再生のブログとは別軸で進めているプロジェクトですが、ようやくハードウェア初期化・ユーザプログラムの起動テストまで一通り形になってきたので、現状と今後の計画を共有したいと思います。

1. 進捗概要

  1. Exokernelの最小コア実装
    CPU初期化、ブート（UEFI経由）、GDT/IDT設定、メモリ管理の土台が完成。

    起動時に多段ページテーブルを構築し、64bitロングモードへ移行できるようになりました。

  2. システムコール切り替え (int 0x80 → syscall命令)
    初期実装中は、 x86 的な int 0x80 割り込みベースでシステムコールを扱っていましたが、今は64bit専用のsyscall命令に移行済み。
    • STAR/LSTAR MSRの設定でユーザ空間→カーネル空間への切り替えがスムーズに動くよう調整
    • ユーザプログラムのsys_writeやsys_exitが正常に呼び出せることをQEMU上で確認

  3. ユーザモードのテストプログラム実行成功✅
    ELFローダを実装し、簡単な「Hello World」やsys_writeテストが正常に動作。
    • QEMUのシリアル出力に「Hello from Kagiroi User Space!」と表示される
    • プログラム終了後は sys_exit(0) でユーザ空間が停止し、カーネルだけが動作継続

  4. 複数ファイルの整理
    • kernelディレクトリ内にリンカスクリプト、CPU/メモリ周りのコードを配置
    • apps ディレクトリにユーザプログラムを配置（hello_world, test_userprogなど）
    • libraryOS ディレクトリに「linux_compat」や「windows_compat」などのモジュールを用意

      （まだ大きな機能実装には至っていないが、将来的にライブラリOSとして拡張する土台）

  5. 最低限のログ＆デバッグ出力
    シリアルポートへのログ出力と、フレームバッファ（グラフィック画面）への出力を並行して使えるように。
    • フレームバッファへのテキスト描画は簡易的なフォントを使った表示
    • シリアルのほうがデバッグ向けに詳しいログを表示

2. 現時点で実装できた機能

  1. ブート & ロングモード移行✅
    • UEFIブートでカーネルイメージを読み込み、kernel_mainに制御が移る
    • GDT/IDTを初期化し、割り込みを有効化

  2. 基本的なメモリマップとページング✅
    • OffsetPageTable（カーネル空間用）をセットアップ
    • 動的フレームアロケータでページを割り当てし、ユーザプログラムをロード可能

  3. ユーザプログラムロード & ELF解析✅
    • ELFヘッダとプログラムヘッダを解析し、PT_LOADセグメントを正しい仮想アドレスにマッピング
    • ユーザのエントリポイントにジャンプして実行開始

  4. システムコール実行 (syscall命令)✅
    • MSR設定（STAR/LSTAR/FMASK/EFER）
    • sys_write/sys_exitをテストしてOK
    • syscallエントリラッパで引数をRustの関数に受け渡すところまで整備

  5. ユーザスタックの確保とユーザモード遷移✅
    • 必要なページを割り当ててスタックを用意
    • iretq（もしくはsysretq）ベースでユーザ空間に移行

  6. デバッグ・ログまわり✅
    • シリアルへの出力
    • フレームバッファへの文字描画（簡易フォント使用）
    • IDT例外ハンドラでエラー時のレジスタ内容をダンプ

3. 今後の目標・課題

  1. 複数ライブラリOSを共存できる仕組み
    • いまは「Linux互換」風のコードを置いているだけなので、Windows互換やmacOS風など、複数の“ライブラリOS”をユーザ空間内で使い分けるにはさらなる分離メカニズムが必要。
    • スレッドモデルやドメイン切り替えをどう実装するか（Exokernelらしい保護の最小化を目指す）。
  2. AIエージェントとの統合
    • 現在はまだ“ホストOS上”でバイナリ解析ツールやLLMが動いているだけ。
    • 将来的には、Exokernel上でAIが「このバイナリはどのライブラリOSで動かすべきか」を自動判別し、実行を割り振る仕組みを導入予定。
    • ただし、メモリ消費やコンパイル環境などの整備が不可欠。
  3. 自己改善（セルフホスティング）機能の検討
    • AIが自分のコードやOS部品を修正・再ビルドする流れは、まだPoC段階
    • Exokernel内部でどこまで「ホットスワップ」的にパッチを当てられるか、セキュリティ面での課題も大きい。
  4. 周辺デバイスやドライバサポート
    • 現状、シリアルポート＆VGAフレームバッファしか触れていない。
    • ネットワークカードやUSB周りを扱えるようにするには、ユーザ空間ドライバが必要あり。
    • これもExokernelであることを考慮して、物理資源（デバイスレジスタ）を直接ユーザプロセスへ割り当てる仕組みを検討する必要あり。
  5. 安定性・パフォーマンス検証
    • ユーザモードで複数アプリを同時起動したり、マルチコア環境（SMP）でスレッドを分散させたりするテストは未実施。
    • タイマー割り込みやスケジューラも仮実装なので、実運用にはまだまだ道のりが長い。

4. 直近の作業スケジュール

  1. システムコールの拡張
    • sys_open, sys_close, sys_read, sys_mmap など、もう少しファイルI/O系を整備
    • 仮想メモリ領域管理を拡張し、ユーザ空間のメモリマップを柔軟にコントロール
  2. 簡易的なプロセス管理　－Exokernel準拠－
    • “保護ドメイン” 単位でページテーブルを切り替える仕組みを試す
    • 複数ユーザプログラムを並行実行し、タイマー割り込みでスケジューリング
  3. AI側との連携基盤
    • まずはホスト側AIとQEMU上のカーネルをソケット通信で結び、バイナリを送受信→実行する実験を行う
    • 最終的にExokernel内でもAIが部分的に動けるよう、クロスコンパイルやリソース制限の検討
  4. 不審バイナリ検知 & セキュリティ試験
    • ファジングツールの導入
    • 検査モジュール（ユーザ空間）を追加し、危険判定なら強制終了させる実装をテスト

5. まとめ

  1. 現在の状態:
    • "最小カーネル + ELFローダ + syscall + ユーザ空間テスト" の段階に到達。
    • 単純なユーザプログラム（例：hello_worldやtest_userprog）が走るところまで成功。
  2. 主な課題:
    • 複数のライブラリOSをどう並行実行するか
    • AIとの統合やセルフホスティングを実現するためのインタフェース整備
    • 周辺機能（ネットワーク、USB、ドライバモデルなど）はこれから
  3. 今後の展望:
    • Exokernelらしい『超軽量かつ高い自由度』を活かして、マルチOSサンドボックス環境を構築したい
    • AIエージェントが未知バイナリを解析しながら、安全なライブラリOSへ割り当てを行う実験を行いたい

まだまだ「やりたいこと」に比べれば進捗は序盤ですが、“動くプロトタイプが生まれた”ことは大きな一歩。
ここから徐々に多機能化していけるように、今後も地道にアップデートしていきます。


次回の開発レポートでは、複数プロセスを同時実行させてみるところを目指します。引き続き、開発記録を楽しみにしていただけると幸いです！

⟵記事一覧へ戻る