大山恵弘ブログ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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周りの性能のグラフは、見ててなかなか楽しい。

In 2006 IEEE Workshop on Information Assurance.
http://www.cse.buffalo.edu/~ashish/research.html

Windows XPのGUI動作を学習して異常検知。

シェルコマンドを使った異常検知はたくさん研究されているが、GUIコマンドについても異常検知が必要という問題意識。

マウスの動き、クリック、キータイプ速度などを利用。

サポートベクタマシンを利用して特徴ベクタを学習、分類。

GUIに関する公開されたデータセットはないので、研究室のユーザ3人を対象にログを収集。

いかにも既存研究ありそうな気がする研究だが、確かにたくさんある。差分は、たくさんのGUI情報を扱うことと、認証でなくなりすまし検出に使っているところらしい。

In IEEE ISSSE 2006.
http://www.cs.princeton.edu/~appel/papers/

SafeJNIの提案。アッペルさんの最近の研究。

JNIを使ったときにJavaの型安全性をバイパスできるような抜け道をidentifyした。

・Javaの世界からもらったリファレンスはJNI APIを使って操作されることを期待されている。しかしそれにしたがわず、リファレンスをいじったりたどったりすれば、想定外の領域をアクセスできる。
・JNI API関数の関数テーブルを上書きされてしまう。
・Cのコードは、Javaの世界からもらった配列の添字を超えてアクセスできる。
・Cのコードはヒープのどこでも読めるので、privateみたいなアクセス制御機構が効かない。
・JNIではmalloc/freeのような感じで明示的にメモリ管理をするので、ダングリングポインタ、多重フリー、メモリリークなどのバグが入る。
・JavaからCに来る時点で、どんなオブジェクトも単一の型に変換されるので、Javaの世界とCの世界で型が合わないことがある。
・Cの世界からJavaの世界のオブジェクトをアクセスするときには、型を意識して適切な関数を呼び出さなければならない。
・Cの関数からJavaの関数を呼び出せる。呼び出しから返った後には例外の検査などが必要。それをしないと予期しない結果になる。
・Cの世界にはJavaのセキュリティマネージャの制御が及ばない。

解決。

・CCuredをJavaハンドルポインタと読み出しオンリーポインタで拡張（？）した型システム。JNIに関連するinvariantを静的に強制。リファレンスをいじられて変なとこ触られたり、関数テーブルを上書きされることを防ぐ。

Javaハンドルポインタは、読むことも書くこともできない（JNI APIに渡される）ポインタ。

読み出しオンリーポインタは、そのポインタが指す領域に書き込みできないポインタ。Cで言う、ポインタのconstみたいなもの。

・動的検査の挿入。配列境界、アクセス制御、例外などの検査。

・安全なメモリ管理。メモリ領域に有効タグをつける。確保したらセット。フリーしたらクリア。タグがクリアされてる領域をフリーしようとしたら二重フリーと判断。

あまり奇をてらわず、スタンダードな感じ。

In ADEAC 2006.
http://www.sid.org/conf/adeac2006/adeac2006.html

リモートデスクトップの規格が乱立しているので統一しましょうという呼びかけ。

現在のリモートデスクトップシステムは動画の性能とか反応速度に問題があると指摘。また、一つのOSにしばられるなどの互換性の問題があると指摘。

性能をどうやって改善するのかってところに興味がある。読んでみると、どうやら、統一規格を作ればグラフィックスハードウェアの助けを借りられる可能性が出てくるので、性能が上がりますよって話のようだ。

私が不勉強だっただけかもしれないが、論文そのもの以上に、ディスプレイ専門の学会組織があるってことのほうに興味をひかれた。

Technical Report.
http://virtuoso.cs.northwestern.edu/

リモートディスプレイシステムの最適化。投機的リモートディスプレイを提案。広域環境での利用を意識。

リモートディスプレイサーバから来るイベントをクライアントが予測して、先に実行しておく。予想通りそのイベントが来たらそのまま。予想がはずれたら、ロールバック。

予測は、過去のイベント列からk次のマルコフモデルを作ることによって行う。

実験にはrdesktopを利用。ワード、パワポ、IEなどを実行。ユーザイベントトレース中には、6万8千から11万2千個のイベントを含む。スクリーンイベントトレース中には、250万から440万個のイベントを含む。非常にナイーブな予測方式ですら、25%から45%の確率で次のイベントを当てることができた。

In ICS '06.
http://www.ics-conference.org/2006/program.html

ハイパフォーマンス計算にFailure-Oblivious Computingを適用しましたみたいな話。

対象は数値計算。
普通、プログラムにエラーやフォールトが発生したら、そのプログラムを終了させる。

提案手法では、計算をタスクブロックに分割。エラーやフォールトが発生したタスクブロックは、単純に見捨てて、残りのタスクブロックで計算を続行させる。

こんなことしたら計算結果がめちゃくちゃになりそうだが、サンプリング実行の結果をうまく組み合わせると、誤差の上限を与えられるような確率モデルが得られますって話。

Jadeっていうメタ言語を使ってプログラムをタスクブロックに分割。
まずは正しい結果が出るとわかってる入力を与えて、入力と出力を記録。

次に、タスクブロックをわざとフェイルさせてみて、それが与える誤差の度合いを見る。それにもとづいて、タスクブロックをクリティカルとフェイラブルに分類。

そして今度は、フェイラブルなタスクブロックをわざとフェイルさせてみて、それが出力に与える誤差を計測。

最後に、タスクのフェイル率を受け取り、計算結果に加わる誤差を見積もって返すような確率モデルを得る。

計算の一部が落ちたり異常動作することを仮定してシステムを作ろうって方向の研究は好きです。なんか定量的に結果が出てるあたりも、研究としてうまいなあと思います。

ひとつ疑問としては、90年代末のグローバルコンピューティングとかメタコンピューティングで、こういう研究ってなかったのかな。

Failure-Oblivious Computingという最近の駒と、元々の土俵である（と思われる）ハイパフォーマンス計算をうまくブレンドさせている点で、味わい深い。

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

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

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

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

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

In ITICSE '05
http://portal.acm.org/citation.cfm?doid=1067445.1067591

Bochsを使って、入出力プログラミングの教育を行いましたという話。

MS-DOSのクローンであるFreeDOS（パブリックドメイン）と、
ボーランドのTurbo C（フリー）を使った。

将来はQEMUも評価してみるそうだ。