Vol. 47

情報処理学会論文誌

No. 4

Apr. 2006

仮想マシンモニタにおけるデバイスドライバ安全性向上に関する提案
藤 澤 一 樹†1
金美 羅†1

橋 本 正 樹†1 宮 本 久 仁 男†1
辻秀 典†1,†2 田 中 英 彦†1

近年，注目を集める仮想化技術はコスト削減の観点から普及が始まった．今後，仮想化支援機能を搭載した CPU より一層普及していくことが考えられる．特に仮想マシンモニタ（VMM：Virtual
Machine Monitor または Hypervisor）というソフトウェアがパフォーマンスとセキュリティの点で注目を集める．VMM によって得られるセキュリティの効果は，VMM 上で稼動する Guest OS が使用するリソースを隔離できるということと，Guest OS の実行環境を防御可能になることが挙げられる．しかしながら，これらは VMM が安全であるという前提の基に成り立っており，VMM に脆弱性が存在すると，その上で動作する Guest OS が安全であってもシステム全体を脆弱性にしてしまう．そこで本稿では，Device Driver に起因する VMM の脆弱性を指摘し，これによって引き起こされる問題を事前に防ぐ手法を提案する．

Security enhancement of device drivers for virtual machine monitor
Kazuki Fujisawa,†1 Masaki Hashimotoo,†1 Kunio Miyamoto,†1
Mira Kim,†1 Hidenori Tuji†1,†2 and Hidehiko Tanaka†1
Now, Virtualization Technology which attracted attention came to be used from the viewpoint of cost cut. It is thought that it is used still more in future by a set of processor
enhancements that improve traditional software-based virtualization solutions. In particular,software called Virtual Machine Monitor (VMM or Hypervisor) attracts attention at a pointof performance and the security. VMM provide security advantage. VMM can isolate theresource that the Guest OS to operate on VMM uses and, VMM can defend the executing
environment of the Guest OS in VMM. However, these make ends meet by a premise that
VMM is secure. Even if the Guest OS on VMM is secure, if VMM has vulnerability to makesystem vulnerability. This paper points out that vulnerability of VMM is device driver. And
technique is proposed to prevent a problem to happen for it beforehand.

ジされた KVM（Kernel Based Virtual Machine）2)

1. は じ め になどが挙げられる．特に Xen は，全てのサーバ，デ

近年，注目を集める仮想化技術は，複数台のサースクトップ，ラップトップ，携帯電話に VMM が使わ

バを 1 台に集約すことによってサーバの運用効率をれる Ubiquitous Virtualization を目指しており，各向上させ TCO（Total Cost of Ownership）の削減

社の Enterprise Server の仮想化ソフトのベースとしができるという事から普及が始まった．今後，仮想て使われている．VMM は，その上で稼動する Guest

化支援技術を搭載した CPU によって一層普及するとOS が使用するリソースを隔離できるとともに，Guest

考えられる．仮想化技術の中でも特に仮想マシンモ

OS の実行環境を防御することができるため，これらニタ（VMM：Virtual Machine Monitor または Hy-の機能をセキュリティ分野に適用した研究例が多く存

pervisor）と呼ばれるソフトウェアがパフォーマンス

在する．例えば，隔離機能を強化し VMM に Guestとセキュリティの点から注目を集めており，その代表

OS 間のポリシーベースの強制アクセス制御を持たせ的な例として VMware ESX Server や OSS（Openたもの3) や，Guest OS のデバック機能を修正し防御

Source Software）の Xen1) や Linux カーネルにマー

対象システムのスナップショットを即座に取得できる
システム4) などがある．しかしながら，これらの研†1 情報セキュリティ大学院大学
INSTITUTE of INFORMATION SECURITY†2 株式会社情報技研
Institute of Information Technology, Inc.

究は，VMM が安全であるという前提に基づいているために，VMM に脆弱性が存在するとその上に載せた Guest OS が安全であってもシステム全体は脆弱に
1234

Vol. 47

No. 4

仮想マシンモニタにおけるデバイスドライバ安全性向上に関する提案

なってしまう．

1235

間で動作する．そのため，確保したメモリを開放

そこで本稿では，VMM 自体のセキュリティに焦点しないことによって，カーネルのメモリ空間を圧を合わせ，その安全性を向上させる手法を提案する．

迫し，メモリリークを起こす．また，自分以外の

まず，VMM の脆弱性として考えられるのは，Device

別のアドレスに書き込んでしまうことによって，Driver の脆弱性を突いて VMM の特権を奪取するこ

権限の昇格，クラッシュや DoS が起きる．さらとである．実装によるが，VMM は OS と同様に特権に，初期化せずにメモリを扱ったため，カーネル

モードで Device Driver を動作させるため，Deviceが使用したデータを Device に送ってしまいデー

Driver に脆弱性があった場合，VMM における特権命

タリークが起きる．

令を実行することができる．これによって Guest OS• バッファの取り扱い：Device Driver に記述されが停止されたり，新たな Guest OS が構築され踏み台たバッファのサイズを越えてデータを渡すことでにされたりするなどの問題が起きる．

バッファオーバフローが起きる．これによって権

現在の計算機における Device の機能が複雑になり，限の昇格，任意のコードの実行，クラッシュ，DoS

これらの機能を制御する Device Driver のコードがが可能となる．NIC（Network Interface Card）

大きくなりつつある．そのために脆弱性が存在するこのバッファに対してバッファオーバフロー攻撃をとが知られている．これら Device Driver が Trusted行うことができれば外部から特権を取得すること

Virtual Machine Monitor（TVMM）として研究されが可能となる．

5)ている Terraの中でも問題となることが指摘されてここで挙げた Device Driver は我々が調査／分析をおり，Device Driver を Trusted Computing Base の行った結果の中から，上位 4 項目にあたる脆弱性へ一部として含めることができないということを述べての対応を目標とし，これらの脆弱性に対して，Device

いる．

Driver に対するリファレンスモニタを導入することで我々は ，Terra の User Mode Driver と Next-

Generation Secure Computing Base6) を用いる方法と異なり，ハードウェアに依存せず Device Driver にシステムを保護する．

3. 関 連 研 究

起因する問題を防ぐために，Device Driver に対する

Device Driver の脆弱性によって起きる問題を回避

7)

しシステムの安全性を向上させるために様々な実装やリファレンスモニタを提案

し，Xen 上での提案アー

キテクチャを示す．
本稿では，以下のように構成される第 2 節で，De-

vice Driver と脆弱性について述べ，第 3，4 節で関連研究が行われており，これらは大きく 4 つに分類する
ことができる．それぞれの方法については以下に詳しく説明する．

研究と本提案に至る議論について述べる．そして第 5，

3.1 バグの極小化

6 節にて提案アーキテクチャの概要と実装について説

Device Driver そのものに存在する脆弱性を出来る限明し，最後に，まとめと今後の課題について述べる．

り排除することでシステムへの影響を小さくする手法

2. Device Driver と脆弱性である．主に SCAT（Static Code Analysis Tool）を用いてバグを発見する方法と DSL（Domain-Speciﬁc

Device Driver が VMM の脆弱性になることを第 1Language）を用いて正しく動作をすることを確かめ節にて述べた．以下に Device Driver の脆弱性についる方法，ソフトウェアテストがある．Engler 等の研て説明する．

究8) のように SCAT はソースコードを静的解析して脆• 入力値の取り扱い：Device Driver は，Systemcall

弱性を発見する方法である．Microsoft は，Windowsを通じてユーザからデータを受け取る．このデーの Device Driver に最適化した Static Driver Veriﬁer

タのサニタイズやサイズのチェックを行わないこ（SDV）9) を提供している．

とによって整数オーバフローが発生し，権限の昇格やクラッシュ，DoS が起きる．

DSL は，C 言語等の汎用言語と異なり，ある用途に設計された言語で，ソースコードの検証が可能である．

• 権限の取り扱い：Device Driver に記述しなければDevice Driver の開発用として NDL10) などがある．

ならない権限項目を忘れたことや，権限の設定ミ

ソフトウェアテストでは，静的に発見できないバグ

スによって起きる問題ある．この脆弱性によって，をプログラムを動作させることで動的に発見できる．

権限の昇格や任意のコードの実行が可能となる．

ブラックボックステストやホワイトボックステストが• メモリの取り扱い：Device Driver はカーネル空ある．また，Microsoft の Device Driver 署名11) のよ情報処理学会論文誌1236

うな外部監査的なアプローチは有用である．

Apr. 2006

FED: Frontend Driver

3.2 特権モード動作の局所化

BED: Backend Driver DD: Device Driver
アプリケーション

Xen管理ツール

通常，特権モードで動作する Device Driver を特権
モードと非特権モードに分ける方法である．この方

dom 0

dom U

dom U

法は，パフォーマンス低下を最小限にして，Device

Driver によるシステムに対する影響を小さくする．

DD

BED

FED

この手法は Microsoft の Windows Vista で Kernel

FED

XenbusMode Driver と User Mode Driver12) として実装さ

Xen

れ，3D ゲーム等の高パフォーマンスの要求に対応できる．
Device3.3 特権モードからの排除

Hardware

一般的に micro-kernel における Device Driver は，

図 1 Xen アーキテクチャ
Fig. 1 Xen Architecture

ユーザ空間で動作しており，特権モードから Device

Driver を排除している．また，VMM 自体に Device
Driver を持たせないことで Device Driver の脆弱性

回避する手法について実装方法や研究について述べた．

による影響を排除する手法がある．この手法はケンブ現存する保護手法の問題と，提案手法にいたる議論にリッジ大学で開発された VMM である Xen

13)

に実装

ついて本節では述べる．

されている．Fig.1 に示すように Xen 自体は Device

一般にセキュリティ対策は，ソフトウェア開発工程

Driver を持たなく，管理ドメイン（dom 0）の Device

である設計，実装，テスト，運用というサイクル全て

Driver を利用する．dom 0 は Xen を管理する特権ドで行うことが重要である．しかしながら，全ての段階

メインであり，非特権ドメイン（dom U）とは区別さでセキュリティ対策を行うことは難しく，行った場合れる．dom U から Device へのアクセス要求があったも全ての脆弱性を無くすことは困難である．そのため場合は，必ず Frontend Driver（FED）が Xenbus を運用時にセキュリティ対策をすることが多い．第 3 節

通って Backend Driver（BED）にアクセスし，domで述べた既存の研究も，実装・テスト・運用に分ける

0 の Device Driver が Device へアクセスするようにことができる．

している．同様に，IBM Research によって開発され実装工程において，SCAT は有効である．しかし，こた Secure Hypervisor（sHype）3) や Terra において

れらのツールは，あらかじめ決められたルールに違反も VMM 自体が Device Driver を持つことは好まししているかどうかを検査しているためルールに存在しくないことが述べられている．また，micro-kernel でないものは検出できない．SDV は，WDM（Windows

ある L4 を VMM とし，QEMU をサービスとするこ

Driver Model）と，その後継にあたる WDF（Win-とで，Guest OS を動作させる L4VM がある．このdows Driver Foundation）というフレームワークのL4VM を用いて通常の OS の Device Driver を Reuse

違反を検出するため，それらフレームワークに脆弱性

14)

する研究

3.4 隔

がある．

が存在すると修正を困難にする．一般的な SCAT は，離

False Positive と False Negative の問題があり，最終

micro-kernel であれば，サービスとして Device

的に人の目が必要である．DSL は，Device Driver のDriver を動作させ，他のサービスから隔離することがセキュリティに対する究極のアプローチであるが設計可能である．そのため Device Driver の故障によって／運用／保守のコストが高くなるという欠点があるた

OS がクラッシュすることはない．しかし，monolithic-

め普及していない．さらに，汎用言語から DSL を呼kernel であると Device Driver の故障が OS をクラッ

ぶためのインタフェースに脆弱性があると，DSL でシュさせる．そこで，OS の拡張機能の保護を目的とし書かれたコードが安全であってもシステムは脆弱なま

た Nooks15) を用いて，Device Driver を隔離し，OSまである．また，ソースコードの検証には人の目が必をクラッシュから保護し，故障した Device Driver の要である．

リカバリを可能16) とした．

4. 不完全な保護方法
第 3 節にて，Device Driver によって起きる問題を

テスト工程における動的解析は，静的解析で見つけられないバグを発見できることができる．しかし全てのテスト項目を網羅することは難しく，取りこぼしが起きる．そのため，Device Driver 署名を得るためのVol. 47

No. 4

仮想マシンモニタにおけるデバイスドライバ安全性向上に関する提案

1237

検査や通常のソフトウェアテストも脆弱性を発見できることで，攻撃をアクセス拒否し，Device Driver のないことがある．

脆弱性からシステムを保護する．さらに Xen 上で実実装／テスト工程で発見できない脆弱性からシス装することで Device Driver を特権モードで動作させテムを保護するのが運用時のセキュリティ対策である必要がないため，さらに VMM を安全にすることる．特権モードの局所化は，特権モードで動作するができる．

Device Driver が残っており，Device Driver を保護する機能がない．次に特権モードで動作する Device

5. 提案アーキテクチャ

Driver の排除では，パフォーマンスの観点から純粋な第 1，2 節で VMM が安全であるという前提に基づ

micro-kernel を採用するコモディティな OS（Linux

いて VMM における研究がされていること，Device

や Windows 等）は無く，OS がクラッシュすること

Driver の問題が VMM の脆弱性となりえることを述はないが，Device Driver に対する攻撃からシステム

べた．さらに第 3 節にて，行われている取り組み，第を保護する機能を持たない．Xen のような VMM に

4 節にて提案方式にいたった理由を述べた．本節ではDevice Driver を持たせない方法は，VMM を安全に

提案アーキテクチャについて述べる．

するが，dom 0 の Device Driver を用いているため，

5.1 提案アーキテクチャの概要

攻撃者が Device Driver の脆弱性を突き，dom 0 のコ

我々は，Device Driver に対してリファレンスモニ

ントロールができるようになると，Xen のコントロー

タを導入し，I/O アクセスに対して MAC を執行する

ルが可能となるという問題がある．L4VM の Reuse

ことで Device Driver の脆弱性からシステムを保護す

する Device Driver が安全であるとは証明できず，まることを述べた．しかし，リファレンスモニタを採用た，Device Domain は任意の VM または，VMM でした Secure OS や VMM の中には I/O 制限が可能なあり，Xen 同様にコントロール VM の問題を残す．隔ものがある．NSA が中心になって開発した Security-

離ができる Nooks は，Device Driver の故障からシEnhanced Linux（SELinux）18) や sHype などである．

ステムを保護するために開発されたものであり攻撃かSELinux は，LSM(Linux Security Module) を採用

らシステムを保護することができない．また，Device

し，PLP と MAC を Linux に提供することで Linux

Driver は特権で動作しているままであり隔離も弱い．

を Secure OS とする．しかしながら，SELinux は，

特にコモディティな OS であることは重要であり，

アプリケーション空間でのみ有効である．そのため，セキュア VM17) では，その点を考慮して OS でなく

Device Driver を LKM（Loadable Kernel Module）

VMM によって OS のセキュリティの担保しようとしとして実装する Linux の場合，Device Driver の脆弱ている．VMM を用いることで OS に比べ，多くの性そのものがカーネルの脆弱性となるため SELinux

特権レベルを使えるためセキュリティレベルを高めらでは防ぐことはできない．sHype は，リファレンスモ

れる．

ニタを VMM に内蔵し，VM 間の MAC を実現する

このように，設計，ソフトウェアテストで脆弱性をが，攻撃からシステムの保護が目的で無いため，De-

完全に排除するには限界があり，既存の運用時に保護

vice Driver の脆弱性に対する攻撃からシステムを保する仕組みは，結果的に特権モードで動作するか，一護できない．

般的なアプローチでないため，根本的な解決は難しい．

そこで，本稿では，Device Driver に対してリファレ

以上の理由から現在まで存在している 4 つの手法でンスモニタを提案する．提案アーキテクチャを Fig.2 には VMM を保護できないと考えた．そこで本稿では，示す．提案アーキテクチャは Flask アーキテクチャ19)

Nooks が Device Driver の故障から動的にシステムのようにセキュリティポリシーによる MAC の執行を保護したように，Device Driver の脆弱性から動的に行うサブシステムとセキュリティポリシーに従ってアシステムを保護するアプローチをとる．このアプロー

クセス可否を決定するサブシステムに分けて，より安チは，Secure OS の考え方と同様で脆弱性を持ってい

全で柔軟なポリシーを扱えるリファレンスモニタを構ることを前提にしている．Secure OS の場合は，最築する．

小特権の原則（PLP: Principle of least privilege）に

提案アーキテクチャは，Device Driver に対してサン

よって，root 権限を分割し，強制アクセス制御（MAC:

ドイッチ型に Last Driver（以降:LD）と First Driver

Mandatory access control）によって被害を拡大する（以降:FD）というセキュリティポリシーによる MAC

ことを防ぐ．Device Driver に対してリファレンスモ

の執行を行うサブシステムと Device Driver Auditor

ニタを導入し，I/O アクセスに対して MAC を執行す

（以降:DDA）というキュリティポリシーに従ってアク情報処理学会論文誌

1238
Guest OS

LD: Last Driver
FD: First Driver

VMM

DD: Device Driver
DDA: Device Driver Auditor

モニター及び
MACの執行LD

Apr. 2006

Step6: DDA は Device Driver のハッシュ値を求
め，格納する

Step7: DDA はポリシーを読み込み，提案アーキ
テクチャの動作準備が完了する

アクセス可否の決定

提案アーキテクチャは I/O アクセスに対しての MAC
DD

DDAを執行するが場合によって FD と LD の動作が異なる．
本稿では VMM から Device に通知する場合を Inside，

モニター及び
MACの執行FD

Device から VMM に通知される場合を Outside と定義する．FD と LD は対の関係になっており，Inside

Device
図 2 提案アーキテクチャ
Fig. 2 Proposed Architectureからのアクセスと Outside からのアクセスで逆の動作を行う．それぞれの動作について Fig.3 と Fig.4 に示した．以下に Inside と Outside についての動作を示す．

セス可否を決定するサブシステムからなる．
Guest OS

提案アーキテクチャの特徴は，Device Driver をサンドイッチのように挟み込むように LD と FD が存

VMM

在することである．サンドイッチ型にすることにより

NIC がパケットを受信して，ハードウェア割り込みがPolicyLD
Detection

DDA

Query

発生するような，ネットワークドライバの非同期アクセスに対しても MAC の執行が可能となる．

Device Driver と関連する問題として不正な Deviceを接続し，DMA を用いて不正なメモリアクセスを行

Decision結果
Enforcement

アクセス拒否DD

う攻撃があるが，本研究では，その攻撃をハードウェ
アで保護する Intel の VT-d20) や AMD の AMD-V21)

FDが存在することやソフトウェアで保護する機能が Xen
や L4VM で実現されていることから DMA を用いた攻撃からシステム保護することは対象としない．

5.2 動

作

Device

図 3 提案アーキテクチャの動作（Inside）
Fig. 3 Running of Proposed Architecture(Inside)

提案アーキテクチャはリファレンスモニタである以
上，リファレンスモニタの必要条件を満たす必要があInside の場合:

る．提案方式における DDA の役割は，アクセス可否

Step1: あるプログラムからハードウェアへのアクの決定だけでなく，Device Driver，FD，LD の完全性を保証する機能を持つため DDA 自体の完全性を保証しなければならない．そのため，VMM の起動時に，何らかのプログラムによって DDA のメモリ空間を，セス要求が発生し，Systemcall が発生する

Step2: LD は Systemcall をトラップし，メッセー
ジを生成して Query を DDA に送信する

Step3: DDA は LD から送信された Query を受信

書き換えられることを想定し，起動後に，再起動を行しセキュリティポリシーと比較，アクセス可否のう．以下に起動手順を示す．

決定を下す（Decision）

提案アーキテクチャの起動:

Step4: DDA は Decision 結果を LD に送信する

Step1: 電源 ON，BIOS，ブートローダ，VMM が

Step5: LD は DDA から送信された Decision に基起動する

づいて MAC の執行を行う

Step2: DDA が VMM によって呼び出される
Step3: DDA 自らを再起動する

Outside の場合:

Step4: DDA は再起動時に自分自身が正しいこと

Step1: 割り込み線に信号が入りハードウェア割りを確認する

Step5: DDA は FD，LD が正しいことを確認する．

込みが生じ，割り込みハンドラが実行される．

Step2: FD は割り込みハンドラをトラップし，メッVol. 47

No. 4

仮想マシンモニタにおけるデバイスドライバ安全性向上に関する提案

1239

へのアクセスに対応するために FD と LD はサンド

Guest OS

イッチ型になっている．
VMM

次に，DDA の役割を確認し，4 つの case に対して

DDA がどのように Decision を行うのかを述べる．

FD

表 1 ポリシーと FD，LD の動作
Table 1 Policy and Running of FD, LD

DD

Enforcement

アクセス拒否
Decision結果
PolicyDetection
FD

Query

DDA

Device

図 4 提案アーキテクチャの動作（outside）
Fig. 4 Running of Proposed Architecture(Outside)

セージを作成してする．DDA に Query を送信
する．

検出元
検出方法
執行先
case-1LD
Systemcall の監視
LD
case-2FD ／ LD
入力値の監視FD ／ LD
case-3FD ／ LD
メモリの監視FD ／ LD
case-4FD ／ LD
バッファの監視FD ／ LD
case-1 : 権限の取り扱い（Inside）
case-2 : 入力値の取り扱い（Inside と Outside）
case-3 : メモリの取り扱い（Inside と Outside）
case-4 : バッファの取り扱い（Inside と Outside）

5.4 Device Driver Auditor
DDA は，起動時から一貫して完全性を維持しなけ

Step3: DDA は FD から送信された Query を受信ればならない．また，ポリシーによる Decision につしセキュリティポリシーと比較，アクセス可否のいて行う重要なサブシステムである．そのため，自ら決定を下す（Decision）

を再起動し，自分自身の完全性をチェックする．そのStep4: DDA は Decision を FD に送信する

後，Device Driver，FD，LD の完全性をチェックす

Step5: FD は DDA から送信された Decision を基る．これら完全性のチェックについては SHA-1 またづいてセキュリティポリシーの執行を行う

は，MD5 を用いる．Device Driver の完全性チェックを定期的に行うことで FD，LD をバイパスされてし5.3 Fast Driver と Last Driver

まうことや，Device Driver を改変してしまうようなFD と LD の役割を確認し脆弱性によって，どのrootkit を検出が可能になると考えられる．

ように検出するかを述べる．提案アーキテクチャは，

また，DDA はリファレンスモニタであるため柔軟なLD,FD で検出した後に，DDA がアクセス可否の決定

ポリシー設定が求められる．それは，現在のポリシーを行い，LD または FD が MAC の執行を行う．これを破棄し，新しいポリシーを読み込み，執行を行うこらの執行は Inside，Outside によって異なるが脆弱性とである．

によっても異なる．脆弱性を case-1〜case-4 として検そして，DDA はアクセス可否の決定を行うサブシス

出元，検出方法，執行先と含めて Table1 に示す．

テムであり，Table1 と同様に脆弱性を case-1〜case-

Device Driver の脆弱性は，何らかのアクションが4 として DDA における Decision について Table2 になければ問題が起きないもの，Device が動作してい示す．DoS 攻撃以外の場合は，Device の停止をせずれば起きるものの 2 通りである．アクションによってに動作させるようにしている．これによって，Device

起きるものとして，システムを使うユーザが原因でDriver が脆弱性を持っていても安全に VMM を動作

起きる内部要因（case-1）とシステム外部からの外部させることが可能となる．また，Decision には優先順

要因と内部要因から起きる（case-2〜case-4）があり，位が存在する．最も優先度が高いのが権限の取り扱い

Device を動作させているだけで起きる問題が（case-

で，次がバッファの取り扱い，入力値，メモリの取り

2）ある．例えば，バッファオーバフロー対策として，扱いとなる．次節で実装について述べる．

OSS であることを前提として，ソースコードからバッ
ファサイズをシグネチャとして，登録しておき，バッ

6. 提案アーキテクチャの実装と評価

ファサイズを監視することが考えられる．しかし，こ

本節では，提案アーキテクチャの実装と評価方法に

れらの検出方法は，検出が可能であるという前提に基ついて述べる．本研究は，リファレンスモニタである

づいており，今後，検証する必要がある．

故に満たさなければならない要件が存在する．

また，割り込みハンドラの実行による Device Driver情報処理学会論文誌

1240
表 2 脆弱性と Decision
Table 2 Vulnerability and Decision

Decisioncase-1
管理者の設定に従ってアクセス制御
case-2
入力値のサニタイズ
case-3
定期的にメモリの初期化と開放
case-4
アクセス拒否
Device の停止（対 DoS）
case-1 : 権限の取り扱い（Inside）
case-2 : 入力値の取り扱い（Inside と Outside）
case-3 : メモリの取り扱い（Inside と Outside）
case-4 : バッファの取り扱い（Inside と Outside）

Apr. 2006

dom 0，dom U には 2.6 系の Linux Kernel を用いる．
Xen は dom 0 の Device Driver を用いるため Linuxの Device Driver に対して提案アーキテクチャを実装することになる．Xen を用いる利点は OSS であること，また，Xen のアーキテクチャによって DDA を保護できることが挙げられる．DDA を特権モードで動作する Xen 自体（Ring 0）に持たせることで，CPU のプロテクション機能が利用できる．それによって DDA
保証することが可能となる．Xen に対する提案アーキ
テクチャの実装を Fig.5 に示す．
一般的に Linux の Device Driver は，LKM として

6.1 リファレンスモニタの要件
実装は，以下に示すリファレンスモニタの用件を満たす必要がある．

• リファレンスモニタは全てのアクセス要求に対して必ず呼び出されること• リファレンスモニタのメカニズムは破壊や改ざんを受けないこと• リファレンスモニタが正しく動作することが保証されていること作成されるため，Device Driver に対して

function_fd_call();function_ld_call();というような関数を加えることで実装が可能であり，特に FD と LD は対になっているため共通するコードが使えるためリファレンスモニタを小さくすることが可能だと考えられる．しかしながら，この実装の仕方
では個々の Device Driver に対して FD と LD を作らなければならない．
ユーザアプリケーション

これらのリファレンスモニタの要件はリファレンス

Ring 3モニタの概念が初めて登場したアンダーソンレポー
Ring 2ト22) にて，リファレンスモニタの要件として書かれdom 0たものである．リファレンスモニタの要件のうち，最初の要件は Device Driver をサンドイッチ型にしたことで必ずリファレンスモニタがアクセス要求に対し

LD

dom U

dom U
Ring 1

BED

DD

FED

FED

FD
Xenbusて呼び出される．リファレンスモニタが改ざんされてRing 0いないことは，DDA の完全性を保証することであり

DDA

PolicyXen

Xen に実装することで，DDA を Ring 0 で動作させCPU のプロテクション機能で守ることができる．最後の項目であるリファレンスモニタが正しく動作することを保証するためにはコードの量が，出来る限り小NIC
Hardware

図 5 提案アーキテクチャの Xen への実装
Fig. 5 Implementation of proposed architecture by Xen

さいことであり実装による．

6.2 提案アーキテクチャの実装

6.3 FD，LD，DDA の通信におけるデータ構造第 5 節にて提案アーキテクチャの概要について述べ

FD，LD と DDA は通信を行う．提案アーキテクたが本節では実装にあたり，設計について述べる．提チャは単純な動作をするため最低限必要なデータ構造

案のリファレンスモニタはサンドイッチ型で Device

は Device のアイデンティティとハッシュ値だけでよ

Driver をリファレンスモニタで挟むことで全ての I/O

い．提案アーキテクチャは I/O 処理に対して MAC をアクセスに対して対応できる．現状ではプロトタイプ

執行するためパフォーマンスの低下は明らかであり，として 1 つの Device に対してのリファレンスモニタ

データ構造に別の項目を加えてパフォーマンスの低下として実装を行う．リモート攻撃で VMM の特権をを軽減できる可能性がある．

奪取できる可能性があるのが，NIC の Device Driver

6.4 評 価 方 法に対する攻撃あることを第 2 節で述べた．そこで提案

提案アーキテクチャは，実装してみなければパフォー

アーキテクチャを FD，LD 単体として NIC に対してマンスの低下にどれほど影響を与えるのか不明である．

実装を行う．また，VMM としては Xen3 系を用いてそのため，全ての機能を有効にして，もっとも負荷をVol. 47

No. 4

仮想マシンモニタにおけるデバイスドライバ安全性向上に関する提案

与える状況での評価を行う．また，脆弱性を持った De-

vice Driver を作成し，実際に攻撃を行い，有効性を証明する．

7. まとめと今後の課題
本稿では VMM における問題点を指摘し，その対策として Device Driver に対するリファレンスモニタ
を提案し，アーキテクチャを示した．しかしながら，

DDA に関して抽象的な部分が多い．今後の課題としては，Device Driver に対するリファレンスモニタによって攻撃検知が可能であることを示すとともに，パフォーマンスへの影響を調べ，対策の検討を行う．また，ポリシーを検討する必要がある．

参 考 文 献1) Xensource, “XenSource: Open Source Virtualization”.
http://www.xensource.com/
2) kvm-wikiKernel, “Based Virtual Machine”.
http://kvm.qumranet.com/kvmwiki
3) IBM Research, “sHype: Secure Hypervisor”.
http://www.research.ibm.com/secure systems department/projectsHypervisor/index.html, 2005.
4) 安藤類央, 門林雄基, “仮想マシンモニタ（XEN）
上のデバッグ機能の改良によるフォレンジックシ
ステムの構築”, Oct. CSS2006.
5) Tal Garﬁnkel, Ben Pfaﬀ, Jim Chow, Mendel
Rosenblum, Dan Boneh, “Terra: A Virtual
Machine-Based Platform for Trusted Computing”, ACM SIGOPS Operating Systems Review, Vol.37, No.5, pp.193-206, 2003.
6) Microsoft, “Next-Generation Secure Computing Base”
http://www.microsoft.com/resources/ngscb/default.mspx7) 藤澤 一樹, 橋本 正樹, 宮本 久仁男, 金 美羅, 辻
秀典, 田中 英彦, “仮想マシンモニタにおけるデバ
イスドライバ安全性向上に関する提案”, FIT2007
第 6 回情報科学技術フォーラム Sep. 2007.
8) Dawson Engler, David Yu Chen, Seth Hallem,
Andy Chou, Benjamin Chelf, “Bugs as deviant
behavior: a general approach to inferring errors
in systems code”, In Proceedings of the Eighteenth ACM Symposium on Operating Systems
Principles, 2001.
9) Thomas Ball, Ella Bounimova, Byron Cook,
Vladimir Levin, Jakob Lichtenberg, Con McGarvey, Bohus Ondrusek, Sriram K. Rajamani,
Abdullah Ustuner, “Thorough static analysis

1241

of device drivers”, In Proceedings of the 2006
Eurosys Conference.
10) Christopher L. Conway, Stephen A. Edwards,“NDL: A Domain-Speciﬁc Language for Device Drivers”, In Proceedings of Languages,
Compilers, and Tools for Embedded Systems(LCTES), June, 2004.
11) Microsoft, “ロゴ及び WHQL テスト”.
http://www.microsoft.com/japan/whdc/GetStart/default.mspx12) Microsoft “Windows Driver Foundation”.
http://www.microsoft.com/japan/whdc/driver/wdf/default.mspx
13) Keir Fraser, Steven Hand, Rolf Neugebauer,
Ian Pratt, Andrew Warﬁeld, Mark Williamson,“Safe Hardware Access with the Xen Virtual Machine Monitor”, OASIS ASPLOS 2004
workshop.
14) Joshua LeVasseur, Volkmar Uhlig, Jan Stoess,Stefan Götz, “Unmodiﬁed Device Driver Reuse
and Improved System Dependability via Virtual Machines”, Proceedings of the 6th Symposium on Operating Systems Design and Implementation, Dec, 2004.
15) Swift, M. M., Bershad, B. N., and Levy, H. M.,“Improving the reliability of commodity operating systems”, In Proceedings of the Nineteenth ACM Symposium on Operating Systems
Principles (Bolton Landing, NY, USA, October
19 - 22, 2003). SOSP ’03.
16) Michael Swift, Muthukaruppan Annamalai,
Brian N. Bershad, and Henry M. Levy, “Recovering Device Drivers” ACM Trans. on Computer Systems 24(4), November 2006.
17) 加藤和彦, “セキュア VM プロジェクトの概要”,
第 1 回セキュア VM シンポジウム, Mar. 2007.
18) Stephen D. Smalley, “NSA SecurityEnhanced
Linux”, Ottawa Linux Symposium BOF 2006.
19) Ray Spencer, Peter Loscocco, Stephen Smalley, Mike Hibler, David Anderson, and Jay Lepreau, “The Flask Security Architecture: System
Support for Diverse Security Policies”, In Proceedings of the 8th conference on USENIX Security Symposium, pp.123-139, August 1999.
R Virtualization Technology for20) Intel, “Intel⃝
Directed I/O Architecture Speciﬁcation”, 2006.
21) AMD, “AMD64 Technology AMD64 Architecture Programmer s Manual Volume 2: System Programming”, 2006.
22) James P. Anderson, “COMPUTER SECURITY TECHNOLOGY PLANNING STUDY”,
1972.