Skip to content

spec.md

Latest commit

 

History

History
88 lines (57 loc) · 5.76 KB

spec.md

File metadata and controls

88 lines (57 loc) · 5.76 KB
Raw

mochiOS Window System "Kagami" Specification

1. 概要 (Overview)

Kagami は、自作OS mochiOS 向けのコンポジット型ウィンドウサーバーです。 単なる描画エンジンではなく、「システムとユーザーの保護すべき領域を厳格に守る」 ことを最大の設計思想としています。各アプリケーションの描画領域を完全に分離し、Kagamiのみがそれらを合成（Composite）して画面という「鏡」に映し出します。

2. コア・アーキテクチャ (Core Architecture)

Kagamiは、以下の3つの主要コンポーネントで構成されます。

2.1 Kagami Daemon (kagamid)

ウィンドウシステムの心臓部となる特権プロセスです。

  • VRAMの独占: ビデオメモリに直接書き込む権限を持つ唯一のプロセスです。
  • イベントルーティング: カーネルからキーボード・マウスの割り込みを受け取り、現在フォーカスのある（かつ権限が許可された）アプリへ配送します。
  • コンポジタ (Compositor): 全アプリのバッファを収集し、Z-Order（重なり順）に従って1枚の画像に合成します。

2.2 LibKagami

各アプリケーションがウィンドウを描画・操作するためにリンクするクライアントライブラリです。

  • 内部で kagamid とのIPC（プロセス間通信）を隠蔽します。

2.3 Mochi-Buffer (共有メモリ管理)

アプリとサーバー間でピクセルデータをやり取りするためのメモリ領域です。

  • 分離の原則: アプリAは、アプリBの Mochi-Buffer を読み書きできません。
  • 権限の非対称性: アプリ側は「書き込みのみ」、Kagami側は「読み取りのみ」の権限を持ちます。

3. レイヤーと保護モデル (Layer & Protection Model)

Kagamiは、画面を論理的な「層（Layer）」に分割して管理します。鏡餅（Kagamimochi）の構造になぞらえ、上位の層ほど特権が高く、下位の層からは決して不可視・不可侵となります。

レイヤー名 役割 (例) 権限レベル 保護・防衛ロジック
System Layer ログイン、パスワード要求、緊急通知 最高 (特権) [橙/Daidai] 絶対に他の層の下に潜らない。この層がアクティブな時、他の全アプリへの入力イベントは遮断される。
Status Layer タスクバー、メニューバー 高 常にApp Layerの上に描画される。一般アプリがこの座標に描画を試みても、Kagami側でクリッピング（切り捨て）する。
App Layer 一般アプリのウィンドウ 中 各アプリは自身のバッファのみアクセス可能。画面キャプチャAPIを呼ぶにはTCC（ユーザー許可）が必要。
Wallpaper Layer 背景画像、デスクトップアイコン 低 常に最背面に描画される。

4. セキュリティと防衛メカニズム (Security Mechanisms)

4.1 Secure Event Input (入力の保護)

System Layer に属するウィンドウ（例：パスワード入力欄）にフォーカスがある場合、kagamid は「Secure Input Mode」に遷移します。この状態では、バックグラウンドで動作する他のアプリに対して、キーボードイベントの配送をOSレベルで完全に停止し、キーロガーによる盗聴を防ぎます。

4.2 Anti-Spoofing (なりすまし防止)

一般のアプリケーションが System Layer や Status Layer のフラグを立ててウィンドウを作成しようとした場合、kagamid は要求元のプロセスID（PID）の権限をカーネルに問い合わせ、許可されていない場合は要求を破棄します。

5. 通信プロトコル (IPC Protocol) - Draft

アプリと kagamid は、メッセージパッシングにより通信を行います。

主要なメッセージタイプ:

  1. REQ_CREATE_WINDOW : ウィンドウ作成要求（サイズ、希望レイヤー）
  2. RES_WINDOW_CREATED : 応答（割り当てられた Mochi-Buffer のID）
  3. REQ_FLUSH : 描画完了通知（「合成して画面を更新してほしい」という合図）
  4. EVT_KEYBOARD / EVT_MOUSE : kagamid からアプリへの入力通知

6. MVP開発ロードマップ (Roadmap)

  • Phase 1: 基礎描画
    • kagamid がカーネルのフレームバッファを取得し、画面を単色で塗りつぶす。
    • マウスカーソルの描画と移動（ハードウェア割り込みとの連携）。
  • Phase 2: Mochi-Buffer と IPC
    • クライアントアプリがダミーのピクセルデータを送信し、kagamid がそれを受け取る。
  • Phase 3: 合成 (Compositing) の実装
    • 複数のアプリのバッファを、Z-Orderに従ってVRAMへ転送する（ダブルバッファリング）。
  • Phase 4: 保護レイヤーの導入
    • System Layer を実装し、一般アプリが全画面表示しても System Layer が上に描画される（クリッピングされる）ことを証明する。 カーネル側の フレームバッファ（VRAM）の取得 か、それとも **IPC（プロセス間通信）のデータ構造（C言語やRustの構造体）の定義 ** か、どのあたりからコードを書き始めたいですか？