プロフィール

大山恵弘

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

最近の記事

最近のコメント

最近のトラックバック

月別アーカイブ

ブロとも申請フォーム

ブログ内検索

RSSフィード

リンク

FC2カウンター

スポンサーサイト

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

【仮想化】 Solaris Zones: Operating System Support for Consolidating Commercial Workloads 【ホスティング】

In LISA 2004.
http://www.usenix.org/events/lisa04/tech/price.html

最近私が大注目してるZone。

一言で言えばFreeBSD jailのパワーアップ版。
jailに比べて何がすごいのか、短い言葉で言えと言われると、困るのだけれど。

いわゆるjailをzoneと呼んでる。だから仮想機械じゃなく仮想OS。
Solarisのインスタンスをいっぱいつくれる。
実環境がglobal zone。仮想環境がnon-global zone。
狙ってる用途はサーバのconsolidationみたい。
マイグレーションを意識しているかどうかは不明。

スキルが低い人でもzoneを管理できるようにすることを目指している。
そもそも、zoneの中からは、ほぼ普通のSolarisが動いているように
見えるので、管理は簡単。

Zoneを作ったり、zoneの中のOS instanceをブートしたり、
zoneの中にログインしたりなど、zoneを制御するための
コマンド集がある。適切にコマンド打てばいいので、
スキル低くても、zoneを管理できる(たぶん)。

zonecfgとかzonepathというコマンドで、どんなzone作るかの設定が
できるようだが、詳しい情報はこの論文にはない。

各zoneは別々のrootパスワード、別々の管理者を持つ。

ファイルツリーはzoneごとに別のものが作られる。Chroot風に。
でも、外のファイルをSolaris loopback mount file system (lofs)
でzoneの中にもってこれるので、コピーは少なくてすむ。
初期作成時のzoneは60MBくらい。

プロセス空間も切れてる。Zoneをまたがってシグナルは送れない。
/procの下も、自分のzone内のプロセスのエントリしか見えない。

Global zoneからはnon-global zoneの下のプロセスや資源は見える。

Zoneの中では、実行できるシステムコールが制限される。
カーネルモジュール挿入とか、デバイス作成とか。

普通のUNIX(global zone)ではプロセス0はsched。
non-global zoneでは、プロセス0はzsched。
zschedは、プロセス木の根としての仕事のほか、
zoneごとの情報を保持する役目も果たす。

各zoneからは最低一つの論理ネットワークインタフェースが見える。

Zoneごとの資源消費制御機能あり。
Global zoneの管理者が、各zoneの資源消費制御&制限を決める。
各zoneの管理者は、zone内での資源消費制御&制限を決める。

Linuxのcapabilityに似た権限分割機能あり。

Accountingとauditingについても何かちゃんとやってるようだが、よく読んでない。

オーバヘッドは最大4%くらい。

既存技術と比べてのzoneのポイントは、
商業アプリケーションを処理する能力である、
と主張しているように読める。
それはもっと具体的に言うと何?
低オーバヘッドの仮想化?アカウンティング機能?

たしかに、FreeBSD jailでホスティングするより色々なことが楽に
できそうな気がするし、VMM使うよりも軽そうな気はする。
管理者は(ていうか今後の世界は)、zoneみたいな仮想OSを選ぶのか、
XenみたいなVMMを選ぶのか、興味ある。もちろん共存の道もあるかも。

技術的な面では、目の覚めるような新規性は感じなかった。
でも、奇をてらわず地道に普通の設計して、使いやすそうなシステムを
バランスよく組み上げたって点は、高く評価すべきだと思います。
個人的に、好きなタイプの研究です。

仮想環境をポコポコつくってホスティングなどに利用するっていう他の研究として、
SoftwarePotとか、
薄い層による軽い仮想環境(by 横山くん)とか、
Quasarとか、
VEEMLとか、あります。
スポンサーサイト

【形式手法】Hob: A Tool for Verifying Data Structure Consistency

In CC 2005 tool demonstrations.
http://cag.csail.mit.edu/~plam/hob/

プログラムの実装が仕様を満足していることを検証する静的検証フレームワーク(SPINみたいなもの?)。

あと、プロシージャ呼び出しの前条件と後条件がどうとか。

データ構造の操作の検証をしやすいのが売り?

それともモジュール化されたプログラムの検証で、モジュールごとの検証結果をあとからくっつけられるのが売り?
(よくわかってません)

いろいろプラグイン入れられる。フラグプラグイン、シェイプ解析のためのPALEプラグイン、定理証明プラグイン、など。

システムはOCamlで作られてます。

検証した最大のプログラムは、2000行の実装と500行の仕様からなるベンチマーク。

たまにこういうグダグダな記事もまぜていきます。

雑記スレッド

雑記スレッド作りました。

本題と関係ない内容はこちらへ。

【tamper-resistance】 A Generic Attack on Checksumming-Based Software Tamper Resistance 【セキュリティ】

In IEEE Security and Privacy 2005.

http://www.scs.carleton.ca/%7Epaulv/papers/pubs.html

コードのバイト列のチェックサムを計算してコード改変を検出する方式がある。本論文はその方式への攻撃の指摘。UltraSPARC, x86を含む最近のプロセッサの高機能が攻撃を支援する。

1. 攻撃者は元のプログラムのコピーを作る

2. 元のプログラムを好きに改変する

3. カーネルモジュールを入れるなりカーネルパッチを当てるなりして、カーネルを修正する。その結果カーネルに攻撃コードが入る。

4. 攻撃コードは、改変されたプログラムとコピーされたプログラムの両方を物理メモリに置く。データ読み出しをリダイレクトする。

カーネル改変可能という仮定が攻撃者にとってはちょっと厳しいかも。

リダイレクト処理は仮想記憶をこねくって実装(よく読んでない)。最近のプロセッサの仮想記憶機構をうまく用いると、データとしてのメモリ読み出しと、実行のためのメモリ読み出しで、読まれる内容を変化させることができる。

PowerPC, AMD64, Alpha, ARMにも適用可能。

新しいこと考えれば、性能評価なくても、一流の学会に通りますってことを見せつけられるような論文。

【リカバリ】 Treating Bugs as Allergies: A Safe Method for Surviving Software Failures【チェックポイント】

In HotOS X (2005).

落ちるなどの障害がプログラムに発生したら、最近のチェックポイントの時点までロールバックして再実行。そのときに、実行環境を少し変化させる。「実行環境」には、メモリ管理の実装やプロセススケジューリングなども含む。障害が出なくなったら、そのまま実行を継続。再び障害が発生したら、またロールバックして、別の変化を適用して再実行。

バッファオーバフローが発生したら、メモリブロックにパッドを入れて再実行するとか。ダブルフリーによる障害が発生したら、フリーされたバッファの再利用を遅らせるようにして再実行するとか。スケジューリングを変えて、並行バグを出なくさせるとか。攻撃とおぼしきユーザの入力をドロップするとか。

リカバリ指向コンピューティングは再起動一辺倒。さらに、アプリケーションプログラマがリカバリを意識してプログラムを記述する必要がある。本研究は、ヒューリスティクスで自動リカバリしましょうってあたりは共通。ちがうのは、再起動以外の手段も取ること。また、アプリケーションはレガシーでもよい。

チェックポイント&ロールバックをセキュリティに使おうという発想は好きです。障害をどう検出するかではなく、検出後にどうするかに注目しているあたりも、時流に乗ってる感じでいい。実行状態を変えて再実行して、バグを出なくさせるという路線も、野心的でいいと思います。

ただし、この手の研究では、最低限以下の2つの質問に答えられる必要があると思います。

(1) 障害があるとわかっているプログラム動かし続けるのはいかがなものか。

(2) アプリケーション独立な手段だけによる障害からの自動リカバリには、限界があるのではないか。

うちの研究室では、吉野くんが自己修復型リファレンスモニタ、尾上くんがセキュリティシステム保護のためのサンドボックス、横山くんがチェックポイントシステムという感じで、似た方向性で各自おもしろい話題を扱っています。bibはこのへん

【IDS】 Automatic Synthesis of Filters to Discard Buffer Overflow Attacks: A Step Towards Realizing Self-Healing Systems 【autonomy】

In USENIX Annual 2005.
http://seclab.cs.sunysb.edu/seclab1/pubs/papers.htm

サーバを攻撃するような入力データのフィルタを自動生成する。どんな入力文字列が攻撃で、どんな入力文字列が善良か?その判断基準を、アプリケーションの過去の実行履歴情報を用いて、自動的に生成する。

サーバをモニタしながら動かす。入力処理時には、入力データの長さと実行コンテキストが記録される。実行コンテキストとは、現在の実装では、スタック内の全リターンアドレス。

入力処理を行う際に、以下の方法で、その入力が攻撃かどうかを判定。過去の正常な実行の同じ実行コンテキストにおいて処理された入力文字列長の最大値bmaxと、現在入力されようとしている文字列の長さaを比較。aが長ければ、現在の入力は攻撃。

後の実行では、攻撃と判断する文字列長の閾値を、bmaxとaの中間の値に変更。

攻撃と判断された入力は、単にdropする。そして、サーバには、ネットワークエラーとして観測させる。そうすると、サーバが適切な後処理(資源解放とか)を実行するので。

いわゆる動作の学習を使うIDS。その手のIDSのポイントは、プログラムの「状態」をどう表現するか。

最も単純には、システムコール列だけで表現。IDSの古典。

次に単純には、スタックやシステムコール引数の情報も使って表現。過去5年、かなりはやった。私も何本か論文書いた。

入力文字列の長さを使うってアイデアは、たしかに、これまでになかったかもしれない。まあ、システムコール引数の情報を使うIDSの1インスタンスと言えなくはないのだけれど。

あと、正常と異常の閾値を動的に変えるってあたりが、他のIDSにあんまり見られない特徴かもしれない。

【仮想機械】 SoftUDC: A Software-Based Data Center for Utility Computing 【ホスティング】

In IEEE Computer, November 2004.


http://www.hpl.hp.com/research/papers/2004/SoftUDC.html


VMMを使って、サーバ、ネットワーク、ストレージを集中管理しましょうといういわゆるutility computingの話。HPのVMMであるSoftUDCについて。SoftUDCはたぶんsoftware-based utility data centerの略。

論文ではなくて雑誌記事なので、気楽に読める。それでいて、VMMがホスティングに何をもたらすのかについては、だいたい網羅されているように思う。

既存研究と一線を画す、SoftUDCならではの新しい内容があるかどうかは、よくわからなかった。

以下詳細。

VMMとしてはXenを使用。

当然ながら、OSどうしはisolateされる。performance isolationについての考慮もあり?

SoftUDCコントロールシステムが全VMMにまたがり、サービスの配置などを行う。あるVMの上で動いているmanagement OSがサーバ、VMM、ネットワーク、ストレージを管理。

仮想ストレージデバイスと実ストレージデバイスの間にマッピングを作れる。

仮想ネットワークもあり。IPトラフィックでなくイーサフレームをカプセル化。こうするとどんなプロトコルも使えるので。

VMのマイグレーションもあり。VMがマイグレーションするときには、仮想ストレージデバイスのアクセスポイントが動く。実データは動いたり動かなかったり?

Automatic managementのサポートもあり。自動かつオンラインでのアップグレード、パッチング、システムソフトウェアの再設定がサポートされている。

自動オンラインアップグレード。OSのコピーを作る。コピー先のOSをアップグレードして、パッチあてたら、コピー元からコピー先にアプリケーションを移動させる。アプリケーションの透明な移動にはZap風の仕組みを用いる。

負荷が下がったVMは別の物理ノードに移すことにより物理資源を解放するとか、その逆とかの話もあり。

私もこのへんすごく興味あって、最近は、「仮想実行環境を管理するためのライブラリ」なんて発表したりしてます。

Quasarにもかなり関係してるかも。

| ホーム |


 BLOG TOP 


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