通信処理のカーネル内競合を 検出するアスペクト指向 カーネルレベルロガー 柳澤 佳里* 光来 健一* 千葉 滋* *東京工業大学大学院情報理工学研究科 数理計算科学専攻

} カーネルレベルロガーの必要性 カーネル内の競合が疑われるケースがある カーネル内でログを取れることが必要 カーネル ネットワーク リモートログイン と バルク通信の競合 E.g.)ダウンロード中にリモートログインすると反応が遅い ネットワーク・カーネルの両方での競合の可能性 E.g.)CPUの競合により送受信処理が滞る カーネル内でログを取れることが必要 Tcpdumpなど既存のツールでは内部の処理が見えず不十分 write(2) read(2) } カーネル 見えない デバイス ネットワーク

Printfによるログ出力の問題点 コードを挿入するたびに再起動はしたくない コード挿入作業は煩雑 コード挿入後再起動が必要で動作するまでに時間がかかる カーネル・ネットワークの状況が変わる 再起動時にメモリ内容、接続情報は消去される コード挿入作業は煩雑 入れ忘れるとコードを挿入し再起動 とり忘れると性能低下、情報漏えい n_time ip_time() { … printf(“%ld\n”,..);

フラグによるログ出力切り替えの問題点 実行時オーバーヘッドが常にかかる ログ出力を細かく制御しようとするとフラグ数が爆発 ログ出力できる箇所が増えるとフラグチェックのオーバーヘッド大 そのオーバーヘッドを減らそうとすると十分なログが取れない可能性がある ログ出力を細かく制御しようとするとフラグ数が爆発 メモリ使用量大 フラグの構造化された 管理機構が必要 n_time ip_time() { if (flag1) printf(...); … if (flag2)

カーネル用アスペクト指向システム ログコードと挿入箇所をアスペクトとして記述 アスペクトを動的に挿入、削除 カーネル本体から分離して記述できる アスペクトを動的に挿入、削除 再起動不要 挿入箇所以外の実行時オーバーヘッドは低い アスペクトとしてまとめて関連箇所にコード挿入、削除 入れ忘れやとり忘れを防ぎやすい Eg) *_output関数呼び出しの箇所すべて、など

アスペクトとは ポイントカット アドバイス ジョインポイントの例 ログコード挿入できる箇所(ジョインポイント)を指定 関数呼び出し call/execution 変数アクセスの指定 set/get アドバイス ポイントカットで指定した 位置に挿入するログコード ジョインポイントの例 n_time Iptime() { … getmicrotime(&atv); t = … return (htonl(t)); } 関数実行箇所 関数呼び出し 変数への参照、代入

divert_packetを呼んでいる位置の前で 例: 特定箇所でロギング ポイントカット アスペクト int ip_fastforward(struct mbuf *m) { … divert_packet(teem,..); } aspect log_dequeue { } pointcut call(“ void divert_packet( struct mbuf *m,int ..)”); before(struct mbuf *m) { logging(m); } void ip_input(struct mbuf *m) { … divert_packet(m,...); } アドバイス divert_packetを呼んでいる位置の前で logging(m)を実行

Mbuf構造体の値を参照している位置の前で 例: データの追跡 ポイントカット アスペクト void ip_input(struct mbuf *m) { …. m = m->m_next; … } aspect trace_mbuf { } pointcut get(mbuf *m); before(mbuf *m) { logging(m); } void tcp_input(m, off0) { … for(; m && …) } アドバイス Mbuf構造体の値を参照している位置の前で logging(m)を実行

アスペクトのカーネルへの適用(weave) アスペクト記述 OSカーネル ポイントカット位置の検索 ポイントカット位置とアドバイスの対応付け コンパイル weave アスペクト (カーネル内部表現) カーネル内表現 ポイントカット記述子 コンパイル済みアドバイス

Call/executionポイントカットの実現方法 関数呼び出し箇所、実行箇所にてアドバイスを実行 実現方法: ブレークポイント トラップ(BPT) 実行時 (a) BPTの発生 Weave時 元の命令の保存 BPTの挿入 BPT trap(..) { exec_advice() exec_inst() } (b)adviceの実行 (c)Weave時に 保存した命令の実行

} ブレークポイントによる実現の利害 利点 欠点 実行フローを破壊しない Weaveした点以外の実行時間は不変 Jmp/call命令(5byte命令)で実現すると飛び先を上書きする恐れ ブレークポイント命令は1byte命令 Weaveした点以外の実行時間は不変 Weaveした点のみコード書き換え 欠点 ブレークポイント命令の実行は遅い カーネルではプロセス間のコンテキストスイッチが 無い分だけ軽い } mov $0x1, %eax call func 0 … jmp label1

Set/getポイントカットの実現方法 変数の代入、参照箇所でアドバイスを実行 デバッグレジスタによる実現 ポイントカットする変数のアドレスをデバッグレジスタに登録 デバッグレジスタに格納されたアドレスへのアクセスでトラップ ページフォールト トラップによる実現 ポイントカット箇所の入ったページを書き込み/読み込み禁止に設定 ページへの読み書きでページフォールトトラップ (b)割り込み trap(..) { advice } mbuf領域 （a)アクセス Weave時に アクセス禁止設定

ページフォールトによる実現の利害 利点 欠点: 実行時オーバーヘッド ポインタによるアクセスにも対応可能 静的な解析ではわからない ポインタによる変数アクセスの箇所すべてでステップ実行が必要 欠点: 実行時オーバーヘッド 同一ページ内の関係ない変数アクセス時も発生 Mbuf全体への使用ではオーバーヘッド小 Mbuf領域は連続して確保 Mbuf領域はページあたりの個数が小

実験I: 割り込みと関数呼び出しの比較 関数呼び出し(call命令)、ブレークポイント割り込み(int3命令)にかかる実行時間時間の比較 カーネル内部で実験 実験時はsti命令でその他の割り込みの禁止 実験環境 CPU: Athlon XP 2200+, Mem: 1GB FreeBSD 5.2.1R-p8 実験結果 Call命令 15 clocks Int3命令 373 clocks Getpid(2)システムコール 28,596 clocks

実験II: 割り込み挿入時の ネットワーク処理性能 ブレークポイント割り込み挿入時のTCPスループットを測定 ip_outputへのint3の埋め込み数を変えて実験 OS: FreeBSD 5.2R CPU: Athlon 2200+ Mem: 1GB NIC: Intel Ethernet Pro OS: FreeBSD 4.10R CPU: Athlon 2200+ Mem: 1GB NIC: Intel Ethernet Pro Network 100Mbps switching-HUB

実験結果II: 割り込み挿入時のネットワークの性能低下の調査 300回以下の割り込み数ではスループットの低下無し 300回以上ではほぼ線形に性能劣化 スループット(Mbps) 割り込みの数

関連研究(1) Aspect指向言語 AspcetC++ [Olaf ’02] μDyner [Marc ’03] コンパイル時にweaveを行う 実行時に必要となった箇所へのログ埋め込みは不可 μDyner [Marc ’03] 動的にweaveを行う コンパイル時に関数の頭にnop命令を挿入しておく コンパイル時に決めた箇所のみweave可能 Nop命令の実行によりweaveしていない時でも性能劣化

関連研究(2) カーネルロガー カーネルレベルでのコード挿入 LKST [畑崎 ’03]、 KTR 決められたイベントの箇所でのみログ出力可能 カーネルレベルでのコード挿入 Kerninstd [Ariel ’02] カーネル内のほぼ任意の箇所にコード挿入 基本ブロックの解析をしてjmp命令で実装 機械語レベルに挿入するので使いにくい

まとめ カーネル用アスペクト指向システムの提案 ブレークポイントトラップによりExecution/callポイントカットを実現 システムコール内部で呼んだ際に影響が少ないことを実験で確認 300回以下の場合にスループットに影響がほぼ無いことを実験で確認 デバッグレジスタ、ページフォールトトラップによりSet/getポイントカットを実現

今後の課題 実装 性能評価 作成したシステムを用いてリモートログインとバルク通信の競合を調査 データ構造が変化しても追跡してロギング E.g.) Network I/Oでは配列からmbufへのデータが変化 利用者からヒントをもらうとできる? 利用者は前後にポイントカットを挿入可能