ハードウェア障害に対するハイパーバイザの対故障性検証

全文

(1)Vol.2018-OS-143 No.6 2018/5/21. 情報処理学会研究報告 IPSJ SIG Technical Report. ハードウェア障害に対するハイパーバイザの対故障性検証荻野将拓1. 味曽野雅史1,a). 深井貴明2. 品川高廣1. 概要：本稿ではハイパーバイザのデバイスドライバがハードウェア障害に対して適切なエラーハンドリングを実施しているかを検査する手法を提案する．提案手法ではネステッド仮想化を用いて検査対象のハイパーバイザを動作させ，ハイパーバイザのデバイスドライバによるデバイスレジスタ読み込み要求をトラップする．そして，この際に擬似的なエラーを挿入し，適切なエラーハンドリングが実行されるかどうかを観察する．ネステッド仮想化のオーバヘッドの削減のために検査対象以外のデバイスはパススルーとし，検査に不要な EPT シャドウイングなどの処理は省略する．これにより現実に近い環境下で，ソースコードが非公開の場合であってもハイパーバイザのデバイスドライバの検査が可能となる．提案手法の評価として VMWare ESXi 上の 2 つのデバイスドライバに対して検査をおこなったところ，デバイスドライバの不適切なハンドリングが原因と考えられるエラーを 3 種類発見した．. 1. はじめに今日，多くの場面でハイパーバイザによる仮想化が利用されている．特にクラウドサービスでは数万台を超える大規模なサーバ群をハイパーバイザを用いて運用している．. while(ioread(STATUS_REGISTER) & 0x8000); 図 1. 問題のあるコード例. るまでビジーウェイトするプログラムである．このとき，このステータスレジスタの当該ビットが故障. そうした環境では仮に一つのデバイスの故障確率が低くて. により 1 にならなければ，このデバイスドライバは永遠に. も，全体としてデバイスが故障する可能性は高くなる．一. ハングアップすることになる．このようなコードは実際に. 例として，クラウドストレージサービス会社の BackBlaze. Linux のデバイスドライバに存在するものである [2], [3]．. は 2013 年から 2017 年の 4 年間の間に 116,833 台の HDD. デバイスドライバ開発時においてデバイスのエラーの発. を運用し，そのうちの 5%弱である 6,795 台の HDD に障害. 生は稀有な事象であるため，このようなコーディングエラー. が発生したことを報告している [1]．ハードウェアエラー. の検知は容易ではない．効率的にデバイスドライバを検証. が生じた際にハイパーバイザは適切にエラーハンドリング. するために，いくつかの手法が提案されている．代表的な. を実施することがシステムの信頼性向上のために重要であ. 手法の一つが静的コード解析 [2], [4], [5], [6], [7], [8] である．. る．ハイパーバイザが適切にエラーハンドリングできない. また，シンボリック実行により，デバイスドライバが不正な. 場合，最悪ハイパーバイザがクラッシュし，その上で動作. 状態になる条件を検出する方法もある [9], [10], [11], [12]．. する全ての VM が影響を受ける．そういう意味ではハイ. これらの手法はテスト対象となるコード網羅率が高い一方. パーバイザのデバイスドライバのエラーは通常の OS デバ. で，一般に実行可能パスの探索に時間がかかり，さらには. イスドライバのエラーよりも影響範囲は大きいといえる．. 検出結果が偽陽性の場合も多いという問題がある．. デバイスのエラー要因は様々である．摩耗や経年劣化に. 別のアプローチとして，擬似的なエラーを挿入する. よる恒久的な故障の他に，電磁的干渉や熱が原因で一時的. Software Fault Injection (SFI) を利用した検査手法があ. な信号エラーを生じている場合もある．一方で，デバイス. る [3], [13], [14], [15], [16], [17], [18], [19], [20], [21]．これ. ドライバはデバイスが仕様通りに正しく動作することを想. らの手法では主に関数の戻り値を書き換えることでエラー. 定して書かれていることがある [2], [3]. 例えば，図 1 は. を挿入し，デバイスドライバの挙動を観察する．SFI の対. ハードウェアのステータスレジスタのあるビットが 1 にな. 象はデバイスのレジスタアクセスのみならず，OS 内の様々. 1. 2. a). 東京大学 The University of Tokyo 筑波大学 University of Tsukuba [email protected]. c 2018 Information Processing Society of Japan ⃝. なインタフェース（リソースの確保・解放など）を対象にすることもある．. FaultVisor [3] は，検査対象となるデバイスのレジスタアクセスのみを仮想化し，そのレジスタにアクセスした際に. 1.

(2) Vol.2018-OS-143 No.6 2018/5/21. 情報処理学会研究報告 IPSJ SIG Technical Report. 異なるレジスタ値を返すことで Fault Injection をおこなう方法を提案している．この方法はデバイスのハードウェア. 2.1 静的コード解析静的コード解析は，実際にコードを実行せずに，ソース. エラーの対処に検査対象を絞っているが，OS に非依存で，. コードを解析することでデバイスドライバを検査する手法. クローズドなソースのデバイスドライバに対しても検査が. である． [4], [5], [6], [7], [8] は定理証明やモデル検査手法. 実行可能である．さらに，実環境に近い状態でデバイスド. を活用した検査を実施している．Carburizer [2] は Linux. ライバの検査ができるという利点がある．一方で，仮想化. のソースコードを解析し，デバイスドライバが暗にデバイ. を利用しているためそのままでは Type 1 型のハイパーバ. スが正常に動作することを仮定しているコードを発見し，. イザのデバイスドライバの検査に利用することはできない．. 自動的にその一部を修正するシステムである．. 本稿では FaultVisor がおこなっていた擬似エラー挿入手法をハイパーバイザのデバイスドライバに対して適用す. 静的コード解析は実環境での動作を確認しているわけではないため，検出結果が偽陽性であることもある．. る．ハイパーバイザのデバイスドライバに対してエラーを挿入するために，ネステッド仮想化 [22] を利用して検査対. 2.2 シンボリック実行. 象のハイパーバイザを検査用のハイパーバイザ上で実行す. シンボリック実行は，プログラムが実行可能なパスを網. る．これにより，ハイパーバイザのデバイスドライバによ. 羅的に探索する手法である．[9], [10], [11], [12] はいずれ. る実デバイスのアクセスがフック可能となる．ネステッド. もシンボリック実行を利用することで，実ハードウェア. 仮想化のオーバヘッドを抑えるために，デバイスドライバ. 無しにデバイスドライバを検査する手法を提案している．. 検査に不要な処理は省略する．. DDT [9] は部分的にシンボリック実行を実施する選択的シ. 実験として，VMWare ESXi ハイパーバイザ [23] のネッ. ンボリック実行により，リソースリークや競合状態，ヌル. トワークデバイスドライバ（ixgbe）及びストレージデバイ. ポインタ参照などを検出する．SymDrive [10] は静的コー. スドライバ（iomemory-vsl）の二つのデバイスドライバに. ド解析とシンボリック実行を組み合わせ，事前のコード分. 関して提案手法を用いて検査をおこなった．その結果スト. 析によりシンボリック実行を効率化するシステムを提案し. レージデバイスドライバに関して不適切なエラーハンドリ. ている．. ングが原因とみられる 3 種類のエラーを検知した．また，. シンボリック実行はコード網羅率が高い一方，実行可能. オーバヘッドの評価結果より，本手法が実環境に近い状態. パスの探索に時間がかかり，効率的なパス探索のためには. でデバイスドライバの検査ができることを確認した．. プログラマの労力が必要である．また，検査は仮想的な環. 本論文の貢献は以下の通りである．. 境で実行するため，実環境での副作用を含む様々な挙動を. • ネステッド仮想化を用いてハイパーバイザのデバイス. 正確に再現することはできない．静的コード解析と同様に. ドライバに対して Fault Injection を実施するシステム. 偽陽性の問題も存在する．. を提案し，実装した．. • 実際に提案システムを広く用いられているハイパーバ. 2.3 Software Fault Injection. イザに適用し，提案手法によりハードウェアエラーに. Software Fault Injection (SFI) はソフトウェア的に擬似. 対するデバイスドライバの対応が検査できることを示. 的なエラーを挿入することでソフトウェアの動作を検証す. した．. る方法である．SFI をデバイスドライバの検査に利用した手. 以降，2 章でまずデバイスドライバの検査に関する関連研. 法としては [3], [13], [14], [15], [16], [17], [18], [19], [20], [21]. 究について述べる．3 章で提案手法の設計を，4 章で具体. がある．これらの手法では主に関数の戻り値に対してエ. 的な実装について述べたあと，5 章に提案手法の評価結果. ラーを挿入しデバイスドライバの挙動を観察する．SFI に. を示す．6 章で提案手法の有効性について議論し，7 章を. よるデバイスドライバ検査の最新手法の一つである EH-. 本論文の結論とする．. Test [21] はデバイスドライバのエラーハンドリングコード. 2. 関連研究デバイスドライバは主にサードパーティの開発者によっ. を対象に，テストケースを自動生成してリソースリークなどの検知をおこなう．一方で，ハードウェアエラーに関する検証はおこなっていない．. て書かれ，その特性上エラー検査が難しいため，効率的な. デバイスのハードウェアエラーに関して Fault Injection. 検査のために様々な研究がおこなわれている．検査の対象. をおこなうものに，FaultVisor [3] がある．FaultVisor は. はハードウェアエラーに対する対応の他に，適切な API の. 一種のハイパーバイザであり，検査対象のデバイスドライ. 使用やリソース解放の確認などがあり，手法により検査の. バを有する OS をゲストとして動作させる．FaultVisor は. 対象も異なる．. 検査対象のデバイスドライバによるデバイスからの値の読み込みを捕捉し，実際とは異なる値を返すことで Fault. Injection を実施する．FaultVisor はデバイスのみを仮想化. c 2018 Information Processing Society of Japan ⃝. 2.

(3) Vol.2018-OS-143 No.6 2018/5/21. 情報処理学会研究報告 IPSJ SIG Technical Report 1. O. F. O. L 1. 1. O. 1. SO. :. S. V. S S F1. /. 1 1. O 1 2. 0/. 図 2 FaultVisor の構成 1. し，それ以外はパススルーすることで仮想化のオーバヘッドを抑え実環境に近い状況でのドライバの検査を実現する．デバイスドライバがアクセスしてきた部分に対して Fault. 図 3 提案システム構成. Injection をおこなうため，他手法のように偽陽性が生じることもない．FaultVisor の検査結果から分かるのはどのデ. に問題があると判定する．. バイスのレジスタ読み込みにエラーが発生した場合に，デ. どのレジスタを改変するかどうかの決定を補助するため. バイスドライバのハンドリングが不適切であるかというこ. に，FaultVisor には monitor モードと呼ばれるモードが存. とであり，具体的なエラー箇所の特定及び修正はプログラ. 在する．monitor モードで FaultVisor を動作させた場合，. マがおこなうことになる．. Fault Injection をせず，代わりにデバイスドライバがアク. FaultVisor は仮想化を用いているため，そのままでは. セスしたレジスタを記録する．これを利用することで，デ. Type 1 型のハイパーバイザに適用することはできない．本. バイスドライバのソースコードを解析することなく通常時. 稿ではハードウェア障害に対するハイパーバイザの対故障. に使用されるデバイスのレジスタを調査することができる．. 性を検証するために，この FaultVisor をハイパーバイザの. 仮想化のオーバヘッドを減らすため，FaultVisor は準パ. デバイスドライバに適用できるように拡張する．. 3. 設計. ススルー型ハイパーバイザ [24] を利用する．これにより，検査対象のデバイスのみを仮想化し，それ以外をパススルーさせることで実環境に近い状況での検査を実現する．. 本稿では，ハードウェア故障に対するハイパーバイザの対故障性を検証するために，FaultVisor を Type 1 型ハイ. 3.2 提案システムの構成. パーバイザに適用できるように拡張をおこなう．本章では. 図 3 に，本提案手法のシステム構成を示す．本論文では. まず FaultVisor の構成について説明したのち，提案システ. 一番最下層にあるハイパーバイザ (拡張された FaultVisor). ムの構成について述べる．. を L0，ネステッド状態で起動する検査対象のハイパーバイザを L1，L1 上で動作するゲスト OS を L2 と表記する．. 3.1 FaultVisor の構成図 2 に FaultVisor の構成を示す．検査対象となるデバ. 提案システムではネステッド仮想化 [22] を用いて検査対象のハイパーバイザを動作させる．ネステッド仮想化を用. イスドライバを有する OS を FaultVisor 上で動作させる．. いることで，L0 から L1 のデバイスのアクセスを補足する. FaultVisor はゲストのデバイスドライバによるデバイスの. ことが可能となる．図に示したように，L2 のアプリケー. アクセスを捕捉し，それがデバイスからの読み込みであ. ションからは検査対象となるデバイスは直接は見えず，仮. る場合に異なる値を返すことで Fault Injection をおこな. 想化されたデバイス（仮想デバイス）が見えている．L2 が. う．FaultVisor がどのデバイスのアクセスに対して Fault. 仮想デバイスにアクセスすると，L1 に制御が移り，L1 が. Injection するかは，ゲスト OS のユーザランド上で動作す. 仮想デバイスの処理をおこなう．この結果として実デバイ. るコントローラが指示をする．値の改変を設定した後，コ. スへのアクセスが発生する．FaultVisor はこのアクセスを. ントローラはワークロードを実行する．ワークロードには. 捕捉し，Fault Injection をおこなう．FaultVisor のコント. デバイスを利用するアプリケーションの実行やデバイスド. ローラは L2 のゲスト OS 上で動作させる．コントローラ. ライバのロード・アンロードなどがある．この際にカーネ. は検査対象の実デバイスに Fault Injection が実施されるよ. ルがクラッシュ（カーネルパニックなど）やハングアップ. うに，適切な L2 アプリケーションを選択して実行する．. （一定時間応答がない）した場合デバイスドライバの処理. また，ハイパーバイザによっては動的なデバイスドライバ. c 2018 Information Processing Society of Japan ⃝. 3.

(4) Vol.2018-OS-143 No.6 2018/5/21. 情報処理学会研究報告 IPSJ SIG Technical Report. のロード・アンロードに対応しているものもある．この場合 L2 のコントローラから L1 の管理ツールを使用してドライバのロード・アンロードをおこなうことで，その部分のデバイスドライバの検証をおこなうことができる．このよ. 0 1. 0. 2 0 1. 0. 2. うな構成にすることで，ハイパーバイザやハイパーバイザ. -. 1). 0. -. のデバイスドライバがクローズドソースな場合であっても. Fault Injection による検査が実行できる．. (. 0. 3.3 検査の流れ. 図 4. L1 から L2 への VMENTRY の流れ. 検査の基本的な流れは FaultVisor と同様である．まず. FaultVisor を monitor モードで動作させ，検査対象となる. non-root モードへ移行する．VMX non-root モードにおい. レジスタを調査する．その後コントローラは FaultVisor に. て予め決められているセンシティブな命令（in/out 命令な. どの実デバイスのアクセスに対して Fault Injection を実施. どの特権命令）を実行した際や，VMCS で設定した事項が. するかを L0 の FaultVisior に通知したのち，ワークロード. 発生した場合は，VMEXIT により VMX root モードへ移. として適当なアプリケーションを実行してデバイスドライ. 行する．またゲストがメモリアクセスする際，ゲストの仮. バのテストをおこなう．アプリケーションは例えば，ネッ. 想アドレスはゲストが設定したページテーブル基づきゲス. トワークデバイスの場合は外部への ping を実施する．一度. トの物理アドレスに変換された後，EPT (Extended Page. に複数のレジスタに対して改変をおこなうと，エラーが発. Table) によりそれがさらにホストの物理アドレスへと変換. 生した際にどのレジスタアクセスが原因かを特定すること. される．EPT の設定は VMCS の設定に含まれている．. が困難であるため，レジスタへの改変は一つずつおこなう．. ネステッド仮想化の処理の例として，L1 から L2 へ. VMENTRY する際の処理の流れを説明する．ネステッド 3.4 エラーの検出. 仮想化をおこなう際，L1 のハイパーバイザは VMX non-root. デバイスドライバにエラーが発生したかどうかはハイ. モードで動作している．そして L1 が L2 へ VMENTRY し. パーバイザがクラッシュするか，あるいはハングアップす. ようとすると，これはセンシティブな命令であるため実際. るかで判定をおこなう．. には VMEXIT が発生し，制御は L0 のハイパーバイザへ. 4. 実装実装は FaultVisor [3] をネステッド仮想化対応させることでおこなった．FaultVisor は BitVisor [24] がベースとなっている．FaultVisor (BitVisor) は Intel 及び AMD CPU に. 移行する．L0 のハイパーバイザは VMCS のゲスト状態が. L1 ではなく L2 の状態を表すものに切り替え，VMENTRY をおこなう．これにより，VMENTRY 後は L2 の処理が再開される．図 4 にこの処理を示す．. L2 が VMEXIT する際も，最初は L0 へと制御が移る．. 対応しているが，今回は Intel CPU を対象に FaultVisor の. L0 は必要に応じて VMCS をゲストの状態が L2 から L1 の. ネステッド対応の実装をおこなった．. ものに切り替え，L1 へ VMENTRY をする．このとき L1 から見ると L2 から直接 VMEXIT してきたのと同じ状態. 4.1 ネステッド仮想化の概要. となっており，L1 はそれに応じた処理を実行する．なお，. Intel CPU の仮想化支援機構 VT はネイティブなネス. ホスト状態が L0，ゲスト状態が L2 の VMCS は L1 が L1. テッド仮想化は完全にはサポートしていない．そこで，L1. のホスト状態と L2 のゲスト状態を含む VMCS を作成し. が実行する VMX 命令（仮想化命令）を L0 がトラップし，. VMPTRLD 命令でそれを CPU に設定しようとした際に. 適切なエミュレーション処理をおこなうことでネステッド. その命令が（センシティブ命令であるため）トラップされ. 仮想化を実現する [22]．. L0 に制御が移るので，そのタイミングで作成する．. VT にはハイパーバイザを動作させる VMX root モード及びゲスト OS を動作させる VMX non-root モードが存. 4.2 Fault Injection の方法. 在する．VT では VMCS と呼ばれるデータ構造でホスト. Fault Injection の方法は元の FaultVisor のものを利用. （ハイパーバイザ）とゲストの状態を管理する．VMCS の. する．デバイスドライバがデバイスにアクセスする方法. ゲスト状態にはゲスト OS 実行中に用いる CPU レジスタ. は，PIO を使用する場合と MMIO を使用する場合の 2 種. 等の情報が，ホストの状態には VMX non-root モードか. 類がある．PIO でアクセスする場合，デバイスドライバは. ら VMX root モードに切り替わる際に設定される CPU レ. in/out 命令を利用する．in/out 命令はセンシティブ命令で. ジスタ等の情報が格納されている．VMX root モード状態. あるため，自動的に VMEXIT が発生する．MMIO のアク. で VMCS を適切に設定し，VMENTRY することで VMX. セスを捕捉するには，MMIO 領域に関する EPT の読み込. c 2018 Information Processing Society of Japan ⃝. 4.

(5) Vol.2018-OS-143 No.6 2018/5/21. 情報処理学会研究報告 IPSJ SIG Technical Report. みパーミッションを無効化する．これによりこの MMIO. アクセスは全てパススルーさせる．また，L1 には EPT も. 領域にアクセスした際に EPT Violation による VMEXIT. パススルーさせる．すなわち，L1 が EPT を設定する際. が発生するようになる．なお，値の改変をおこなうのはレ. は，L1 の物理アドレスが EPT のホスト物理アドレスとし. ジスタ読み込みのみである．. てそのまま登録される．いわゆる EPT のシャドウイング. FaultVisor で値を改変する方法には，予め決めた値に値. はおこなわない．もともと FaultVisor (BitVisor) は基本的. を改変する “fixed” および，xor のマスク演算を適用する. に EPT をストレートマッピングさせ，フックしたい部分. “xormask” がある．検査の際はコントローラは FaultVi-. のみ EPT のアクセスパーミッションを無効化する．した. sor に対し，Fault Injection したいレジスタ番号ならびに. がって，L1 の物理アドレスは実際には L0 の物理アドレス. “fixed” と “‘xormask” いずれを改変に使用するかと，改変. にそのまま対応しているため，このような処理が可能とな. に使用する改変パラメータ（“fixed” で設定される値あるい. る．これにより極力ネステッド仮想化のオーバヘッドを削. は “xormask” でマスクとして利用される値）を設定する．. 減させる．. 4.3 コントローラから FaultVisor への指示の送信. 制約が存在する．. 一方でこのようなネステッド仮想化には，以下のような. L2 で動作させるコントローラから FaultVisor への指示. ( 1 ) 複数のハイパーバイザを動作させることができない. 通信は，VMX non-root モードから root モードへ明示的に. ( 2 ) L2 が L0 のメモリ領域にアクセスできる. 制御を移す VMCALL 命令を用いておこなう．VMCALL. ( 3 ) L1 がデバイスをパススルーした際にそのデバイスを. を L2 で実行すると，VMEXIT が発生し L0 へ制御が戻る．. 捕捉できない. この際にレジスタ経由で引数を渡すことができる．通常の. しかしながら，以下で説明するようにハイパーバイザの. ネステッド仮想化の実装では L2 の VMCALL は L1 側へ. デバイスドライバの検査にはこれらの制約は問題とならな. 伝えるが，今回は L2 の VMCALL は全て L0 側で処理し，. い．まず (1) に関して，ハイパーバイザのデバイスドライ. L1 へ遷移することなしに L2 へ再び戻るようにした．. バ検査のためには複数のハイパーバイザを動作させる必要がない．(2) に関しては，L1 には BIOS の e820 を偽装して. 4.4 検査処理の流れ. L0 のハイパーバイザのメモリ領域は予約済み領域として. 具体的に，L2 から仮想デバイスを経由して L1 が実デバ. 通知している．一方で，EPT をパススルーしているため，. イスにアクセスする際に Fault Injection を実施する場合，. EPT で L0 の領域を指すことで，L2 から L0 の領域へのア. 以下のような流れとなる．. クセスが可能である．しかしこのような場合の対処は今回. ( 1 ) L2 のアプリケーションが L2 のカーネル内のデバイス. の想定外である．また (3) に関しても，L1 が全てのデバイ. ドライバ経由で仮想デバイスにアクセスする．. ( 2 ) その結果 VMEXIT. が発生する*1 ．L0. スをパススルーして L2 に VMENTRY すると，VMEXIT. から L1 へ. が発生しないためそのデバイスに対するアクセスが捕捉で. VMENTRY する．L1 は仮想デバイスの処理をおこ. きないが，今回のデバイスドライバの検査にはパススルー. ない，L1 から実デバイスへのアクセスが発生する．. デバイスは対象外であるため問題ない．. ( 3 ) EPT Violation により VMEXIT が発生し，L0 に制御が移る．L0 が当該 MMIO レジスタの値を改変し L1 へ伝える（VMENTRY）.. ( 4 ) L1 が MMIO レジスタの値を適当に処理し，L2 へ VMENTRY しようとする． ( 5 ) L0 を一旦経由して VMENTRY で L2 へ処理が移るここで，提案手法では (4) の部分で Fault Injection した際に適切なエラーハンドリングが実施されるかを，システ. 5. 実験今回実験として，VMWare ESXi 6.5.0 [23] (VMKernel. Release Build 4887370) を対象に提案手法を用いてそのデバイスドライバの一部の検査を実施した．表 1 に今回実験に用いた器具を，表 2 に検査対象のデバイス及びデバイスドライバを示す．Intel X540-T2 は 10GbE のネットワークカード，Fusion IO は PCIe 接続の SSD である．. ムがクラッシュあるいはハングアップするかどうかで判定する．. 4.5 ネステッド仮想化のオーバヘッド削減のための工夫と制約. ハードウェア. 表 1 使用器具モデル. マザーボード. ASRock Z170 Extreme4. CPU. Intel Core i7-6700. RAM. DDR4 2133MHz 8GB × 2. 今回は検査対象のデバイスのみを仮想化し，それ以外の. VMWare ESXi では管理ツールを用いて動的にデバイス *1. L1 は仮想デバイスのアクセスを捕捉して処理するため，L2 が仮想デバイスのレジスタにアクセスした際 VMEXIT が発生するように VMCS を適切に設定している．. c 2018 Information Processing Society of Japan ⃝. ドライバをロード・アンロードすることができる．VMWare 上で動かすゲスト OS には Ubuntu 16.04 を利用した．ま. 5.

(6) Vol.2018-OS-143 No.6 2018/5/21. 情報処理学会研究報告 IPSJ SIG Technical Report 表 2 検査対象デバイスデバイスデバイスドライバ. Intel X540-T2. ixgbe. Fusion IO Drive2. iomemory-vsl. モジュールのロード・アンロードに関するワークロードは以下の様なものとした．. ( 1 ) デバイスドライバをロードする ( 2 ) IO Drive2 の接続を有効にする ( 3 ) VMWare ESXi のファイルシステムにストレージをマ. た，コントローラは Python を用いて作成した．. ウントする. ( 4 ) VMWare ESXi のファイルシステムからストレージを 5.1 実験手順各デバイスと対応するデバイスドライバに対し，以下の手順で実験を実施した．実行するワークロードの詳細は次節で説明する．. アンマウントする. ( 5 ) IO Drive2 の接続を解除する ( 6 ) デバイスドライバをアンロードするまた，データの送受信に関するワークロードとして以. ( 1 ) monitor モードでワークロードを実行し，レジスタア. 下を実施した．なお，前準備として予め検査対象のハイ. クセスを記録する．記録されたレジスタが改変対象レ. パーバイザから IO Drive2 上に仮想 HDD を作成し，その. ジスタとなる. 上にパーティションを作成し，4MB のファイルを保存し. ( 2 ) 改変対象レジスタ 1 つずつに対して以下の (3) から (6). ている．. を fixed モード及び xormask モードについてそれぞれ. ( 1 ) ゲスト OS に仮想 HDD をマウントする. 3 回ずつ実施する. ( 2 ) 仮想 HDD 上から 4MB のファイルを読み込む. ( 3 ) 対象のレジスタに対して改変パラメータを乱数で決定し，FaultVisor に送信して入力値の改変を開始する. ( 3 ) 仮想 HDD に対して 4MB のファイルを書き込む ( 4 ) ゲスト OS から仮想 HDD をアンマウントする. ( 4 ) ワークロードを実行する ( 5 ) FaultVisor による改変を終了する. 5.3 実験結果. ( 6 ) エラーを検出した場合，マシンを再起動して次のレジ. 5.3.1 monitor モードの結果. スタから検査を開始する. 表 3 に monitor モードにより記録されたデバイスドライバごとのレジスタのアクセス数を示す．. 5.2 ワークロードできるだけ多くのレジスタにアクセスするようにワークロードを定めることで，検査のカバレッジを広くすることができる．また，実際の使われ方に近いワークロードを用いることで，実際に使うときに起こりうるエラーを発見す. 表 3 monitor モードの結果デバイスドライバ検出したレジスタ数. ixgbe iomemory-vsl (ロード・アンロード) iomemory-vsl (データ送受信). 1114 262 3. ることができる．これらを踏まえつつ，今回は以下のワークロードを実行した．. 5.2.1 ネットワークデバイスに対するワークロードネットワークドライバ ixgbe の検査には以下のワークロードを用いた．. ( 1 ) デバイスドライバをロードする ( 2 ) インタフェースをリンクアップし，IP アドレスを割り当てる. ( 3 ) 同一 LAN 上のサーバに対し，3 秒間 netperf [25] でデータの送受信をする．. ( 4 ) デバイスドライバをアンロードする 5.2.2 ストレージデバイスに対するワークロードストレージドライバ iomemory-vsl の検査において，ゲ. 5.4 発見したエラー monitor モードでの結果を元に，Fault Injection によるデバイスドライバの検査をおこなった．表 4 にテストにより引き起こされたエラー（クラッシュやハングアップ）数を示す．なお，ixgbe に関しては検査時間を短縮するため，. 1114 中 602 個のレジスタに対して検査を実施した．除外対象のレジスタは配列やそれに類するデータ構造において同じ役割を持つ複数のレジスタ群の中から，適切だと考えられるものを選択した．. スト OS がストレージを利用している間はハイパーバイザ. 表 4 改変によって引き起こされたエラーの種類の数エラーの種類の数デバイスドライバ. からそのデバイスを取り除くことができず，デバイスドラ. ixgbe. 0. イバをアンロードできないという問題があった．そこで，. iomemory-vsl (ロード・アンロード). 3. iomemory-vsl の検査ではワークロードをデバイスドライバ. iomemory-vsl (データ送受信). 0. のモジュールのロード・アンロードに関するワークロードとデータの送受信に関するワークロードに分けて実施した．. c 2018 Information Processing Society of Japan ⃝. 今回 iomemory-vsl について，3 種類のエラーを確認し. 6.

(7) Vol.2018-OS-143 No.6 2018/5/21. 情報処理学会研究報告 IPSJ SIG Technical Report. た．表 5 に，エラーが発生した改変対象のレジスタと，引き起こされたエラーについて示す．なお，同じ改変パターンでもエラーの再現性がない場合がある．これは割り込みのタイミングやその他外的要因が原因だと考えられる．今回エラーの再現性が取れなかったものについては除外した．. 表 6 それぞれのワークロードで検査にかかった時間デバイスドライバ時間. ixgbe. 13h55m. iomemory-vsl (ロード・アンロード). 10h16m. i0memory-vsl (データ送受信). 2m56s. 表 5 iomemory-vsl において改変対象としたレジスタと引き起こさ. イパーバイザをハードウェア上で直接動かした場合と，提. れたエラー．無印のものは同じ改変パターンで常に再現性の. 案手法を用いてネステッド状態でハイパーバイザを動作さ. あったもの，*印のついたものは常にではないが複数回再現が. せた場合とで性能比較をおこなった．提案手法を用いる場. 確認されたものを表す．改変対象としたレジスタ (BAR 番号:. 引き起こされたエラー. 合，xormask モードで改変パラメータを 0 にすることで，入力値のフックはするが値は改変しないようにした．実験. オフセット). 5:8500, 5:9100, 5:9238*, 5:9264. TIMEOUT. 5:80d8*, 5:9020*, 5:9240*. no heartbeat. 5:80d8*, 5:9104*. VMKernel Exception. は 10 回実施し，その平均を求めた．ネットワークデバイスに関しては，netperf で 3 秒間スループットを測定した．ストレージデバイスに関しては，データ送受信のワークロードを実行し，その実行時間を計. それぞれのエラーの詳細状況を以下に示す．. 測した．図 5 に，提案手法を利用した場合における，提案. TIMEOUT デバイスドライバのロード処理が一定時間. 手法を利用しない場合との相対値を示す．network がネッ. 経過して終了しなかった．そのワークロードプロセス. トワークデバイス，storage がストレージデバイスに関す. を強制終了すると，それ以降デバイスドライバが対象. る結果である．図より，オーバヘッド測定に用いたワーク. の仮想 HDD を認識しなくなった．加えて，デバイス. ロードでは提案手法によるオーバヘッドはほぼ無く，実環. ドライバの状態は依然使用中のままで，アンロードで. 境に近い状況であることが分かる．. no heartbeat 仮想 CPU が一定時間応答しないことが原因で，VMWare ESXi のカーネルパニックが発生した．デバイスドライバのロード中に発生した．. VMKernel Exception VMWare ESXi のカーネルによる例外処理が発生した．例外の種類としては GP Ex-. ception（一般保護違反）と PF Exception（ページ違反）が確認された．GP Exception は，メモリアクセスにおいて要求されたアドレスのページがそのプログラムに属していない際，あるいはページへの書き込み/読. Relative value against no nested virtualization. きない状態になった．. 1.0 0.8 0.6 0.4 0.2 0.0. み取りの権限がそのプログラムに無い際に発生するエラーである．また，PF Exception は要求されたペー. 1.01. 1.00. network. Workload. storage. 図 5 提案手法を利用した場合の測定結果の相対値. ジがメモリに正常にロードされなかった際に発生するエラーである．このエラーもデバイスドライバのロード中に発生した．. no heartbeat 及び VMKernel Exception が発生した場合. 6. 考察 6.1 提案手法の適用範囲. は，VMWare ESXi のデバッグモードよりスタックトレー. 本手法は基本的にハイパーバイザには依存しない．コン. スが取得できる．iofusion-vsl のドライバはクローズドソー. トローラを L2 で動作させることで，クローズドソースなハ. スであるため，今回は具体的な原因の特定までは至らな. イパーバイザに対しても検査をおこなうことができる．さ. かったが，スタックトレースの情報や，改変したレジスタ. らに monitor モードを利用することで，デバイスのレジス. の情報が問題発生箇所特定に役立つと考えられる．. タ情報が無い場合でも検査が可能である．ハイパーバイザが共通の L2 の動作に対応していれば，検査のためのワー. 5.5 検査時間表 6 にそれぞれのワークロードで検査にかかった時間を以下に示す．. クロード処理などを共有することができる．提案手法を適用する際の注意点として，検査するレジスタに漏れが生じないように，実行するワークロードを適切に選択する必要がある．また L1 がデバイスドライバの. 5.6 オーバーヘッドの測定提案手法のオーバヘッドを測定するため，検査対象のハ. c 2018 Information Processing Society of Japan ⃝. ロード・アンロードを管理ツールを通じて提供している場合，それを利用することでその部分のデバイスドライバの. 7.

(8) Vol.2018-OS-143 No.6 2018/5/21. 情報処理学会研究報告 IPSJ SIG Technical Report. 検査ができる．ただしこの処理はハイパーバイザごとに作成する必要がある．. [2] [3]. 6.2 提案手法の効率性本手法では検査対象のレジスタ 1 つ 1 つに対してテストをおこなう．したがって検査にかかる時間は検査対象レジスタ数に比例する．一方で，異なるレジスタのアクセスであっても，プログラムのコードパス的には同一の処理が実行される可能性もある．今回検査にはドライバのソース. [4] [5] [6]. コードは一切用いていないが，ソースコード情報を用いて効率的なテストケースを生成することが今後の課題の一つ. [7]. である．また，検査中にハングアップなどのエラーが発生した. [8]. 際，具体的なエラー個所の特定や修正は本手法の範囲外で. [9]. あり，プログラマが自らおこなうことになる．ソースコード情報と合わせてこれらを自動でおこなう枠組みを作成することも今後の課題である．. 6.3 提案手法の限界. [10]. [11]. 今回の提案手法はハードウェアエラーに対してデバイスドライバが正しく対応できるかどうかを調べるものであるが，エラーが検知できる場合はハイパーバイザがクラッ. [12] [13]. シュあるいはハングアップする場合のみである．不適切なエラー処理によるリソースリークに関しては，それが原因でシステムがクラッシュしない限り検知ができない．. [14]. また，そもそもデバイスドライバのバグがハードウェアエラーの処理に起因しない場合は本手法の適用範囲外である．[21] などの SFI 手法では例えばメモリ確保関数に. [15]. Fault Injection をおこなうことで，リソースリークの検査などをおこなっている．本提案手法とこれらの手法と組み. [16]. 合わせることで，より強固なデバイスドライバの検査がで. [17]. きる．. 7. 結論本稿では，ハイパーバイザの上で動くデバイスドライバ. [18] [19]. のハードウェア障害に対する検証をおこなうため先行研究である FaultVisor にネステッド仮想化の機能を加え，ネステッド環境に合った検証システムを提案した．提案手法により実際に VMWare ESXi 上の 2 つのデバイスドライバに. [20] [21]. 対して検査をおこなったところ，デバイスドライバの不適切なハンドリングが原因と考えられるエラーを 3 種類発見. [22]. した．また，オーバヘッドの評価実験より提案手法は実環境に近い状況でデバイスドライバのテストができることが. [23]. 示された． [24]. 参考文献 [1]. Klein, A.: Backblaze Hard Drive Stats for 2017, https://www.backblaze.com/blog/hard-drive-. c 2018 Information Processing Society of Japan ⃝. [25]. stats-for-2017/ (Viewed on 2018/4/18) (2018). Kadav, A. et al.: Tolerating Hardware Device Failures in Software, SOSP ’09, ACM, pp. 59–72 (2009). Takekoshi, S. et al.: Testing Device Drivers Against Hardware Failures in Real Environments, SAC ’16, ACM, pp. 1858–1864 (2016). Witkowski, T. et al.: Model Checking Concurrent Linux Device Drivers, ASE ’07, ACM, pp. 501–504 (2007). Ball, T. et al.: Thorough Static Analysis of Device Drivers, EuroSys ’06, ACM, pp. 73–85 (2006). Post, H. et al.: Integrated Static Analysis for Linux Device Driver Verification, IFM ’07, Springer, pp. 518–537 (2007). Lawall, J. L. et al.: WYSIWIB: A Declarative Approach to Finding API Protocols and Bugs in Linux Code, DSN ’09, IEEE, pp. 43–52 (2009). Amani, S. et al.: Static Analysis of Device Drivers: We Can Do Better!, APSys ’11, ACM, pp. 8:1–8:5 (2011). Kuznetsov, V. et al.: Testing Closed-source Binary Device Drivers with DDT, ATC ’10, USENIX Association, pp. 1–12 (2010). Renzelmann, M. J. et al.: SymDrive: Testing Drivers Without Devices, OSDI ’12, USENIX Association, pp. 279–292 (2012). Chipounov, V. et al.: The S2E Platform: Design, Implementation, and Applications, ACM TOCS, Vol. 30, No. 1, ACM, pp. 2:1–2:49 (2012). Cong, K. et al.: Symbolic Execution of Virtual Devices, QSIC ’13, IEEE, pp. 1–10 (2013). Microsoft: Driver Verifier, https://docs.microsoft. com/en-us/windows-hardware/drivers/devtest/ driver-verifier (Viewed on 2018/4/18). Linux Kernel Documentation: Fault Injection Capabilities Infrastructure, https://www.kernel. org/doc/Documentation/fault-injection/faultinjection.txt (Viewed on 2018/4/18). Johansson, A. et al.: On the Selection of Error Model(s) for OS Robustness Evaluation, DSN ’07, IEEE, pp. 502– 511 (2007). Mendonca, M. et al.: Robustness Testing of the Windows DDK, DSN ’07, IEEE, pp. 554–564 (2007). Rubanov, V. V. et al.: Runtime Verification of Linux Kernel Modules Based on Call Interception, ICST ’11, IEEE, pp. 180–189 (2011). Shekar, S. D. et al.: Device Driver Fault Simulation using KEDR, IJARCET, Vol. 1, No. 4, pp. 580–584 (2012). Winter, S. et al.: simFI: From single to simultaneous software fault injections, DSN ’13, IEEE, pp. 1–12 (2013). Cong, K. et al.: Automatic Fault Injection for Driver Robustness Testing, ISSTA ’15, ACM, pp. 361–372 (2015). Bai, J.-J. et al.: Testing Error Handling Code in Device Drivers Using Characteristic Fault Injection, ATC ’16, USENIX Association, pp. 635–647 (2016). Ben-Yehuda, M. et al.: The Turtles Project: Design and Implementation of Nested Virtualization, OSDI ’10, USENIX Association, pp. 423–436 (2010). VMWare: vSphere Hypervisor, https://www.vmware. com/products/vsphere-hypervisor.html (Viewed on 2018/4/18). Shinagawa, T. et al.: BitVisor: A Thin Hypervisor for Enforcing I/O Device Security, VEE ’09, ACM, pp. 121– 130 (2009). HewlettPackard: Netperf, https://github.com/ HewlettPackard/netperf (Viewed on 2018/4/18).. 8.

(9)