fc2ブログ

プロフィール

大山恵弘

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

最近の記事

最近のコメント

最近のトラックバック

月別アーカイブ

ブロとも申請フォーム

ブログ内検索

RSSフィード

リンク

FC2カウンター

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

In HotOS X (2005).

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

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

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

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

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

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

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

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



<< 【tamper-resistance】 A Generic Attack on Checksumming-Based Software Tamper Resistance 【セキュリティ】 | ホーム | 【IDS】 Automatic Synthesis of Filters to Discard Buffer Overflow Attacks: A Step Towards Realizing Self-Healing Systems 【autonomy】 >>


コメント

コメントの投稿


管理者にだけ表示を許可する

 BLOG TOP