■元麻布春男の週刊PCホットライン■ 仮想化技術へのもう1つの期待

●エラーログを報告しますか?

【図1】「深刻なエラー」ダイアログ

　ある程度Windowsを使ったことのあるユーザーなら、図1のようなメッセージを見たことがあるだろう。念のために解説しておくと、これはWindowsがいきなりリブートするような、深刻なエラーが発生した後、もう1度ログインした時に表示されるダイアログだ。

　このダイアログのデフォルトボタンは「エラーログを送信しない」になっており、聞くところでは日本からの送信は非常に少ないのだという(ほとんどが米国内からのものらしい)。ブロードバンド＆常時接続が普及した日本で、エラーログを送信したからといってお金がかかるわけでもないのに、エラーログを送信する人が少ないのは、送ったところで何にもならない、と考えている人が大半だからかもしれない。

　エラーログを送信すると、Microsoftのオンライン クラッシュ ダンプ解析サービスに接続される。が、ほとんどの場合「問題の原因はデバイスドライバですが特定できません」みたいなメッセージが表示されるだけ。具体的な問題の解決方法が提示されることはまれだ。1度、この表示に当たったユーザーは、2度とエラーログを送らないかもしれない。

　しかし、実はそうでないこともある。図2は先日、Windowsがクラッシュした際にエラーログを送信して表示されたもの。なんと問題の原因が特定された上、この問題を解決できるかもしれない更新があるという。素晴らしい。

　早速リンクをクリックするとCreativeのソフトウェア自動アップデートサイトへと飛ばされる。これで新しいドライバがインストールされ、問題が解決すれば人生捨てたものではないのだが、残念ながらそうたやすいものではない。何でもすでに最新バージョンがインストールされており、現在必要な更新はないのだという(図3)。惜しい。実に惜しい。MicrosoftもCreativeも、問題を解決しようと努力しているのは間違いないのだが、まだ万全の体制ではないようだ。

【図2】オンライン クラッシュ ダンプ解析サービスの通知画面	【図3】Creativeのソフトウェア自動アップデートサイトでは、「最新バージョンがインストールされています」と表示される

　というわけで、今でもある特定の操作をすると、筆者のシステムは突然リブートする。完全に再現性のある問題だが、再現性が把握できているということは、回避策も分かっているわけで、今となっては筆者にとって深刻な問題ではない。ある特定の操作をしなければ良いだけの話であるからだ。

　このように深刻なエラーから回復した後で、オンライン クラッシュ ダンプ解析サービスから問題を解決するための具体的な方策が示されることがあるとは聞いていた。が、なかなかそのチャンスが巡ってこなかった。今回、結局はうまくいかなかったとはいえ、その入り口まではたどり着くことができたというわけだ。

●Windowsの構造的な脆弱性

　しかし問題の本質は、今回障害を回避できるアップデートされたドライバを入手できなかった、ということでは全くない。最大の問題は、今のWindowsはデバイスドライバ1つで、場合によってはアプリケーション1つで簡単にリブートしてしまう脆弱なものに過ぎない、ということだ。恐ろしいことに、これはWindows XP Home Editionだろうと、Windows Serverだろうと、基本的に変わらない。Windowsのアーキテクチャ的な問題だ。

　元々のWindows NTは、このようなアーキテクチャではなかった。デバイスドライバはKernelモードで動作するドライバ(Kernelモードドライバ)とUserモードで動作するドライバ(サブシステムドライバ)に分かれており、ベンダに依存するドライバは基本的にサブシステムドライバとしてインストールされる形をとっていた。

　つまりKernelモードドライバは、基本的にMicrosoftがOSに付属する形で提供するもので、周辺機器に付属するドライバはサブシステムドライバだったわけだ。これなら、サードパーティ製のハードウェアをインストールしたからといって、そのドライバが原因でシステムがリブートしたり、フリーズするような危険性は低い。

　これが変更されたのはWindows NT 4.0の時だ。Windows NT 4.0では、サードパーティ製のドライバがKernelモードに組み込まれるようになった。理由は、性能の向上とDirectXのサポートだと考えられている。UserモードのドライバとKernelモードのドライバが連携して動作するアーキテクチャは安全な反面、DirectXのサポートが困難な上、オーバーヘッド(UserモードからKernelモードへ遷移する際にコンテキストの保存が必要など)が大きく、どうしても性能が振るわなかった。

　特に、クライアントOSとして主流だったWindows 95との比較が避けられなかった当時、性能改善とDirectXのサポートによるAPIセット面での優位性(Windows NTがAPI的にスーパーセットであるということ)を確保することが、Windows NT 4.0に課せられた重要命題の1つと考えられる。

　その一方で、サードパーティ製のドライバをKernelモードに組み込むことの危険性は早くから指摘されていた。それを防ぐために、WHQLやドライバのデジタル署名といった方策がとられたが、これらがいまだに安定性確保の切り札になり得ていないのは、明らかなことだ(おそらく今後も「気休め」的な効果しか期待できないだろう)。

●仮想化技術は切り札になるか

　現在、この問題の解決策として最も期待されているのが仮想化技術だ。仮想化技術を用いることで、1つのOS(が動く仮想マシン)が吹き飛んでも、ほかの仮想マシンで実行されているOSやその上で動作しているアプリケーションは保護される。仮想化環境と既存のOS間の互換性、あるいは仮想化環境上でのアプリケーション性能は、仮想化技術が普及する最大の障壁となってきたが、これを何とかしようというのがIntelのVanderpool(先日のIDFでIntel Virtualization Technologyという正式名称が発表された)であり、AMDのPacificaといった仮想化技術であるわけだ。

　これらの仮想化技術を用いると、OSそのものが最も特権レベルの高いRing 0で実行されることはなくなる(言い換えれば、Ring 0ではないところを、OSにRing 0だと思わせるのも仮想化技術の重要なポイントの1つだ)。当然、デバイスドライバが違反をしようと、OSそのものが吹き飛ぼうと、システム全体に影響を及ぼすことはなくなる。とりあえず問題の解決になることは間違いない。

　しかしまず懸念されるのは、仮想化技術の導入による一種のモラル低下だ。仮想化技術で守られている、ということで、OSなんて吹き飛ぶものとか、飛んでもしょうがない、といった考えが一般化しないかと心配してしまう。そんな考えで完成度の低いドライバやアプリケーションがはびこっては、利用者はたまらない。

　最初のWindows NT(Windows NT 3.1)がリリースされたのは'93年7月のことである。以来12年にわたり、さまざまな機能追加が行なわれてきた。機能追加とは、基本的にはコードの追加であり、コードが追加されることで潜在的な脆弱性や不具合も増える。現在開発が進められているLonghornを最後にして、次はゼロから全く新しいOS、堅固でセキュアなOSを作ってもらえないかと思っている。

　もちろん、ゼロから開発を行なった場合、デバイスドライバやAPIレベルでの互換性を100%保つことは難しい。当然移行のハードルは高くなるが、それで構わないではないかと思っている。ハードルが高ければ高いほど、移行した先で得られるものも大きくなるチャンスが増えると考えられるからだ。間もなくリリースされるx64版のWindowsは、32bit版アプリケーションとの互換性を持つなど、スムーズな移行ができることを前提にしている。が、それは同時に、移行した後に劇的な変化も得られないことを意味している。

　逆に互換性がなくなると、これまでのユーザー資産はどうなる、という話もあるだろう。しかし、これについてはあまり心配しなくてよいかもしれない。上で述べた仮想化技術で、新しい互換性のないOSと、古いこれまで使っていたOSを同時に利用すれば済むからだ。両者を共存させることは決して難しくないし、そのための仮想化技術なのである。

　仮想化技術が普及すれば、1台のハードウェア上で、同じOSを複数起動するだけでなく、異なるOSを複数起動することも可能になる。これは、Microsoftにもチャンスを与えるだろうが、Microsoft以外のOSベンダ(Linuxのディストリビューターを除くと、数えるほどかもしれないが)にも大チャンスだ。仮想化技術により、OSという土俵にも競争がもたらされることを切に願っている。

□バックナンバー

(2005年3月18日)

[Reported by 元麻布春男]