一般保護違反（General Protection Fault）とは本来、OSが不正な命令を出したプロセスを強制終了するための安全機構だ。Hailey Somerville氏が公開した「WSL9x」は、その安全機構を逆手に取り、Linuxのシステムコール処理路として動かす。30年前のレガシーOSであるWindows 95上で、仮想化もエミュレーションもなしにLinuxカーネル6.19が動作する。Intel 486プロセッサでも稼働するこのアーキテクチャは、いかにして越えられないとされた構造的制約を破ったのか。例外処理を悪用する三段構えの転用機構と、リング0で二つのカーネルが同居するリスクを解説する。

AD

30年前のレガシーOSが抱えるアーキテクチャの壁

Windows 9x（Windows 95や98などの総称）には、Linuxをネイティブ動作させる上で越えられないとされてきた構造的な壁が存在する。Linuxのi386アーキテクチャにおけるシステムコールは、通常「int 0x80」というソフトウェア割り込み命令を通じてカーネルに特権処理を要求する仕組みだ。しかし、Windows 9xのカーネルは、この特定の割り込みベクタを適切に処理するための十分な長さを持つ割り込み記述子テーブル（IDT：Interrupt Descriptor Table）を備えていない。このテーブルの欠落により、Linuxの標準的なバイナリがシステムコールを発行した瞬間、OSは不正な命令として処理を打ち切り、システムは即座にエラーを吐き出して停止する。

現代の開発環境で標準的に用いられる仮想化技術を用いたアプローチも、このレガシー環境では通用しない。現在のWindows 10や11に搭載されているWSL2（Windows Subsystem for Linux 2）は、Intel VT-xやAMD-VといったCPUのハードウェアレベルの仮想化支援技術を前提に設計されている。Windows 9xが稼働していたIntel 486プロセッサや初期のPentiumプロセッサの時代には、CPU側の仮想化支援機能は存在しなかった。QEMUやBochsのようなソフトウェアによる完全な命令セットエミュレーションを選択すれば動作自体は可能になるものの、当時の数MHzから数百MHzという限られたCPU性能と数十MBのメモリ容量では、実用的な実行速度を全く得られない。

LinuxカーネルはPOSIX（Portable Operating System Interface）標準に基づくAPIを提供し、厳格なプロセス分離と仮想メモリ空間の管理を担う。一方、Windows 9xのカーネルAPIやVMM（Virtual Machine Manager）はこれと全く異なる設計思想で作られており、16ビットのMS-DOSコードと32ビットのWindowsコードが複雑に絡み合った構造を持つ。KernelExのようなWindows 9x上でモダンなWindowsアプリケーションを動かす互換レイヤーは存在するが、OSの根幹となるカーネルそのものを異種環境で動かすための土台は用意されていない。仮想化に頼らず、ハードウェアの制約を回避しながら二つの異なるカーネルを同一のメモリ空間上で協調させる道筋を、誰も提示できないまま長年の課題として残り続けてきた。

一般保護違反をインターセプトする3ステップの処理機構

Hailey Somerville氏は一般保護違反（GPF：General Protection Fault）ハンドラを悪用するという特異な手法を実装した。WSL9xのシステム初期化と制御の大部分は、Windows 9xの特権モードで動くVxD（Virtual Device Driver：仮想デバイスドライバ）が単独でこなす。このカスタムドライバはカーネルコードの初期マッピングをメモリ上に設定し、DOS割り込みを使用してディスクからLinuxカーネルの実行ファイルである「vmlinux.elf」を直接ロードする。その後、System VM（System Virtual Machine）内に新しいスレッドを開始し、Linux環境に移行するための16KiBのスタック領域を確保する。

システムの稼働後、VxDドライバはエラーを引き起こす命令の監視を続ける。監視網にLinuxのシステムコールである「int 0x80」が捕捉された瞬間、通常であれば致命的な例外としてブルースクリーンを引き起こすはずのこの違反を、OSが認識する前にインターセプトする。捕捉したGPFハンドラは、割り込みが正常に成功したかのように命令ポインタ（EIPレジスタ）を強制的に進める処理を挟む。その後、捕捉した命令を正規のシステムコールとしてパッチ適用済みのLinuxカーネル6.19にディスパッチし、Windows 9xのIDTが抱える根本的な制約を完全に迂回した。

カーネルへの進入やIRQ（Interrupt Request：割り込み要求）のディスパッチ、ユーザースペースへの復帰といった一連の処理は、専用のイベントループ内で連続して実行に移る。WindowsカーネルとLinuxカーネルが同じリング0（特権モード）の最高CPU権限を共有する設計だ。Somerville氏はHacker Newsの議論で、両者は協調する想定だが、どちらかがクラッシュすればシステム全体が道連れになると説明した。現代のOSが備えるユーザー空間とカーネル空間の厳格な分離は放棄され、パフォーマンスと実装の可能性を最優先したアーキテクチャになっている。

ユーザーがこのシステムと対話するインターフェースは、「wsl.com」という16ビットDOSプログラムが提供する。複雑なカスタムクライアントをゼロから構築する代わりに、既存のDOSプロンプトをそのままTTY（Teletypewriter：標準入出力端末）としてLinuxカーネルに渡す仕組みを取った。

WSL9xにはX11やWaylandといったグラフィカルユーザーインターフェース（GUI）のサポートは一切存在しない。ユーザーはWindows 95や98のデスクトップ上でDOSプロンプトのウィンドウを開き、黒い画面にテキストコマンドを入力してLinux環境のファイルシステムやプロセスを直接操作する。

AD

coLinuxからWSL2へ至る系譜とWSL9xの特異な立ち位置

wsl9x-screenshot.webp

Windows環境でLinuxを動作させる試みの歴史で、2000年代中盤に登場したcoLinux（Cooperative Linux）は重要なマイルストーンだ。coLinuxはLinux 2.6カーネルに独自のパッチを当て、Windows NT、2000、XPの環境上でネイティブ動作する環境を実現した。このプロジェクトはホストOSとゲストOSがリング0の特権モードを共有し、CPUの制御を細かく切り替えながら協調動作する設計を取った。しかし、対象はあくまで堅牢なメモリ保護機構を持つWindows NT系のカーネルに限られる。MS-DOSを基盤とし、16ビットコードが混在するWindows 9xのアーキテクチャはNT系とは全く異なるため、coLinuxをWindows 95や98に移植する道は閉ざされていた。

時代が下り、2016年にMicrosoftが公式にリリースした初代WSL（WSL1）は、Picoプロバイダーと呼ばれる仕組みを用い、LinuxのシステムコールをWindowsのシステムコールにリアルタイムで変換する手法を採用した。これはLinuxカーネルそのものを動かすのではなく、互換レイヤーを通じてELFバイナリを実行する仕組みだ。その後に登場したWSL2では方針を大きく転換し、Hyper-Vアーキテクチャを基盤とした軽量なユーティリティVM内で本物のLinuxカーネルを動かす構造になった。WSL2ではLinux側のプロセスが致命的なクラッシュを起こしても、分離されたVM内で完結するためWindowsホストに影響を与えない。

WSL9xの設計思想は特権モードを共有するcoLinuxの系譜に属するが、対象OSの古さとアーキテクチャの難度が桁違いだ。現代のWSL2がハードウェア仮想化を必須とし、coLinuxがより安定したNT系カーネルを基盤としたのに対し、WSL9xは仮想化支援のない環境で最も不安定なWindows 9xを標的にした。リング0で完全同居する設計は、現代の厳格なセキュリティ基準や安定性の観点から見れば耐障害性に乏しい構造を持つ。しかし、この密接な統合により、仮想化のオーバーヘッドを完全に排除し、数十年前の古いハードウェアでも再起動なしに両方のOSを並行実行できる状態を作り出した。

AIコード生成を排除した開発プロセスとコミュニティの熱狂

Hailey Somerville氏は、かつてGitHubに在籍し、2015年にはGitHub Pagesのアーキテクチャ再構築に携わった経歴を持つ熟練のエンジニアだ。近年もRust言語を用いた低遅延のロスレスオーディオストリーミングシステム「Bark」や、独自の趣味OS「crabos」の開発を手掛けている。WSL9xを構築する際、Somerville氏はMastodonでの発表時に、システム全体がAIによるコード生成支援を一切受けずに書かれたことを意図的に強調した。Windows 9xの内部仕様は公式ドキュメントが乏しく、AIが学習できる公開データ自体が極端に少ない領域だったため、Copilotのようなツールが推論不可能な対象だったとも考えられる。

Windows 9xのカーネル内部に関する技術ドキュメントは、現代の標準から見れば著しく乏しく、不完全な状態だ。VxDドライバの正確な挙動やメモリ管理の隠された仕組みを把握するには、当時の断片的な資料を読み解き、リバースエンジニアリングによる解析を進めなければならない。Somerville氏自身がMastodonで「私の史上最高のハックの一つ」と呼ぶGPFを用いたシステムコール処理も、こうした泥臭い手作業の解析と度重なるクラッシュの末に誕生した。公式な仕様書が存在しない領域で、OSの挙動を一つずつ確認しながらLinuxカーネルにパッチを当てる作業の結晶となっている。

この純粋な技術的挑戦に対し、開発者コミュニティからは称賛の声が寄せられている。Redditのユーザーはこれを「狂気の魔法」と呼び、Hacker NewsのフォーラムではcoLinuxやflinuxといった過去のプロジェクトと比較する技術議論が交わされた。技術メディアのOSnewsは、仮想化やデュアルブートなしで両方のOSを同時に動かせる点を高く評価し、ユーザー視点でのシンプルさが奇妙なほど美しいと評した。セキュリティリスクは高く、GUIアプリケーションも動かないが、過去の遺物となったOSの限界を力技で突破した事実に多くのエンジニアが魅了されている。WSL9xが示すのは、OSのアーキテクチャに正解は一つではなく、例外処理という隙間にこそ設計の自由が眠っているという技術的な命題だ。

Sources