プロフィール

大山恵弘

  • Author:大山恵弘
  • 公式なサイトはこちら

最近の記事

最近のコメント

最近のトラックバック

月別アーカイブ

ブロとも申請フォーム

ブログ内検索

RSSフィード

リンク

FC2カウンター

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

【障害】 Automatic On-line Failure Diagnosis at the End-User Site 【デバッグ】

In HotDep '06
http://www.usenix.org/events/hotdep06/tech/

障害発生したら、それをユーザに通知する前に、自動的に診断処理を実行する枠組みの提案。
ユアンユアンさんがラストオーサー。Rxの研究の流れを組んでいるようだ。

トリアージ診断プロトコルなるものを提案。Wikipediaによりますと、トリアージは、災害医療における多数の傷病者を重症度と緊急性によって分別する方法。

このプロトコルにより、一つの診断の結果に応じて、自動的に次の診断を実行させるなどのことが可能になる。診断手法の例として挙げられているものは、単なる再実行、コアダンプの解析、メモリバグ検出器の実行、レースバグ検出器の実行、バックワードスライシング、スケジューリング変え器、など。

チェックポイントを定期的に取るので、再実行ができる。

デバッグ作業におけるエキスパートシステムを作りましたみたいな感じでしょうか。
最終的には人間がバグを突き止め、除去するにしても、一定の初期診断はこのシステムが自動的にやってくれますみたいな。
スポンサーサイト

【並列処理】 Safe at Any Speed: Fast, Safe Parallelism in Servers 【イベントベース実装】

In HotDep '06.
http://www.usenix.org/events/hotdep06/tech/

サーバをイベントハンドラの集合という形で作ることを主張。

複数の要求を並列に処理できるサーバにしたい。よって複数のイベントハンドラも並列に実行したい。

でもイベントハンドラを何でもかんでも並列に実行したら、共有変数などがあるときに、困ったことになる。なので、互いに干渉しあわないイベントハンドラだけを並列に実行する。

どのイベントハンドラの組を並列実行できるかは、静的解析で求める。解析結果にもとづいて、スケジューラが適切なハンドラを実行。

どういう静的解析を用いるのかは述べられていない。この論文は、サーバをそういうアーキテクチャにもとづいて作りましょうっていう大まかな方向を提案するもののようだ。

こういう論文読むと、並行オブジェクトやってた10年前の自分を思い出す。「複数のスレッドがさわる変数を並行オブジェクトに押し込む。並列性はできる限り抽出して、スレッドを作る」。なつかしいのう。レース条件の話も(同僚が)やってた。

並行オブジェクトに関する一連の研究からの差分は何かな。レースを静的解析で求めましょうってところが新しいのか。いや、そういう研究もあるよな。ううむ。

【VMM】 Characterization of network processing overheads in Xen 【性能評価】

In VTDC 2006.
http://workspace.globus.org/vtdc06/

XenのDom0とDomUを、両方とも1つのCPU上で動かした場合と、それぞれ1つのCPU上で動かした場合とで、ネットワーク性能を比較した。IPerfベンチマークを利用。

アブストに「2CPUで動かすほうが1CPUで動かすよりもexpensiveだった」と書いてあるので、まずギョッとする。マルチコアの時代もこれで終わりかって。

そんなことがあるのか、キャッシュのせいか、などと思いながら読むと、スループットは2CPUのほうが高いという結果。2CPUのほうが各処理にかかるサイクルが多いので、expensiveであるという表現に至ったようだ。native, 1CPU, 2CPUで、スループット的には、1550, 750, 1100くらい。ペイロード1バイトを受信するのにかかるサイクルが、17, 37, 46。

CPUを複数使えば、全体としての処理サイクルが増えるのは当たり前という気がするが...

それはそれとして、ネットワークI/O周りの性能のグラフは、見ててなかなか楽しい。

【セキュリティ】 Toward a Boot Odometer 【TPM】

In 2006 IEEE Workshop on Information Assurance.
http://www.itoc.usma.edu/workshop/2006/index.htm

あるPCが何回ブートしたかを記録する記録計の提案。

遠隔PCがリブートしたふりして実はリブートしないで情報を盗む攻撃への対策。
リブートすれば揮発性メモリの内容は消えるが、リブートしないと残る場合がある。
なので、本当にハードウェア的にリブートしたのかどうかの情報は重要。

TPMを使って実現。CPUが信頼できなくても大丈夫な枠組み?よく理解してないが。

リブートしたようにみせてリブートしないことを利用する攻撃なんてあまり考えたことないけど、軍で利用するような、がちがちの高セキュリティシステムにしようと思ったら、そういうことも考えないといけないのかもなあ。

【セキュリティ】 Towards Protecting Sensitive Files in a Compromised System 【ファイルシステム】

In SISW '05.

Secure Virtual File System (SVFS)の提案。VMMを使った安全なデータストレージ。sHype風味。

ミシガングループ。といってもチェンさんは絡んでない。

センシティブなファイルを一つのゲストOSの中におく、アプリケーションは別のゲストOSで走らせる。ファイルアクセスはVMをまたがることになるので、そこでアクセス制御する。

ファイルシステムを含んでるゲストOSがアクセス制御するので、悪意の者がアプリケーションを乗っ取っても、アクセス制御をバイパスできない。

どのVM(ゲストOS)からファイル要求が来たかによってアクセス制御する。

実装はXenベース。要するにDom0のゲストOSが他のVMのファイルサーバー(NFSサーバみたいなイメージ)になるってやり方。Dom0でローカルで動いているExt3がSVFSの実体。

各ゲストOSのカーネルにはSVFSファイルシステムが登録される。Dom0でSVFSサーバが動く。SVFSファイルシステムが、SVFSクライアントとしてはたらく。

VMMがアクセス制御するアプローチももちろんある。VMMでなくDom0でアクセス制御する利点は、ディスクブロックレベルではなく、ファイル要求レベルでポリシーを強制できること。

標準的なRPCにかわるVirtual RPCを提案。VM間でのデータのやりとりが速い。

ルートキットを用いて実験。ルートキットがセンシティブなファイルを更新しようとしたがブロックできた。

NFSでread-only mountとかCD-ROM mountするから安全ですよ系の研究と言えようか。実に直球の研究という気がします。

VMMならではのイシューや要素技術があるかどうかが鍵。VRPCとかVMの認証あたりがそれになるのかな。

【ストレージ】 Self-Securing Storage: Protecting Data in Compromised Systems 【セキュリティ】

In OSDI 2000.
http://www.usenix.org/events/osdi2000/strunk.html

攻撃対策機能を内包したストレージSelf-Securing Storage。
不正なファイル改ざんなどを発見して元に戻すなどの処理をするための機能が入っている。

といってもやることは単純で、要求を全部記録するような、log-structuredなストレージにするってこと。記録を利用して管理者は攻撃解析やリカバリを行ってくださいと。

このストレージはOSを信用しない。従来のOSレベルでの攻撃対策は、OSが乗っ取られたら、無力化やバイパスされてしまうことが普通だった。このストレージを使うと、たとえOSを乗っ取っても、バイパスすることは難しい。

どうやって攻撃と判断するかなどの運用面は主眼ではなく、性能オーバヘッドを小さくするという技術チャレンジに主眼があるようだ。確かにオーバヘッドはそれほど大きくない。

それより記録量が爆発してディスクがあふれることが心配になる。本論文によると、他の研究では、一日百数十MBを消費するとの報告があるという。なるほどこの程度なら、100GBを準備すれば500日はもつ。



【仮想化】 A Feather-weight Virtual Machine for Windows Applications 【Windows】

In VEE '06
http://www.ecsl.cs.sunysb.edu/fvm/index.html

Windows上でSoftwarePotのようなFreeBSD jailのようなSolaris ContainersのようなLinux VServerのようなものを実現.

資源はcopy-on-writeで複製するので省資源ですむ。このへんはAlcatrazにも似ている。

仮想環境はsystem callの仮想化によって実現。Windowsなのでptraceやら/procやらは使えない。SSDT patchingとIAT書き換えでsystem callをフック。

LinuxなどのUNIXでこの手の話が出てきたら、やや「またか!」という気分にもなるが、Windowsでやった点がなかなか興味深い。

【ディペンダブル】 On the Challenge of Delivering High-Performance, Dependable, Model-Checked Internet Servers 【モデル検査】

In HotDep'05.
http://hotdep.org/2005/

ディペンダブルなサーバの構築に向けての取り組み。

題材はSSH v2。安全なSSH v2サーバを作る。

OCamlで実装してバッファオーバフローを排除する。
サーバがポリシーに従うことを静的にモデル検査で保証または動的検査で強制する。サーバの動きをオートマトンで表現して、それを検査。ポリシー記述には、C-likeな文法で非決定性有限オートマトンを表現するドメイン特化言語を利用。

ちょっと読んだ感じではSekarらのMCCに近い感じ。

SSHではなくメールサーバ・クライアントですけど、このへんも似た仕事をしてるかも。

【セキュリティ】 e-NeXSh: Achieving an Effectively Non-Executable Stack and Heap via System-Call Policing 【システムコール・スタック検査】

In ACSAC 2005.
http://www.acsa-admin.org/2005/abstracts/103.html

プロセス乗っ取り攻撃を防御する手法の提案。

すべてのlibc関数呼び出しとシステムコール呼び出しを監視する。カーネルの修正と共有ライブラリによって実現。

libc関数が呼び出されたときに、正しい呼び出し履歴になっているかどうか、プロセスのスタックのコールチェインを検査。システムコールが呼び出されたときに、それが正しい場所から呼び出されているかどうかを検査。

プログラムバイナリとその逆アセンブル結果を利用。

かなりオーソドックスな手法に見える。今までに提案されていなかったのかなと思ったが、提案されていないのかもしれない。もしくは実験で示された高い有用性が評価されたか。もちろん関連研究は山のようにありそう。

システムコールが呼び出されたときに、プロセスのスタックの呼び出し履歴を検査して攻撃を検出する他の研究としては、これとかこれがあります。

【セキュリティ】 WORM vs. WORM: Preliminary Study of an Active Counter-Attack Mechanism 【ワーム】

In WORM '04.
http://www.icir.org/vern/worm04/

ワームのデータを変換して、そのワームを除去するための「アンチワーム」を自動生成する手法の提案。アンチワームは、対応するワームが感染しているホストからそのワームを除去してホストを正常な状態に戻す。Codered, Blaster, Slammerワームに対して、アンチワームを生成する実験を行った。

ワームを除去するためのワームを作ってばらまこうって研究は遅くとも2000年付近からはあった気がする。ワームコードを解析・変換してアンチワームを自動生成するって点が新規?

タイトルにもある通り研究はまだ予備的段階という感じ。ていうか目標がかなり野心的なので、汎用的に使える技術が編み出せるのかどうか自体がまだわからない。

| ホーム |


 BLOG TOP  » NEXT PAGE


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。