In HotOS X (2005).
落ちるなどの障害がプログラムに発生したら、最近のチェックポイントの時点までロールバックして再実行。そのときに、実行環境を少し変化させる。「実行環境」には、メモリ管理の実装やプロセススケジューリングなども含む。障害が出なくなったら、そのまま実行を継続。再び障害が発生したら、またロールバックして、別の変化を適用して再実行。
バッファオーバフローが発生したら、メモリブロックにパッドを入れて再実行するとか。ダブルフリーによる障害が発生したら、フリーされたバッファの再利用を遅らせるようにして再実行するとか。スケジューリングを変えて、並行バグを出なくさせるとか。攻撃とおぼしきユーザの入力をドロップするとか。
リカバリ指向コンピューティングは再起動一辺倒。さらに、アプリケーションプログラマがリカバリを意識してプログラムを記述する必要がある。本研究は、ヒューリスティクスで自動リカバリしましょうってあたりは共通。ちがうのは、再起動以外の手段も取ること。また、アプリケーションはレガシーでもよい。
チェックポイント&ロールバックをセキュリティに使おうという発想は好きです。障害をどう検出するかではなく、検出後にどうするかに注目しているあたりも、時流に乗ってる感じでいい。実行状態を変えて再実行して、バグを出なくさせるという路線も、野心的でいいと思います。
ただし、この手の研究では、最低限以下の2つの質問に答えられる必要があると思います。
(1) 障害があるとわかっているプログラム動かし続けるのはいかがなものか。
(2) アプリケーション独立な手段だけによる障害からの自動リカバリには、限界があるのではないか。
うちの研究室では、吉野くんが自己修復型リファレンスモニタ、尾上くんがセキュリティシステム保護のためのサンドボックス、横山くんがチェックポイントシステムという感じで、似た方向性で各自おもしろい話題を扱っています。bibは
このへん。
スポンサーサイト
コメントの投稿