tadokoro-phd2012

Coordinated and Secure Server
Consolidation using Virtual Machines
（仮想マシンを用いた調整可能で安全なサーバ統合）
田所秀和
1
2
仮想マシンを用いたサーバ統合
サーバ統合
 リソースの利用効率向上
 物理マシンの台数削減
 サーバを容易に増減できる
P2V tool で動いているOSをそのまま統合
 古いOSを使い続けられる
VMs
Server
Server
Server
統合
10%
30%
20%
VMM
60%
3
仮想マシンが複数存在
複数の仮想マシン(VM)を同じマシンで動かす
 共通のリソースをVM間で分割
 仮想マシンモニタ(VMM)が物理CPUを仮想CPUに分配
 管理VMを使いVMを管理
 VMを他のマシンにマイグレーション
 負荷分散やハードのメンテナンス
管理VM
管理者
VMs
vCPU
vCPU
vCPU
管理
VMM
CPU
リソースをシェア
CPUリソースの競合
他のVMが動き、重要なタスクが阻害
 一つの物理CPUを取り合う
 各VMは他のVMを認識できない
 独立してCPUリソースを利用
素朴な解法：排他的なリソース割り当て
 利用効率低下
VMs
vCPU
vCPU
vCPU
VMM
CPU
CPUリソースを取り合う
4
5
管理VMの脅威
管理VMに侵入されるとすべてのVMに影響
 管理のための特権を悪用
 管理VMへの攻撃
素朴な解法：管理VMの特権を減らす
 マイグレーションができなくなる
 負荷分散や消費電力削減のためには必須
管理VM
VMs
攻撃
侵入
VMM
6
OSによる協調スケジューリング
各VMのスケジューラが協調し重要なタスクを優
先的に実行
 情報交換のために特別なスレッドが必要
 スケジューリング対象にしてはいけないスレッド
協調のため、OSに変更が必要
 動いているOSをそのままサーバ統合できない
不正確なスケジューリング
 仮想化によりOS内の
統計情報が不正確
 情報取得に時間がかかる
sched
sched
CPU
sched
7
情報漏洩防止のトレードオフ
ゲストOSによる管理
 管理VMによる管理を禁止し情報漏洩を防止
 可能な管理に制限がある
 e.g. self-migration
OS自身がメモリを暗号化し管理VMに見せる
 CPUが読み書きするメモリは復号化してある必要
 必要なところだけ暗号化できる
self-migration
管理VM
管理
自力でメモリコピー
VMM
8
本研究の貢献
調整可能で安全なサーバ統合
 仮想マシン間でのプロセススケジューリング
 CPUの競合回避と利用率向上を両立
 VMMが直接スケジューリング
 管理VMを経由した情報漏洩の防止
 従来通りの管理と安全性を両立
 VMMがメモリを暗号化
VMs
管理VM
管理者
管理
vCPU
vCPU
CPUを調停
CPU
vCPU
暗号化
VMM
I. 仮想マシン間でのプロセススケ
ジューリング
9
10
サーバ統合でのスケジューリング
システム全体でのスケジューリングが重要
 CPUはVM間で共有
 利用効率を高める
 重要なタスクが他VMのタスクに阻害されうる
例：システム全体がアイドルの時
VM1
だけIndexingを動かす
 アイドル時スケジューリング
 Indexing: 検索のDB作成プロセス
DB
VM2
WEB
Indexing
VMM
Hardware
優
先
度
システム全体のスケジューリングは
難しい
11
OSのスケジューリングとVMのスケジューリング
だけではうまくいかない
 OSによるスケジューリング
 VM外のアイドルを検出できない
 VMスケジューリング
 VM内のプロセスを区別できない
CPU使用率(%)
 Indexingだけを止めたい
VM1
DB
100
VM2
WEB
Indexing
50
indexer
lighttpd
0
0
60
120
elapsed time (sec)
VMM
Hardware
優
先
度
目標
システム全体でのスケジューリング
 重要なタスクを阻害させない
 CPU利用効率向上
OSを変更しない
 既存のOSをそのままサーバ統合可能
複数OSに対応
 サーバ統合では様々なOSが統合される
12
13
Monarch Scheduler
VMMが全体を考慮しプロセスの実行を調整
 柔軟にCPUリソースを割り当て可能
 利用効率は向上
 ゲストOSのスケジューラの動作を直接変更
 元のスケジューラを活用
 サーバ統合ではOSを変更せず
そのまま統合したい
VM1
DB
 プロセス実行時間を直接取得
 正確な統計情報を取得可能
VM2
WEB
Indexing
状況に応じて
Indexingを止める
Monarch
Scheduler
Hardware
14
VMMによるランキューの操作
VMMがゲストOSのランキューを操作しプロセス
を制御
 ランキューからプロセスを外すと停止
 ランキューはプロセスの待ち行列
 ランキューに再挿入し、再開
ランキュー
CPUで実行中
実行待ちプロセス
VM
process
run queue
ランキューを
直接操作
Monarch
Scheduler
15
プロセスの状態書き換え
VMMが直接プロセスの状態を書き換え停止
 次のスケジューリング時に停止
 通常ならランキューの後ろに追加される
実行中のプロセス
 実行中なのでランキューから単純に外せない
 I/O待ち状態に書き換え
running
I/O待ち(blocked)プロセス
 ランキューに存在しない
 停止状態に書き換え
ready
blocked
プロセスの状態遷移
16
直接プロセス実行時間を取得
VMMがプロセス時間を測定
 仮想アドレス空間の変化を観察 [Jones et al. 2006]
 ゲストOS内のコンテキストスイッチを推測
 e.g. CR3レジスタへの書き込みを観察
ゲストOSの統計情報を使わない
 仮想化により不正確
スイッチを観察
実行時間
スイッチを観察
process1
process2
process3
時間
アドレス空間とプロセスの対応
17
仮想アドレス空間をプロセスに対応づける
 ゲストOSのすべてのプロセス構造体を解析
 プロセスリストをたどる
 すべてのプロセスはリストにつながっている
 プロセス中に仮想アドレス空間の情報
 VMMからわかるのは仮想アドレス空間の情報のみ
 どのプロセスかは不明
ProcHead
Guest OS kernel
lighttpd
仮想アドレス空間A
ClamAV
仮想アドレス空間B
18
ポリシ記述用API
ポリシーに従いプロセスを制御
 実行時のプロセスやVMの増減に対応
 サーバがfork
 毎回マッチを取り直す
 OSの実装に依存しない記述が可能
void init() {
d_all = get_domain_by_name(“.*”);
p_all = get_task_by_name(d_all, “.*”);
p_si = get_task_by_name(d_all, “SearchIndexer”);
set_period(P);
}
void scheduler() {
t_all = get_time(p_all, P);
t_si = get_time(p_si, P);
if (t_all – t_si > 0)
suspend(p_si);
else
resume(p_si);
}
VM1
VM2
DB
WEB
Indexing
WEB’
Monarch
Scheduler
19
アイドル時スケジューリング
定期的にすべてのVMをチェック
 必要なプロセスのCPU使用率を取得
 WebやDBがCPUを使っているとき
 Indexingを止める
 CPUを使っているプロセスが存在しないとき
VM1
 Indexingを動かす
void scheduler() {
t_all = get_time(p_all, P);
t_si = get_time(p_si, P);
if (t_all – t_si > 0)
suspend(p_si);
else
resume(p_si);
}
DB
Indexing
状況に応じて
Indexingを止める
Monarch
Scheduler
VM2
WEB
20
実装
Xen 3.4.2 にMonarch Schedulerを実装
 サポートしているゲストOS
 Linux 2.6 (x86_64)
 Windows Vista (x86_64)
スケジューラはVMM内のタイマで定期的に起動
VMs
process
run queue
interrupt
Xen
schedule
Monarch
Scheduler
ゲストOSのデータ構造の操作
21
ゲストOSのデータ構造を直接操作
 知識を事前に取得
 デバッグ情報から型情報
 ソースコード
ゲストOSのメモリを直接読み書き
 仮想アドレスからマシンフレーム番号を取得
 ゲストOSのページテーブルを参照
 P2Mテーブルを参照
VM
kernel
image
virtual address
machine memory
page table
P2M table
Xen VMM
Linux: データ構造の位置特定
init_taskがプロセスリストの起点
 カーネルイメージから事前に取得
ランキューは仮想CPUごとに存在
 ブートするまでアドレスは不明
 仮想CPUのGSレジスタから
 GSレジスタはx8664_pdaを指す
GS register
Linux memory
x8664_pda
run queue
struct x8664_pda {
task_t* current;
ulong
data_offset;
…};
data_offset
+
PER_CPU_RUNQUEUES
22
Windows: データ構造の位置推定
23
プロセスリストの取得
 メモリ全体からプロセス候補を探す
 プロセスを表すビット列を探索
ProcHeadがプロセスリストの起点
 リストのうちグローバル変数
ランキューはProcHead
から一定距離
Windows Kernel
ProcHead
current
一定距離
summary
実行待ち
リスト配列
IRQL
ランキュー
VMM
実行中プロセス
実行待ちプロセス
I/O待ちプロセス
一貫性を保ったランキュー操作
24
ゲストOSが操作していないときランキュー操作
 ロックをチェック
 ロックが解放中ならスケジューリング中でない
 ゲストOSと同時に操作すれば壊れる
scheduler of Linux OS
schedule() {
spin_lock(runqueue);
RUN QUEUE OPERATION
spin_unlock(runqueue);
}
lock
unlock
runqueue
spinlock
check
Monarch
Scheduler
25
実験
スケジューリングが可能かを確認
 アイドル時スケジューリング
 優先度スケジューリング
オーバーヘッド
 スケジューリングのオーバーヘッド
 CPU時間測定のオーバーヘッド
 スケジューリング間隔の性能への影響
OSバージョンの変化の影響
Core 2 Duo 2.4 GHz Memory 6GB
Xen 3.4.2
Dom0: Linux 2.6.18.8
DomU: Linux 2.6.16.33 (1GB)
DomU: Windows Vista SP1 (1GB)
アイドル時スケジューリング
26
ポリシー
 lighttpdが動くときにSearchIndexerを停止
アイドルの時だけSearchIndexerが動いた
 ポリシー通り
 レスポンス時間が23%改善した
VM2
lighttpd
Search
Indexer
Xen VMM
アイドル時だけ動かす
100
80
60
40
20
0
CPU utilization(%)
VM1
indexer
lighttpd
indexer
lighttpd
100
80
60
40
20
0
60
120
0
60
120 0
elapsed time (sec)
elapsed time (sec)
ポリシー
 ClamAVの優先度を下げる
 CPU使用率を1/10に
結果
CPU utilization (%)
優先度スケジューリング
mencoder
ClamAV
Xen VMM
優先度を下げる
CPU utilization(%)
VM2
Monarch Schedulerなし
clamav
mencoder
100
50
0
0
 ポリシー通り制御できた
VM1
27
100
200
300
elapsed time (sec)
Monarch Schedulerあり
clamav
mencoder
100
50
0
0
100
200
300
elapsed time (sec)
スケジューリングのオーバーヘッド
28
VMMからプロセスリストをたどる時間
 プロセス数を変化
 プロセス数を固定しVM数を変化
現実的な状況では、オーバーヘッドは小さい
800
600
400
200
0
0
2000
4000
Execution Time (us)
Execution Time (us)
 100プロセスで、 3.6us (Linux), 12.1us (Windows)
 5VMで4.4us Linux Windows
6000
Total Number of Processes
20
15
10
5
0
0 1 2 3 4 5
Total number of VMs
29
webサーバの性能低下
lighttpdのスループットと応答時間を測定
 スケジューリング間隔とプロセス数を変化
 リストをたどるだけ
間隔が短く、プロセス数が増えるほど性能低下
 10msec以上なら、影響は小さい
36 processes
500 processes
2000 processes
36 processes
2000 processes
0.8
20000
15000
10000
5000
Throughput
0
0.1
1
10
scheduling interval (msec)
100
response time (msec)
throughput (req/sec)
25000
500 processes
0.6
0.4
0.2
Response time
0
0.1
1
10
scheduling interval (msec)
100
30
OSバージョンアップの影響
OSのバージョンアップ時にMonarch Schedulerが
対応すべきことを調査
 Monarch SchedulerはOSの内部構造に強く依存
 Linux 2.6.0から 2.6.32 の33バージョンを調査
外部からCFSのランキューを操作する必要
 赤黒木ライブラリを397行中91か所変更
 CFSは赤黒木を利用
バージョン変化
対応の難しさ
2.6.14
Spinlock_t の内部構造が変更
容易
2.6.18
runqueueの名前がrqに変更
容易
2.6.23
プロセススケジューラがO(1)からCFSに変更
難しいが可能
2.6.30
ランキューのアドレスの求め方が変更
容易
関連研究
ゲストOSの情報を使いVMをスケジューリング
 guest-aware VM scheduling [2009 Kim et al.]
 ゲストOSを変更
 task-aware VM scheduling [2008 Kim et al.]
 gray box 知識を利用
Windowsの内部情報をVMMから利用
 Vmwatcher [2007 Jiang et al.], EagleEye [2009
Nguyen et al.]
 GREPEXEC
 Lares [2008 Bryan et al.]
 専用のドライバが必要
31
ここまでのまとめ
Monarch Schedulerを提案
 仮想マシンモニタがシステム全体を考慮してプロ
セススケジューリングを調整
 柔軟なCPU割り当て
 CPU利用効率の向上
 OSの事前の変更が不要
 VMMが直接メモリを書き換え
 複数OSへの対応
 高水準APIでOSの種類やVMの違いを抽象化
 正確なスケジューリング
 プロセス時間をVMMが直接測定
32
II. 管理VM経由の情報漏洩防止
33
管理VMを経由した情報漏洩
34
管理VMへの攻撃
 すべてのユーザVMに影響
 管理のためにユーザVMに対して大きな権限
 サスペンド・マイグレーション
ユーザVMのメモリ内情報に簡単にアクセス可能
管理VMに侵入し
ユーザVMの情報にアクセス
管理VM
ユーザVM
メモリ
VMM
35
メモリからの情報漏洩
メモリ中には機密情報が存在
 パスワード
 ファイルキャッシュ
 ディスク暗号化でも防げない
メモリ上の情報は暗号化すると正しく動かない
メモリを覗くだけで
機密情報取得可能
ユーザVM
/etc /shadow
.ssh/id_dsa
暗号化ディスク
web app
パスワード
目標
管理VM経由の情報漏洩を防止
従来通りの管理が可能
 live migration
 負荷分散
 サービスを停止せずにハードウェアメンテナンス
OSを変更しない
 既存のOSをそのままサーバ統合可能
36
37
VMCrypt
管理VMへの情報漏洩を防ぐ
 VMMが管理VMに対してメモリを暗号化して見せる
 管理に必要なメモリは暗号化せずに見せる
従来通りの管理が可能
 live migrationに対応
 準仮想化ゲストOSに対応
 既存の管理ツールがそのまま使える
管理VM
暗号化
メモリ
VMCrypt VMM
ユーザVM
メモリ
38
２つのメモリビュー
VMCryptは２つのビューを提供
 暗号化ビュー
 ノーマルビュー
 ユーザVMには暗号化せずそのまま見せる
２つのビューに同時にアクセス可能
 live migrationに必要
 動いているユーザVMのメモリを転送
管理VM
暗号化
メモリ
VMCrypt VMM
ユーザVM
ノーマル
ビュー
ページ単位の暗号化・復号化
管理VMによるメモリマップ時に暗号化
 アンマップ時に復号化
 ページを複製することで、同時にアクセス可能
 マップ後の変化を知ることができない
 live migration問題ない
VMMがページテーブルの変化を検出
(4) 管理VMのアンマップを検出
(5) 復号化
(6) 書き戻す
(1) 管理VMのマップを検出
(2) VMCryptがページを複製
(3) VMCryptがページを暗号化
管理VM
ユーザVM
ページ’
ページ
Xen VMM
39
暗号化・復号化を省略し高速化
読み込み専用マップでは、アンマップ時に復号
化・書き戻しを省略
 変更がないことを保証できる
未初期化ページのマップ時は、暗号化を省略
 情報は漏れない
 もともと内容は不要
 管理VMによって書きこまれたかを管理
40
非暗号化ページ
暗号化せずに管理VMに見せる
 従来通りの管理を可能にする
 機密情報は含まれない
実行時に追跡して自動的に区別
 ビットマップで非暗号化ページを管理
5種類のページ
 start info
 ring
 shared info
 p2m table
 page table
41
非暗号化ページ: page table
42
マイグレーション時に管理VMがMFNを変更
ページテーブルの変化を実行時に追跡
 増えたらビットマップに追加
 ページ属性を設定するハイパーコールをチェック
ユーザVM
ページテーブル
管理VM
ドメイ
ン0
MFN32
Xen
ビットマップ
0
0
0 …
1
… 0
32
43
VMCryptを使ったlive migration(1/2)
動いているユーザVMのメモリを別ホストに転送
 VMCryptが自動で暗号化
 ビットマップを埋め込み転送
 メモリを転送
 ページテーブル、P2Mは書き換えつつ転送
VMのメモリ
bitmap
kernel
ページテーブル
管理VM
別ホストへ
44
VMCryptを使ったlive migration(2/2)
受け取ったメモリを新しいユーザVMに書き込み
 VMCryptが自動で復号化
 ビットマップを取得
 書き込み後、アンマップ時にVMCryptが復号化
 ページテーブルを書き換え
 新たに割り当てられたメモリを指すように
別ホストから
bitmap
kernel
ページテーブル
管理VM
VMのメモリ
45
暗号化鍵の管理
マイグレーション時は暗号化鍵を共有
Trusted Coordinator (TC) を経由
 信頼できるVMMの公開鍵を管理
TC
1. Bの鍵を要求
2. Bの公開鍵
Host B
Host A
管理VM
ユーザVM
VMM
管理VM
4. 移送
Session
Key
3. セッション鍵を暗号化して渡す
VMM
46
VMCryptはVMMを信頼
VMMは信頼できる
 TCがremote attestationによって確かめる
 信頼できるbootかどうか
 管理VMはVMMのメモリにアクセスできない
 Xenのアーキテクチャの特徴
管理VMを信頼しない
管理VM
TCB
ユーザVM
VMM
ハードウェア
検査
Trusted
Coordinator
TCB
47
実験
情報漏洩を防げるかテスト
オーバーヘッド
 暗号化ビューを作るオーバーヘッド
 ユーザVMの性能低下
 live migrationにかかる時間
 live migration時のオーバーヘッド
暗号化アルゴリズムはAES
 OpenSSLを移植
2.67GHz 8core Memory 12GB
Xen 4.0.1
Dom0: Linux 2.6.32-5-xen-amd64
DomU: Linux 2.6.32.27
connected with gigabit ether
情報漏洩を防げるかのテスト
管理VMからユーザVMのメモリを解析
 メモリ中にはAESやRSAの鍵
VMCryptなし
 AESやRSAの鍵を盗むことができた
VMCryptあり
 AESやRSAの鍵は見つからなかった
root@mach# aeskeyfind quattro1.dump
bb2e3fe052aedffe8ddffd3fbcfa7d09
ea9b7567ae60e300d00bde56096d3170
Keyfind progress: 100%
48
49
暗号ビューを作るオーバーヘッド
管理VMからマップ・アンマップにかかる時間
 1ページ、10万回繰り返し平均
実行時間の大部分は暗号化
Execution Time (us)
 それ以外のオーバヘッドは3usec
 最適化の効果あり
100
80
60
writable
40
read-only
uninitialized
20
0
Vanilla Xen
VMCrypt (null) VMCrypt (AES)
live migrationにかかる時間
50
暗号化により全体の時間は約1.8倍に増加
Execution Time (sec)
80
Vanilla
Vanilla(SSL)
VMCrypt(null)
VMCrypt(AES)
70
60
50
40
30
20
Downtime (sec)
ダウンタイムは1秒未満
10
0
0
1024
2048
3072
4096
memory size of domain U (MB)
1
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
Vanilla
Vanilla(SSL)
VMCrypt(null)
VMCrypt(AES)
0
1024 2048 3072 4096
memory size of domain U (MB)
51
live migration時のwebサーバの性能
lighttpdのスループットを測定
 10秒後からlive migration開始
VMCrypt (AES) の性能が安定しない
 暗号化とネットワークI/Oを重ねられない
throughput (req/sec)
 VMMで暗号化する代償
5000
4000
3000
Vanilla Xen
2000
Vanilla Xen (SSL)
1000
VMCrypt (null)
0
VMCrypt (AES)
0
10
20
30
execution time (sec)
40
関連研究
CloudVisor [2011 zhang et al.]
 VMMの下から管理VMによるユーザVMへのメモリ
アクセスを暗号化
 メモリをすべて暗号化するため準仮想化に非対応
Secure Runtime Environment [2010 Li et al.]
 live migrationに非対応
 管理ソフトウェアに変更が必要
52
ここまでのまとめ
VMCryptを提案
 管理VM経由の情報漏洩を防止
 管理VMからユーザVMのメモリアクセス時に暗号化
 準仮想化Linuxやlive migrationに対応
 非暗号化ページを自動的に認識
53
まとめ
サーバ統合環境での問題
 重要なタスクが他のタスクに阻害される
 管理VMを経由した情報漏洩
調整可能で安全なサーバ統合
 Monarch Scheduler
 VMMがプロセススケジューリング
 VMCrypt
 VMMがメモリ暗号化
54
今後の展望
55
Monarch Schedulerで様々なスケジューリングポ
リシーを作成する
 Fair shareスケジューリング
VMCryptを完全仮想化に対応
 管理VMがさまざまなメモリにアクセスする
 DMA、VGA
論文
56
 田所秀和, 光来健一, 千葉滋, "仮想マシン間にまたがるプロセ
ススケジューリング", 情報処理学会論文誌: コンピューティン
グシステム(ACS), Vol.1, No.2, pp.124-135, 2008月8月.
 Hidekazu Tadokoro, Kenichi Kourai, and Shigeru Chiba, "A
Secure System-wide Process Scheduler across Virtual
Machines", Proc. 16th IEEE Pacific Rim Intl. Symp. on
Dependable Computing (PRDC'10), pp.27-36, Dec 2010.
 田所秀和, 光来健一, 千葉滋, "実用性を考慮した仮想マシン間
プロセススケジューラ", 情報処理学会論文誌: コンピューティ
ングシステム(ACS), Vol.4, No.3, pp.100-114, 2011年5月.
 Hidekazu Tadokoro, Kenichi Kourai, and Shigeru Chiba,
"Preventing Information Leakage from Virtual Machines'
Memory in IaaS Clouds", To be published in IPSJ Transactions
on Advanced Computing Systems (ACS).

Download Report