4 level privilege(1)

さて、どこから手を付けるかちょっと考えたが、まずはこの話からゆきたい。Intelは80386以降で、4レベルのProtection Ringという概念を導入した(Photo01)。もっともこれは何か? というと、単にセグメントレジスタをアクセスする際に、権限チェックを行えるようにするというだけの話である。

Photo02は具体的な操作例であるが、今Ring 1/2/3にそれぞれ独自のプログラム(Code Segment)がロードされている。CPLはCode Privilege Level、RPLはRequested Privilege Level、DPLはData Privilege Levelの略である。今Ring 2にあるCode Segment Aは自分のCPLが2だから、RPLも当然2であり、同じRing 2に所属するDPL=2のData Segment 2には当然アクセスできる。また、Ring 1で動いているCode Segument Bは、RPL=1なのでRing 1のData Segmentは当然アクセスできるとして、自分より権限の低いDPL=2のData Segmentにもアクセスが可能である。ところが逆に、Ring 3にいるCode Segment Cの場合、DPL=3のData Segmentにはアクセスできても、DPL=2のData Segment Eには権限違反ということでアクセスが出来ない。要するに、自分の持つ権限レベル(CPL/DPL)以下(＝数字が大きい)のエリアに対してのアクセス(RPL)は可能だが、自分の権限レベルを超える(＝数字が小さい)エリアへのアクセスは不可能、ということになっている。

OSは一般にこれをどう使うかであるが、OSカーネルのCodeエリアとかドライバ類、OSの管理データ構造(プロセス一覧とかメモリ割り当てとか)を全てRing 0に割りあて、一方普通のアプリケーションはRing 3で走らせることにしている。この結果、不用意に特定のアプリケーションが侵入されても、OSのコードやデータ構造にアクセスする権限が無いから、OS全体に影響を及ぼさない、というのがここでの趣旨である。逆に言えば、Privilegeが行うのは単にこれだけであって、それ以外の保護機能などは特に持ち合わせていない。

さて、話をWindowsに移す。Windowsはこの4つのPrivilegeのうち、Ring 0をKernel Mode、Ring 3をUser Modeとして利用しており、Ring 1/2は未使用となっている。このあたりはInside Windows 4.2.5(上巻P19～)に簡単にまとめられているが、この中の注で、何故Privilegeを4つとも使わないかという理由が示されている(上巻P20)。まぁ実際、例えばMIPSのR3000などはKernel modeとUser modeの2種類しかない訳だが、問題はそういうことだけではない。では何故R3000が2種類しかないかといえば、対象として考えていた主要なOSがいずれも2種類しか使ってなかったから、これで必要十分という判断が下されたためだと思うが、では何でIntelは4種類ものPrivilegeをカバーしたのか? という話になる。

そこで元となったVAX/VMSにおけるPrivilegeの使い方を図1に紹介する。カーネルの中核部分、つまり実際にハードウェアのアクセスを行ったり、メモリ管理/プロセス管理を行う部分はやはりKernel Modeで動作する。面白いのはその外側に、Executive Modeと呼ばれるレイヤが用意されていること。System ServiceというのはUNIXで言うところのSystem Callに近い。例えばSYS$ASSIGN(あるデバイスを論理的に占有するサービス。UNIXで言えばopen()というあたりか)とかSYS$QIO(Queue-I/Oの略。UNIXではread()/write()あたりに該当する)といった、かなりプリミティブなサービス類がここに当たる。その下にあるのがSupervisor Modeで、ここではRMS(つまりファイルシステム)と、Executive Modeよりももう少し高水準なSystem Serviceである。ファイルシステムはKernel Modeで動いてない、というあたりがミソで、例えばファイルシステムがおかしくなったからといって、すぐさまOSがクラッシュする事にはならない(*1)。「仮想記憶でファイルシステム使うのにこれはオーバーヘッドが大きいのでは?」と思われるかも知れないが、仮想記憶に使うページファイルは、ファイルシステムの管理下には無い。詳しい話はまたいずれするが、仮想記憶に使うページファイルは、Memory Mappingという形で物理メモリと一対一でマッピングしており、この部分は直接Kernel Modeで動作している。Supervisor Modeで動くRMSはいわゆるツリー構造のファイルシステムを提供するが、これは内部的にExecutive Mode経由でKernel Modeのドライバを叩く形になっており、従ってファイルシステムが崩壊したからといってOSそのものには影響がないようになっている(図2)。(続く)

(*1)だからといって処理が続行できるかといえば、それはまた別の話であるが。