日本ソフトウェア科学会第 31 回大会 (2014 年度) 講演論文集

仮想マシンモニタによるマルウェアプロセスの実行抑止
本田 惇

高橋 一志

大山 恵弘

近年，クラウドサービスの基盤として仮想マシンモニタ (VMM) が用いられている．特に IaaS と呼ばれるクラウドサービスでは VMM と各 OS の管理者が異なるが，このようなサービスにおいては，ゲスト OS 内でマルウェアが実行されていても VMM の管理者はゲスト OS の内部状態を変更できない．したがって，マルウェアへの対処は仮想マシン (VM) 全体を停止させるなど，被害者のユーザまで VM を利用できなくなってしまうような粒度の粗い方法に限られる．本研究では，ゲスト OS 内で動作するマルウェアの実行を VMM が検知し，そのプロセスに対して，VMM 管理者が指定したアクションによって VMM が実行を抑止するシステムを構築する．VMM は VMM
管理者が定めたセキュリティポリシーに違反したゲスト OS 内のプロセスに対して，実行速度の低下，プロセスの強制終了，システムコールの失敗といったアクションを取ることができる．実行速度低下は，仮想タイマ割り込み間隔の調整やタイマハードウェアのエミュレーション動作の変更を行うことで実現する．本研究ではゲスト OS とホスト
OS に Linux を仮定し，KVM を改造することにより上記システムの実装を進めている．現状の実装では VMM から，セキュリティポリシーに違反したプロセスの認識，プロセスの強制終了，システムコールの失敗が実現できるようになっており，本論文ではそれらを行った実験についても報告する．

1 はじめにIaaSプロバイダが管理各ユーザが管理クラウドコンピューティングのサービスの 1 つでMalicious VMある IaaS (Infrastructure as a Service) が広く利用VMされている．IaaS は，サービス提供者がサービス利用者に仮想マシンを貸し出すものである．サービス利用者は仮想マシンを管理し，サービス提供者は仮想マGood VMs
VM

VM

Good processes

MalwareProcess

Process

シンを管理するための仮想マシンモニタを管理する．
サービス利用者は仮想マシンに自分の好きな OS をVMMインストールし，その OS の管理者権限を保持する．
仮想マシン上で動作させる OS を以降ではゲスト OSと呼ぶ．

図1

ここで，IaaS のゲスト OS が攻撃を受け，そのゲ想定する脅威シナリオ

スト OS 内でマルウェアが実行されたケースを考えるがインストールされているとは限らない．もし，サー(図 1)．ゲスト OS はサービス利用者が管理している

ビス提供者が仮想マシンモニタにおいてマルウェアのため，ゲスト OS 内にアンチマルウェアソフトウェア検知や実行抑止を実現できれば，ゲスト OS 内にインPreventing Malware Process Execution by Virtual
Machine Monitor.
Jun Honda, Kazushi Takahashi, Yoshihiro Oyama,
電 気 通 信 大 学, The University of ElectroCommunications.

ストールされたアンチマルウェアソフトウェアに依存せずに，高い安全性をサービス利用者に提供することができる．
もしゲスト OS 内でのマルウェア実行を検知したとしても，既存の多くの仮想マシンモニタでは，仮想マシンを停止させたり，仮想マシンのネットワーク通VMProcess

信を遮断するなどの粗粒度の対策しか実現できない．
そのような対策を実行すると，同一ゲスト OS 内で動作するサーバなどの重要なプログラムも利用できなくなる．また，一般に，仮想マシンモニタにおけるマルウェア検知は OS 内におけるマルウェア検知よりも精度が低く，通常のプログラムを誤ってマルウェアと判定することがありうる．もしそうなった場合に仮想マシン全体を停止させてしまうならば，サービス利用

MalwareProcess

SYSENTERのフック

KVM

ゲストOS情報の取得

提案システムシステムコールフック部

連携

強制終了
システムコール失敗
提案システム
プロセス解析部

速度低下処理提案システム仮想タイマ割り込み発行部
通信者に大きな被害を与えてしまうことになるだろう．
したがって，仮想マシンモニタによるプログラムの実行抑止は，仮想マシン全体に適用されるのではな

図2

システム構成く，マルウェアであると判定されたプロセスにのみ適とが可能である．本研究では仮想マシンモニタ KVM用されることが望ましい．また，マルウェアである可を拡張して提案システムを実装し，マルウェアを模擬能性の高低やマルウェアと判定される根拠となった処したプログラムの検知と実行抑止ができたことを実理の種類に応じて，厳しい実行抑止や緩い実行制御験により確認した．

を含む様々な方法が提供されることが望ましい．さら

本論文の構成は以下の通りである．第 1 章では本研に，仮想マシンには多様な種類やバージョンのゲスト究の背景と本論文の目的を提示する．第 2 章では本OS がインストールされるため，実行抑止の方法は，論文で提案するシステムについて説明する．第 3 章

OS の種類やバージョンへの依存性が小さいものであでは本研究の実験とその評価を示す．第 4 章では本論ることが望ましい．

文と関連のある研究を紹介する．第 5 章では本論文

本研究では，仮想マシンモニタによってプロセス単のまとめと今後の課題について述べる．

位でマルウェアを検知し，実行を抑止するシステムを提案する．提案システムはゲスト OS で発行されたシ2 提案システム

ステムコールの情報を利用してマルウェアを検知す

2. 1 システム概要

る．提案システムの特長は，マルウェアと判定される

本研究では，KVM 上にある VM 内でマルウェア根拠となった処理の種類に応じて，様々な対策処理をが実行されているという状況を仮定する．KVM 上実行することができる点である．例えば，システム

では，マルウェアが動作している VM 以外の善意のコールを変更したり，プロセスを終了させたり，プロVM や，マルウェアが動作している VM 内においてセスに割り当てる CPU 時間を変更したりすることがもマルウェアプロセス以外の善意のプロセスが動作できる．

している可能性がある．この状態において，マルウェ

また，提案システムはゲスト OS のソースコードをアが動いている VM の外部からマルウェアプロセス修正することなく，VMM を改変することにより実現の実行を検知し，検知したプロセスに対して抑止処理する．本論文ではゲスト OS は Linux であると仮定を行うシステムを提案する．

している．加えて，提案システムはシステムコール番

提案システムの構成を図 2 に示す．提案システムは号の割り当てや引数などのシステムコールの仕様にのシステムコールフック部，プロセス解析部，仮想タイみ依存する．このため，導入対象 OS のシステムコーマ割り込み発行部から構成される．

ルの仕様が変更されない限り，ゲストカーネルのバー

システムコールフック部は VM 上のゲスト OS がジョンを変更した場合でも提案システムを利用するこ

発行するすべてのシステムコールを，SYSENTER 命令

をフックすることによってインターセプトし，システ
ムコール番号，引数，CR3 レジスタの値といったゲ

VM

wrmsr

rdmsr

SYSENTER

Page fault

スト OS の情報を取得する．これらの取得した情報はすべてプロセス解析部に渡される．
プロセス解析部は，VMM の管理者が与えたセキュVMM

hookhook

Shadow MSR

リティポリシーをもとに，システムコールフック部かSystem CallInterceptor

ゲストOSが実際にMSRに設定した値が書き込まれるら送られたシステムコールの情報をプロセスごとに解析する．そして，セキュリティポリシーに違反したシステムコールを発行したプロセスをマルウェアとし，そのプロセスに対してシステムコール情報の書き換え，またはプロセスの強制終了をさせることがで

H/W

MSR

EIP: 0xffffffff

SYSENTER実行時にジャンプするアドレスが含まれる

きる．また，マルウェアプロセスの実行速度を低下さ図3せる処理をする場合は，そのプロセスの CR3 の値をシステムコールフックの概要仮想タイマ割り込み発行部に通知する．VMM 層か

スト OS 内で wrmsr 命令が実行されるときに，VMMらのプロセスの識別は，得られた CR3 の値を擬似的が該当の MSR への書き込みをフックし，本来書き込なプロセス ID とすることで可能となる [2] [3]．プロ

む値を Shadow MSR に保存し代わりに 0xffffffffセスの生成と終了に伴い，異なるプロセスが同一のという実在しないアドレスを実機の MSR に書き込む

CR3 の値を持つことが稀にありうるが，本研究では(図 3)．Shadow MSR はゲスト OS が実際に MSR にそのようなことは発生しないと仮定している．

設定した値が書き込まれる場所である．ゲスト OS 内

仮想タイマ割り込み発行部は，プロセス解析部から送られた CR3 の値を持つマルウェアプロセスに対して実行速度低下の処理を行う．具体的な処理については 2. 3. 3 節で説明する．

で rdmsr 命令を実行すると，Shadow MSR の値が返される．
すると，SYSENTER 命令によって MSR の値を読み込んで実在しないアドレスにジャンプするときにページフォールト例外が起きることで VM Exit が発生し，

2. 2 マルウェア検知

CPU のコントロールが VM から VMM に切り替わ2. 2. 1 システムコールフック

る．したがって VMM はその間にシステムコール番

ゲスト OS が発行するシステムコールの情報は号，引数，CR3 の値といったゲスト OS の情報を取SYSENTER 命令をフックすることによって得ることが得することができる．

可能となる．SYSENTER はシステムコールを高速に呼システムコール番号は EAX レジスタ，第一引数かび出す命令である．MSR (Model Specific Register)

らは順番に EBX 以下の汎用レジスタに格納されていにカーネルモードのルーチンを指すセレクタなどをる．引数がファイルパスなど文字列を示す場合には，保持しておき，カーネルモードに移行するときにそこVMM がゲスト OS のメモリを読みに行くことで文から CS レジスタ，EIP レジスタ，ESP レジスタに値字列を獲得する．引数に対応するレジスタにはゲストをロードすることでオーバーヘッドの少ないカーネル仮想アドレスの値が格納されているので，一度ゲストモード移行を実現している．上記の MSR は，rdmsr物理アドレスに変換した後にメモリを読みに行くこ命令および wrmsr 命令を使用して読み取りおよび書とでこれを実現する．また，フック後のシステムコーき込みを行っている．

ルの再開は本来 SYSENTER 命令の実行時にジャンプすそこで提案システムでは，システムコールフック部が SYSENTER 実行時に実在しないアドレスが EIP レジスタにロードされるようにする．具体的には，ゲべきアドレスを Shadow MSR から取得し，取得したアドレスにジャンプすることによって行う．

2. 2. 2 ポリシー制御



VMM の管理者はシステムコールに関するセキュリ

open, "/etc/passwd", "", 1, niceティポリシーを VMM に与えることができる．プロ

clone, "", "", 10, process_kill

セス解析部はプロセスごとのシステムコールシーケン

write, "", "hoge", 1, slow

スを保持し，プロセスがセキュリティポリシーに違反していないかを調べる．セキュリティポリシーには，


図4

セキュリティポリシーの記述例

システムコール名，引数，システムコールが連続で呼ばれた回数，アクション名が含まれており，引数には

1 行目は第一引数に/etc/passwd を持つ open() シ

整数や文字列を指定することができる．具体的な文法

ステムコールが 1 回呼び出された時，nice() システは後述する．

ムコールに置き換える，という記述の例である．こフックしたシステムコールがポリシーに記述したシの置き換えは，セキュリティ上影響の大きいシステムステムコール名，引数に一致した場合，ポリシーで定コール呼び出しを，ほとんど影響を与えないシステムめた回数だけ連続で呼ばれていたならば，そのプロコール呼び出しに変えることを意図して指示されてセスの CR3 の値を VMM が持つマルウェアプロセスいる．つまり，この例では nice() でなくとも，例えリストに保存する．マルウェアプロセスリストには，ば getpid() システムコールなどに置き換えることもVMM がマルウェアだと判定したプロセスの CR3 のセキュリティ上の影響を小さくする点で有効である．

値とそのプロセスに対応する対策処理が保持されてnice() システムコールは呼び出し元プロセスの niceいる．リストが保持している CR3 の値を持つプロセ値に加える値を第一引数に持つ．システムコール置きスからシステムコールが発行されたとき，VMM は換えの対策処理においては，ゲスト OS への影響を減

その CR3 の値に対応した対策処理を実行する．

らすために第一引数を 0 に書き換える．

提案システムにおける対策処理は 3 つある．シス

2 行目は引数を持たない clone() システムコール

テムコールを発行するプロセスがマルウェアプロセス(fork ライブラリ関数により呼び出される) が 10 回リストに存在するとき，その対策処理として，システ連続で呼び出された場合，そのプロセスを強制終了さムコールの置換，プロセスの強制終了，プロセス実行せる，という記述の例である．これは，多数のプロセ速度の低下のいずれかをポリシーの記述者が指定す

ス生成による DoS 攻撃への対策を意図したセキュリることができる．

ティポリシーである．

図 4 にセキュリティポリシーの記述例を紹介する．

3 行 目 は 第 二 引 数 に hoge と い う 文 字 列 を 持 つセキュリティポリシーから入力する情報は 5 個であwrite() システムコールが 1 回呼び出された場合，そり，次のような文法でカンマで区切って記述する．のプロセスの実行速度低下処理を行う，という記述のシステムコール名，第一引数，第二引数，連続回数，アクション名例である．この例では引数を hoge としているが，実際にはその部分にはマルウェアによる通信やスパムを特徴づける文字列などが入ることを想定している．

引数が文字列の場合は""で囲み，整数の場合は囲

これは，プロセスがそれらの文字列を用いていても，まずに記述する．引数に指定している""という表現

そのプロセスが悪意によるものであると完全に断定は，その引数の値を無視するということを意味しておすることはできない場合の，実行速度低下を行うためり，実装上セキュリティポリシーの読み込みエラーをのポリシー記述例である防ぐためのものでもある．現在の実装では，システムコールの第一引数と第二引数に対してのみ指定ができるようになっている．今後第三引数以降に対しても指定が行えるように拡張する予定である．

2. 3 マルウェア実行抑止

kill() システムコールは任意のプロセスグループ

2. 3. 1 システムコールの失敗

もしくはプロセスにシグナルを送ることができる．第ゲスト OS のシステムコールを失敗させる方法とし

一引数の pid に 0 を指定した場合，呼び出し元のプて，実際にシステムコールが実行される前に SYSEXIT

ロセスのプロセスグループに属するすべてのプロセ命令 (システムコールの出口で実行される命令) をエ

スに第二引数 sig で指定したシグナルが送られる。つミュレートすることで強制的にシステムコールを終まり提案システムは，システムコール番号を kill()了させる，という手法が最も素直な手法である．しかシステムコールのものに，第一引数を 0，第二引数をし，SYSEXIT によるシステムコール呼び出し元への9 (SIGKILL) に書き換えることで実行中のプロセス復帰は復帰先の EIP や ESP の情報を保持する部分でを強制終了させることができる．これを，2. 3. 1 節でゲスト OS 依存の処理が深く関わっており，強い OS述べたシステムコールの置き換えと組み合わせるこ依存を引き起こす．したがって本研究では，OS 依存とで，悪意のあるプロセスが何らかのシステムコールを可能な限り軽減するため，システムコールの置き換を発行した瞬間，それを kill() システムコールに置えという手法を取った．システムコールの置き換えなき換えて直ちにプロセスを終了させることができる．

らば，システムコール番号を格納しているレジスタを2. 3. 3 プロセス実行速度の低下書き換えるだけでよく，OS 依存性は最小限になる．

マルウェア実行速度を落とす機構では，タイマ割りシステムコールを置き換えることで，マルウェアが込みの間隔を短くし，ゲスト OS の仮想的な時間の経本来実行したい悪意のある命令を失敗させることがで過速度を早くすることでマルウェアプロセスの実行きる．具体的には，EAX 以降の汎用レジスタの内容速度を低下させる．プロセス解析部から通知されたを書き換えることでシステムコール番号や引数の値CR3 の値を持つプロセスが VM の仮想 CPU にスケを変更する．そうすることで，マルウェアプロセスがジューリングされ，かつその仮想 CPU が物理 CPU発行したはずのシステムコールは他のシステムコーに割り当てられている間だけ，その仮想 CPU に配送

ルに置き換わり実行される．例えば，ゲストのプロセするタイマ割り込み間隔を短くする．さらに，このタスが open() システムコールを発行したはずが実際はイマ割り込み発生時に，仮想 CPU が保持する仮想的nice() システムコールを実行しているという結果にな時刻の変更を行う．これは，仮想 CPU 内の TSCなる．

(time stamp counter) やカーネル時間を表す変数をこれにより，システムに多大な影響を及ぼすシステ書き換えることで実現する．これは，DoS 攻撃などムコールを実行させないことが可能である．また，シの資源を大量に消費する攻撃に対して有効である．

ステムコール置き換えは，ゲスト OS 内で動くプロセ

プロセス実行速度の低下処理を行う理由は 2 点あスにとっては，提案システムによって置き換えられたる．第一に，IaaS 環境ではゲスト OS の内部を操作後のシステムコール呼び出しと同義である．したがっすることは可能な限り避けたいからである．第二に，て，実行後の戻り値などは置き換え後のシステムコー

プロセスがマルウェアかどうかの判断をセキュリティルの結果が返ることになる．

システムが誤る可能性があるためである．プロセスを

2. 3. 2 プロセスの強制終了

kill するという処理は，そのプロセスがメモリ上に保プロセスの強制終了は，システムコールの置き換え持していたかもしれない重要な情報を失わせることと kill() システムコールの仕様を利用することで実や，そのプロセスが担っている重要なサービスを止め現する．kill() システムコールは次のように定義さることにつながるので，可能な限り行わないことが望れている．

ましい．つまり，セキュリティシステムがプロセスを検知した際に悪意のあるプロセスかそうでないかの

int kill(pid_t pid, int sig);

確信が持てないときは，直ちにプロセスを kill するのではなく，実行速度低下によって様子を見られるよう

表1

実験環境

CPU

Intel Core i7-4702MQ

HDD

SATA 5400rpm 8MB cacheVMM

KVM (API version 12)

ホスト OS

Ubuntu 13.10 (Linux 3.12.5, 64bit)

ホストメモリ

16GByteゲスト OS
ゲストメモリwhile(1)fork();



図5

実験で用いた fork 爆弾のコード

Ubuntu 12.04 (Linux 3.2.0, 32bit)

表2

カーネルコンパイルの所要時間

1GByteネイティブ KVM

52 分 21 秒

提案システム70 分 41 秒にする．そして,VMM の管理者はゲスト OS の管理者に通報し，ゲスト OS の管理者自身に対処してもらするプロセスを検知した時，呼び出し元のプロセスのうことができる．

プロセスグループに属するすべてのプロセスを強制終了させた．実験の結果，図 5 のような単純なコー3 実験と評価

ドの fork 爆弾を検知し強制終了させることができた．

3. 1 実験環境

なお，プロセス実行速度の低下に関しては実装中の実験環境を表 1 に示す．VMM は KVM，ゲスト段階であるが，その前段階の予備実験として，VMM

OS は Linux を使用した．ゲスト OS はシングルコアがカーネル時間を示す変数を書き換えてゲスト OS ので実行されるように設定した．実験は，セキュリティ時間を更新することにより，ゲスト OS の時刻が非常ポリシーによるプロセス制御と提案システム上のゲに速く進むことを確認した．例えば，カーネル時間をスト OS のオーバーヘッドの測定を行った．

示す変数を 60 倍した値に書き換えると，ゲスト OSの時刻は通常の 60 倍の速度で時刻が進んだ．

3. 2 ポリシー制御による擬似マルウェアの抑止ポリシー制御によるマルウェアの抑止実験では 2 つ

3. 3 オーバーヘッドの実験を行った．1 つ目はゲスト OS 内のプロセスがオーバーヘッドの測定実験では，ネイティブな KVM

重要なファイルを open しようとしたら，そのためのと提案システムを実装した KVM とで，ゲスト OS 内open システムコールを失敗させるという実験である．

でのカーネルコンパイルに要する時間を測定し比較

2 つ目はゲスト OS 内で fork 爆弾を実行したプロセした．コンパイルの対象にしたカーネルのバージョンスを強制終了させるという実験である．

は Linux 3.2.0 である．実験結果は表 2 のようになっ

ゲスト OS のシステムコールを失敗させる実験でた. ネイティブ KVM と比べ，提案システムでは約は，/etc/passwd を open しようとするとき，open()35%のオーバーヘッドが発生している．主な原因は，システムコールを nice() システムコールに置き換えゲスト OS のシステムコールが呼ばれるときに必ずた．実験の結果，/etc/passwd を open しようとするページフォールトが起きることや，システムコールのプロセスのシステムコールを置き換え，システムコー解析にあると考えられる．

ルを失敗させることに成功した．しかしながら，このままファイルの open を禁止するのみでは，ゲスト4 関連研究

OS 内に存在する他の善意のプロセスを利用する分に本研究は，岡村らによる HyperSlow [7] の研究をも障害が発生してしまうため，セキュリティポリシー発展させたものである．岡村らによる研究では，仮想の内容をさらに発展させる必要がある．

マシンモニタが特定のプロセスの実行を遅くさせる

ゲスト OS 内の fork 爆弾を強制終了させる実験に機構のみが実現されており，マルウェア検知や他の対おいては，clone() システムコールが 10 連続で発行策処理については実現されていなかった．本研究では

マルウェア検知処理および他の対策処理が実装され，変化させている．本研究は，仮想 CPU の優先度ではより実用的なシステムが構築されている．マルウェアなく仮想的な時刻を操作していることや，特定のプロ検知処理の動作は，セキュリティポリシーによって指セスを速くするのではなく遅くする点で，この研究と定することができる．また，岡村らの研究では仮想マ異なる．

シンモニタとして Xen が利用されていたが，本研究では KVM が利用されている．

vMon [6] は提案システムと同じく，ゲスト OS 内のプロセスに対してセキュリティのための監視を行う仮想マシンモニタを利用したマルウェア検知シスことを可能にする VMM であり，KVM を拡張してテムが過去に多く提案されている．文献 [1] [2] では，実装されている．vMon でも VMM がプロセスを強マルウェアを検知する機構については詳しく説明され制終了させることができるが，その処理はゲスト OSているが，検知したマルウェアの実行を抑止する機構のカーネルのデータ構造に依存している．一方，提案については明らかにされていない．一方，提案システシステムでは，システムコールの番号と引数を書き換

ムでは仮想マシンモニタがマルウェアの実行を効果的えることによりプロセスの kill を実現しており，ゲスに抑止することができる．

Lycosid [4] は，仮想マシンモニタを利用したセキュ

ト OS への依存が小さい．また，vMon ではプロセスの実行速度を制御することはできない．

リティシステムであり，自身の存在を隠そうとするマルウェアを発見する機能を持つ．Lycosid の研究で5 まとめと今後の課題

は，プロセスのコードにパッチを当てることにより，本論文では，仮想マシンモニタがゲスト OS 内で動特定のプロセスの実行時間を増加させる技術が提案

くマルウェアプロセスを検知し，多様な対策処理を通されている．その研究では実行時間の増加を隠れたプじて実行を抑止するシステムを提案した．提案システ

ロセスの検知に応用しているが，マルウェアの実行抑

ムの利用者は，マルウェアと判定されるプログラムの止に応用することは考えられていない．

動作に応じて，適切な対策処理を実行することができ

FoxyTechnique [8] は，仮想マシンに提供する仮想る．実験により，マルウェアを模擬したプログラムのデバイスの振る舞いを変更することで，ゲスト OS の検知と実行抑止が提案システムによって実現されたこ

コードを変更することなく，OS の資源管理ポリシーとを確認した．

を改変する手法である．この研究では仮想マシンがタ今後の課題を以下に述べる．第一にプロセス実行速イマ割り込みの頻度を変更するという手法を用いて度低下機構の実装と評価が挙げられる．第二にセキュいるが，それをプロセスの実行抑止に応用することはリティポリシーをより実用的なものに発展させること行われていない．

も重要であると考えられる．また，SYSENTER のオー

FoxyLargo [9] は仮想マシンモニタが仮想 CPU の速度を制御することにより仮想マシンの実行速度を変えることを可能にするシステムである．FoxyLargo

バーヘッドも改善の余地がある．
謝辞 本研究は JSPS 科研費 26330080 の助成を受けている．

は仮想マシン全体の実行速度を変えることしかできないが，本研究では特定のプロセスの実行速度を変え

参 考 文 献られるようなシステムを提案している．

[1] Garfinkel, T., Rosenblum, M., et al.: A Virtual
Machine Introspection Based Architecture for Intrusion Detection., Proceedings of the 10th Annual
Network and Distributed System Security Symposium, 2003, pp. 191–206.
[2] Jiang, X., Wang, X., and Xu, D.: Stealthy Malware Detection Through VMM-based ”Out-of-thebox” Semantic View Reconstruction, Proceedingsof the 14th ACM Conference on Computer andCommunications Security, CCS ’07, ACM, 2007,

Kim らの研究 [5] では，ゲスト OS 内で I/O を行っているプロセスを VMM が認識し，I/O バウンドのプロセスが動作する仮想 CPU に高い優先度を与えるなどの処理により，I/O 性能を向上させる手法を提案している．この研究は本研究と同じく，VMM がプロセスを認識して特定のプロセスに与える CPU 資源を

pp. 128–138.
[3] Jones, S. T., Arpaci-Dusseau, A. C., and ArpaciDusseau, R. H.: Antfarm: Tracking Processes
in a Virtual Machine Environment., Proceedingsof USENIX Annual Technical Conference, 2006,
pp. 1–14.
[4] Jones, S. T., Arpaci-Dusseau, A. C., and ArpaciDusseau, R. H.: VMM-based Hidden Process Detection and Identification Using Lycosid, Proceedings of the Fourth ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments, VEE ’08, ACM, 2008, pp. 91–100.
[5] Kim, H., Lim, H., Jeong, J., Jo, H., and Lee,J.: Task-aware Virtual Machine Scheduling for I/O
Performance., Proceedings of the 2009 ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments, VEE ’09, ACM, 2009,
pp. 101–110.
[6] Li, N., Li, B., Li, J., Wo, T., and Huai, J.: vMON:

An Eﬃcient Out-of-VM Process Monitor for Virtual
Machines, Proceedings of the 15th IEEE International Conference on High Performance Computing and Communications (IEEE HPCC-13), IEEE,
2013, pp. 1366–1373.
[7] Okamura, K. and Oyama, Y.: Controlling theSpeed of Virtual Time for Malware Deactivation,
Proceedings of the Asia-Pacific Workshop on Systems, APSys ’12, ACM, 2012.
[8] Yamada, H. and Kono, K.: FoxyTechnique:
Tricking Operating System Policies with a Virtual
Machine Monitor, Proceedings of the 3rd International Conference on Virtual Execution Environments, VEE ’07, ACM, 2007, pp. 55–64.
[9] Yoshida, T., Yamada, H., and Kono, K.: FoxyLargo: Slowing Down CPU Speed with a Virtual Machine Monitor for Embedded Time-Sensitive
Software Testing, Proceedings of 2008 International
Workshop on Virtualization Technology, 2008.