プロフィール

大山恵弘

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

最近の記事

最近のコメント

最近のトラックバック

月別アーカイブ

ブロとも申請フォーム

ブログ内検索

RSSフィード

リンク

FC2カウンター

スポンサーサイト

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

【VM】 Parallax: Managing Storage for a Million Machines 【ストレージ】

In HotOS 2005.
http://www.usenix.org/events/hotos05/final_papers/warfield.html

VMのための分散ストレージParallaxの提案。

VMイメージのディスクブロックを提供するサーバを提供。
クラスタ内の各ノードがサーバを実行。
サーバを専用VMの中で動かす(Xenのdom0のようなもの?)。
ディスクへの要求を、専用VMに転送。

ディスクブロックをローカルマシン上にキャッシュして性能を上げる。
コピーオンライトなどを利用して、VM間でディスクブロックを共有。
ディスクブロックを複製してavailabilityとdurabilityを実現。
VMイメージへのアクセスが競合しないことを利用して、排他処理を除去。

Xenのblock tapを利用してプロトタイプを実装。

定石通りにやるべきことをやっている感じ。
既存の分散ディスクブロックストレージをVMイメージ提供に利用したってだけじゃん、って言われないように、VMならではのイシューの説明に紙面をしっかり使っているところは見習いたい。

Machine Bankに似てるかも。

VMのためのストレージについては、こことかここでも研究してます。
スポンサーサイト

【セキュリティ】 Strider GhostBuster: Why It’s A Bad Idea For Stealth Software To Hide Files 【ルートキット】

MSR Technical Report 2004.
http://research.microsoft.com/rootkit/

ルートキットなどの悪性プログラムはファイルの存在を隠すことがある。隠されたファイルを見つける手法・ツールの提案。

まず、普通にブートしてファイルのリストを取得。次に、Windows PE(KNOPPIXのようなブータブルCDのWindows版?)でブートして、OSの外側からファイルのリストを取得。二つのリストの差を取ることにより、隠されているファイルを発見する。

【セキュリティ】 A Safety-Oriented Platform for Web Applications 【VMM】

In IEEE Security and Privacy 2006.
http://www.cs.washington.edu/research/networking/security/

XenのVMの中でブラウザを実行することにより、ブラウザを隔離環境で安全に実行。Browser Operating System (BOS)の提案。BOS上でブラウザを動かす。単に、VMでsandbox作りましたって話にとどまらない技術を提案している。

ブラウザ間、ブラウザ・ホストOS間の隔離に加えて、webアプリケーション間の隔離。

Webサービス側がwebブラウザをカスタマイズして、各ブラウザがどのサイトにアクセスできるかを制御。WebサービスがBOSにmanifest(セキュリティポリシー?)を提供。

まだちゃんと理解していないけど、VMware ACEのようなもの?

このタイミングでXenの応用を作って論文出してくるところはすごいし、Xen sandboxをブラウザやwebアプリに絡めて新ストーリーにするってあたりもうまい。

こういうの読むと一時的には少しへこむんだけど、長期的には、負けてらんないっていう元気も出てくる気がする。

仮想環境をサンドボックスとして利用する試みとしては、たとえばこことかこことかがあります。

【仮想化】 VXA: A Virtual Architecture for Durable Compressed Archives 【データフォーマット】

In FAST 2005.
http://www.usenix.org/events/fast05/tech/ford.html

データ圧縮アルゴリズムは時とともに移り変わる。今持っているデータのデコーダは、将来のOS上にも提供されるかどうかわからない。

データ圧縮アルゴリズムに比べると、プロセッサの変化はゆっくりである。

そこで、デコードが必要なコンテンツとデコーダプログラムを貼り付けたものを保存しておく方式の提案。プロセッサがx86でありさえすれば、デコーダプログラムは動くので、そのコンテンツはデコード&利用できる。

本方式では、デコーダはOS独立なx86環境上(VXA仮想マシン上)で実行される。その環境上で動くプログラムは、非常に限定された動きしかしないプログラムにコード変換される。そのため、デコーダのOS依存性は弱まり、また、悪意のデコーダからホストOSを守れる。

システムコール呼び出しはVMMの呼び出し(仮想システムコールの呼び出し)に変換される。準備している仮想システムコールは5つのみ。ファイルは、標準入力、標準出力、標準エラー出力しか使えない。VM内で動くプログラムは、標準入力からデータを読んで、デコードして、標準出力にデータを書くくらいのことしかできない。

コード変換はx86-to-x86。やってることはJavaのJITコンパイラやprogram shepherdingに似てる感じ。

自分の持っているコンテンツをデコードするためのデコーダが、インターネットのどこを探してもないってことが、将来起こりうるかどうか。

大抵のデコーダは探せば見つかるだろとか、VMMを導入するほどのことか、といった突っ込みはあるかもしれない。でも、新たなテーマを開拓しようとしている本研究の姿勢はいいなって思うし、基本的には、好きな方向性の研究です。コード変換やサンドボックス方面で技術的におもしろそうなネタをたくさん含んでそうだし。

データとコードを一緒くたにアーカイブすることにより、OS依存性を小さくしたり安全性を高めたりする研究としては、たとえば、ここがあります。

【IA-32】 IA-32 Execution Layer: a two phase dynamic translator designed to support IA-32 applications on Itanium-based systems 【バイナリ変換】

In MICRO-36 2003.

IA-32の命令列をItaniumの命令列に動的に変換することにより、IA-32アプリケーションをItanium上で実行することを可能にするソフトウェア層IA-32 ELの話。

IA-32 ELはWindows上でもLinux上でも動く。ユーザレベルのみで動く。ハードウェア支援不要。

二段階JITコンパイル。第一段階は最小限の最適化の単純なバイナリ変換を行い、hotspotを知るためのinstrumentationを埋め込む。第二段階はinstrumentationで得た情報にもとづいて、最適化を効かせてhotspotをバイナリ変換。

IA-32 EL自体はOS独立バイナリ。OS独立部分とOS依存部分をきれいに切り分けて作られているのがポイント。

正確な例外処理などのフィーチャーもあり。

90年代末のJavaの論文を読んでいるような、青春がよみがえってくるような、デジャブ感満載の論文。

Rosettaが出てきたりして、この分野もコンスタントに注目は集めている。
あるアーキテクチャ上で別のアーキテクチャをエミュレーションによって動かしたときの性能は現実的なのか非現実的なのか。3年後、5年後はどうか。

PCの性能もコアの個数もCPUエミュレータの賢さもグングン上昇するとして、こういうシステムの将来は果たしてどうなるのか、今ぼわっと考えています。

【OS】 SWAP: A Scheduler with Automatic Process Dependency Detection 【プロセススケジューリング】

In NSDI 2004.
http://www.usenix.org/events/nsdi04/tech/zheng.html

プロセス間の依存関係を自動的に検出。それを利用してスケジューリングを行う。システムコール履歴を利用して、プロセス間のありうる資源依存関係を決定。依存関係には、信頼度の情報を付加。プロセスのブロックの挙動をもとに依存関係情報は動的に調整。

このへんでも、プロセスの依存関係を自動的に検出して、それを仮想化などに利用するなどの研究してます。

| ホーム |


 BLOG TOP 


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