わかりやすく伝える技術

わかりやすく〈伝える〉技術 (講談社現代新書) 池上 彰

凄く参考になった、でも発表の練習をちゃんとしないとだめですね。
他人にわかり易くつたえるノウハウを説明している。
内容の面白い。

私の映画リスト

私の中で印象に残っている映画。近年が数が減っているなあ。

公開日	題名	監督	主演	感想
1951	白痴	黒澤明	森雅之 三船敏郎 原節子	純粋な愛に応えられない人
1953	ローマの休日	ウィリアム・ワイラー	オードリー・ヘプバーン グレゴリー・ペック エディ・アルバート	ラストが悲しい
1954	ゴジラ	本多猪四郎	宝田明 河内桃子 平田昭彦 志村喬	モノトーンが迫力を増す。 戦争の残滓が。
1957	喜びも悲しみも幾歳月	木下恵介	佐田啓二 高峰秀子	普通の人の精一杯の生き方
1961	用心棒	黒澤明	三船敏郎 仲代達矢	超一級娯楽作品 音楽、カット 全てカッコイイ 三船敏郎は偉大
1963	古都	中村登	岩下志麻	岩下志摩が美しい
1964	博士の異常な愛情または私は如何にして心配するのを止めて水爆を愛するようになったか	スタンリー・キューブリック	ピーター・セラーズ ジョージ・C・スコット	現実はこの映画よりお笑い種だということを認識させられる
1966	大魔神	安田公義	高田美和	勧善懲悪
1966	ミクロの決死圏	リチャード・Ｄ・フライシャー	スティーヴン・ボイド ラクエル・ウェルチ	子供の頃の夢
1967	日本のいちばん長い日	岡本喜八	三船敏郎 黒沢年男 笠智衆	唯一の日本の戦争映画と呼べるもの
1968	猿の惑星	フランクリン・Ｊ・シャフナー	チャールトン・ヘストン キム・ハンター ロディ・マクドウォール	ラストシーンでびっくり
1968	2001年宇宙の旅	スタンリー・キューブリック	キア・デュリア ゲイリー・ロックウッド ダグラス・レイン	最高の映画。 なにもかも凄い どれだけの映画に影響を与えたか計り知れない
1973	燃えよドラゴン	ロバート・クローズ	ブルース・リー	これを見て柔道を始めた。
1976	タクシー・ドライバー	マーティン・スコセッシ	ロバート・デ・ニーロ ジョディ・フォスター	ラストが米国的だ。 音楽が夜の紐育にピッタリ
1977	未知との遭遇	スティーブン・スピルバーグ	リチャード・ドレイファス フランソワ・トリュフォー	ETに会いたい
1978	ゾンビ	ジョージ・Ａ・ロメロ	デビッド・エンゲ  ケン・フォリー	幼児体験の恐怖が蘇る。 台詞が哲学的だ
1979	エイリアン	リドリー・スコット	シガニー・ウィーバー	映画館で見て非常に怖かった
1979	地獄の黙示録	フランシス・フォード・コッポラ	マーロン・ブランド マーティン・シーン ロバート・デュヴァル デニス・ホッパー	本当のワルキューレを見たような気がする。
1981	レイダース 失われたアーク《聖櫃》	スティーブン・スピルバーグ	ハリソン・フォード カレン・アレン ポール・フリーマン	超一級娯楽作品 スピード感がよい
1981	死霊のはらわた	サム・ライミ	ブルース・キャンベル	怖い
1982	遊星からの物体X	ジョン・カーペンター	カート・ラッセル	クリーチャが凄い
1982	ブレードランナー	リドリー・スコット	ハリソン・フォード ルトガー・ハウアー ショーン・ヤング	音楽がよい。 レイチェルが美しい。 チューリングテスト。
1983	ライトスタッフ	フィリップ・カウフマン	サム・シェパード スコット・グレン エド・ハリス デニス・クエイド フレッド・ウォード ヴェロニカ・カートライト バーバラ・ハーシー ランス・ヘンリクセン	男の世界だ。 最後がカッコイイ。
1983	時をかける少女	大林宣彦	原田知世	不覚にも壺にはまった。
1985	バタリアン	ダン・オバノン	クルー・ギャラガー ジェームズ・カレン ドン・カルファ	オレは死んでいるのか? 面白すぎる。
1987	ヘルレイザー	クライブ・バーカー	アンドリュー・ロビンソン クレア・ヒギンス アシュレイ・ローレンス ダグ・ブラッドレイ	おどろどろしい世界観だ。
1988	ビートルジュース	ティム・バートン	マイケル・キートン アレック・ボールドウィン ジーナ・デイヴィス ウィノナ・ライダー	超一級娯楽作品 ウィノナ・ライダーが可愛い
1989	いまを生きる	ピーター・ウィアー	ロビン・ウィリアムズ イーサン・ホーク ロバート・ショーン・レナード	青春映画
1989	その男、凶暴につき	北野武	北野武	本当に凶暴だ
1989	ブラック・レイン	リドリー・スコット	マイケル・ダグラス 高倉健 松田優作 アンディ・ガルシア	松田優作最高だ なぜ死んだ!!!! もっと映画に出ろよ!!!
1990	チャイニーズ・ゴースト・ストーリー2	チン・シウトン	レスリー・チャン ジョイ・ウォン	偽坊主のお経のリズムが面白い
1991	ゼイラム	雨宮慶太	森山祐子	超一級娯楽作品 イリアが可愛い
1992	許されざる者	クリント・イーストウッド	クリント・イーストウッド ジーン・ハックマン モーガン・フリーマン	耐え忍ぶ男。 怒りが爆発。 悲しい。
1993	フォーリング・ダウン	ジョエル・シューマーカ	マイケル・ダグラス	壊れていく男の恐怖。
1995	セブン	デヴィッド・フィンチャー	モーガン・フリーマン ブラッド・ピット	なんて映画だ。
1995	ヒート	マイケル・マン	アル・パチーノ ロバート・デ・ニーロ	市街戦が凄い。 皆シブイ!
1995	セント・オブ・ウーマン・夢の香り	マーティン・ブレスト	アル・パチーノ	男のプライド。 青春映画でもある。
1996	マーズ・アタック！	ティム・バートン	ジャック・ニコルソン グレン・クローズ アネット・ベニング ピアース・ブロスナン	超一級娯楽作品 火星人が面白すぎる、死に方も
1997	タイタニック	ジェームズ・キャメロン	レオナルド・ディカプリオ、ケイト・ウィンスレット	ラストで不覚にも泣いてしまった。
1999	ファイト・クラブ	デイビッド・フィンチャー	エドワード・ノートン ブラッド・ピット ヘレナ・ボナム＝カーター	男の強さって何?
2003	マッハ!!!!!!!!	プラッチャヤー・ピンゲーオ	トニー・ジャー	本当の肉体派
2006	父親たちの星条旗	クリント・イーストウッド	ライアン・フィリップ ジェシー・ブラッドフォード アダム・ビーチ	戦争って何だよ 兵隊って何だよ 今もイラク、アフガニスタンで継続している。
2009	アバター	ジェームズ・キャメロン	シガニー・ウィーバー ゾーイ・サルダナ サム・ワーシントン スティーヴン・ラング ミシェル・ロドリゲス ジョヴァンニ・リビシ	第一級娯楽作品 ビジュアルな世界観が凄い。 ストーリーは不問。

ラクガキマスター

ラクガキ・マスター 描くことが楽しくなる絵のキホン 寄藤文平

楽しい本だ。
私は絵が下手なので絵が上手い人は無条件に尊敬する。
この本は書店で見つけて速攻で買ってしまった。

この本にはいろいろラクガキ(イラスト)を書くノウハウが書いてある(らしい)。
私のようなレベルの人間にはこの内容が描ける技術がないのが残念だ。
でも、この本を机の上に置いておいて、仕事に疲れたらちょっと見て息抜きをする。
そんな見方で十分楽しい。
ここに書かれている絵を見ているだけでも楽しい。
いつか自分が上手く描ける日を夢見て。

著者は、今日のようなインターネット全盛の今こそ、文字では伝えられない"何か"を「ラグガキ」で伝えよう と呼びかけている。
まったく同感だ。

ソフトウェアの自動修復パッチ生成・展開システム ClearView

ソフトウェアのエラーを修復するパッチを自動的に生成・評価・適用するシステム。
これだけだと非常に眉唾な感じがするが、論文を読むとちゃんとした技術だ。
あまりに、面白かったので、論文を全訳した。
ただし、英語力は弱いので意味の通じない文は、原文を読んで下さい。

論文 Automatically Patching Errors in Deployed Software ========================================================================V2.2
Automatically Patching Errors in Deployed Software
Jeff H. Perkins(a), Sunghun Kim(b), Sam Larsen(c), Saman Amarasinghe(a),
Jonathan Bachrach(a),Michael Carbin(a), Carlos Pacheco(d), Frank Sherwood,
Stelios Sidiroglou(a),Greg Sullivan(e), Weng-Fai Wong(c),
Yoav Zibin(g), Michael D. Ernst(h), and Martin Rinard(a)
a)MIT CSAIL, b)HKUST, c)VMware, d)BCG, e)BAE AIT, f)NUS, g)Come2Play,
h)U. of Washingtonjhp@csail.mit.edu,mernst@cs.washington.edu,rinard@csail.mit.edu

概要
我々は、自動的にエラーを修復するClearVireシステムを開発した。
ClearViewは、Windowsx86上でソースコードもデバッグ情報やその他の特別な情報無なしのバイナリに対して動作する。

ClearViewは、
(1)対象アプリケーションの正常動作を観察し、正常動作を特徴付ける不変式(invariants)を学習する。
(2)不変式は正常状態と異なるエラーを検知するために使用される。
(3)エラー発生中に違反した((1)で学習した)不変式を識別する。
(4)不変式が真となるように、制御フローや状態(レジスタ、メモリ内容)の矯正を行う修復候補パッチを生成する。
(5)修復候補パッチを適用したアプリケーションの実行を観察して一番効果のあるパッチを選択する。

ClearViewは、高可用性要求のソフトウェアのエラー修復のために設計された。ClearViewは、人の介在なくパッチを生成する能力、アプリケーションを再起動する必要なくパッチの適用と削除を行う能力を持つ。 パッチを適用したアプリケーションの動作を継続的に観察することで無効なパッチや危険なパッチの識別と破棄を行う。
CliearViewは、Redチームによって、セキュリティ脆弱性を利用した攻撃を乗り切る能力を評価された。
敵対的な外部のRedチームは、１０のexploitコードを開発し、それらのコードでClearViewで保護されているアプリケーションを繰り返し攻撃した。
CliearViewは、すべての攻撃を検知し防御した。
１０のexploitコードの内７つが、ClearViewが自動的に生成したパッチによりエラーを修復し、そのアプリケーションが攻撃を乗り切り、正しく処理を継続した。
最後に、Redチームは、ClearViewが望まないパッチの適用を試みたが、ClearViewのパッチ評価機構は、無効かつ危険なパッチを識別し破棄した。

1.導入
ClearViewは、高可用性要求により開発された、自動エラー修復パッチ生成・展開システムである。 過去の研究はエラーをどのように検出するかが示されていた。(例えば、バッファオーバフローの監視、不正な制御遷移、他の誤った動作など) [19, 31, 21]
標準的な戦略はアプリケーションを終了させることであり、本質的には全てのエラーはサービス停止を引き起こしてしまう。 多くの重要な場面において、システムの可用性は重要な要件である。 それらの場面において、エラーが発生してもサービスが継続提供可能であることは重要の要件である。
ClearViewは、商用パッケージソフトウェアの未知のエラーを自動的に修復することができる。 ClearViewは実行中のアプリケーションに対して、再起動や動作不安定引き起こすことなくパッチを適用する。 それは人の介在を必要しない。
そして、ソースコードもデバック情報も必要としないWindows x86のバイナリで働く。

図1は、ClearViewの5つのコンポーネントのアーキテクチェアを示す。 
  図1 ClearViewアーキテクチャ 

学習(Learning):
ClearViewは、動的にアプリケーションの正常動作を観察し、その正常実行状態を特徴付けるモデルを推論する。 モデルは、不変式(invatiants)と呼ばれる(レジスタやメモリ内容の観測時の値)属性の集合である。 不変式とは、常に正常動作中に充足されている条件のことである。 ClearViewは、アプリケーション実行状態を観察するほど正確なモデルを作る。 現状のClearViewの実装では、学習コンポーネントは、拡張されたDaikon[14]を使用している。

監視(Monitoring):
ClearViewモニタは、故障(failures)を検出し、その時に実行状態がエラー/正常か区別する。 エラー実行状態の場合、モニタは故障が検知されたバイナリ上の場所を示す。 ClearViewは、任意のモニタを組み込めるように設計されている。
現在の実装では、2つのモニタが使われている。

Heap Guard: メモリの領域外書込を検知する。
Determina Memory Firewall: 不当制御フローを検出する商用プログラム。[21]

各モニタは、故障を検知したとき、アプリケーションを停止することによって影響の拡散を防止する。 現状のモニタは、正常実行をエラー実行と判定するような、擬故障(false positives)は決して無い。 しかし、指定された種類のエラーのみ(ヒープバッファオーバーフロー、不当制御フロー遷移)を検知するように設計されている。 ClearViewは、モニタが検知する全ての故障を取り除くようには設計されていない。

関連不変式の識別(Correlated Invariant Identification):
モニタが故障を検知した時、ClearViewは、故障が発生した近傍で、事前に学習した不変式の状態を調べるパッチを適用する。 これらの不変式を確認するパッチは、エラー修復やエラー削除を意図するものではない。 この目的は、エラー実行状態、正常実行状態を特徴付ける相関不変式の集合を見つけることである。 

候補修復パッチの生成(Candidate Repair Generation):
各相関不変式に対して、ClearViewは、それらの不変式を矯正する修復パッチの集合を生成する。 それらのパッチは、不変式を再度充足させるために違反した不変式のレジスタやメモリの値を変更する。制御フローが違反した場合は、観察された不変制御フローになるように制御フローを変更する。
これらの修復は、エラーは違反した不変式を矯正することでエラーを訂正することができるという仮説に基づく。 目標はエラーが発生してから、その影響が拡散して回避不能な故障となる前に、修復パッチを見つけることである。 この目標を達成のために、ClearViewは十分初期のうちに発生するエラーを検知し修復しなければならない。

候補パッチの評価(Candidate Repair Evaluation):
パッチは効果が無いか、パッチされたアプリケーションが悪影響を受けるかもしれない。従って、ClearViewはパッチを適用したアプリケーションの実行を継続的に監視する。 パッチを適用したとき、アプリケーションの故障やクラッシュの発生状況から各パッチをランク付けする。 ClearViewは、最もランクの高いパッチを適用することで、悪影響を最小限にしようとする。 実際に、これらの戦略は修復パッチ適用後の正常実行に影響を与える可能性を最小限にする傾向あった。 我々は、アプリケーション保守者（彼らが存在するならば）が不具合に対しソースコード（それがまだ存在するならば）の欠陥を見つけて除きたい場合があることを知っている。
ClearViewは、故障についての以下の情報を提供することで、この活動を支援する。
・故障発生場所
・関連する不変値
・各修復候補パッチが不変式を充足させるために使用した戦略
・各々のパッチの効果に関する情報
この情報は保守をより迅速にし、発生した欠陥の理解と修復作業を支援する。
一方、自動生成されたClearViewパッチは、サービスを継続して提供するためにアプリケーションがエラーを乗り越えることを可能する。 ClearViewは、失敗(また成功)から学ぶ概念で設計されている。 このプロセスは、生物学的な免疫システムと同様に、ClearViewのパッチの品質を時間とともに改善していく。
ClearViewは最初に故障を検知し、アプリケーション上での故障(検知)場所を学習する。 この情報は、ClearViewが以降の計測と修復が効果的になりそうな場所を限定する。 以降の故障の度に、ClearViewは改変された変数とデータ構造と違反した不変式を学ぶ。この情報によって、ClearViewはエラーを修復するパッチ候補を生成する。 そして、ClearViewはパッチを適用する。
ClearViewは、パッチが適用されたアプリケーションが処理を継続すると、各パッチの効果を評価するための情報を取得する。 この評価機構は、故障を取り除くことができるパッチを適用するまでの間、効果のないパッチや危険なパッチが適用されることを抑止する。

1.1 Redチームによる評価
DARPAのApplication Communities program (www.darpa.mil/IPTO/programs/ac/ac.asp)の一環として、ClearViewを評価するための、独立した対抗RedチームをつくるためSparta Inc.を雇った。そのゴールは、ClearViewのセキュリティ脆弱性を取り除く効果を評価することである。
我々はClearViewの人の介在なしに迅速かつ自動的にパッチ生成と評価を行う能力が以下の要求に役立つと考える。
- 脆弱性を標的とする攻撃に対して素早く自動的に応答する
- 人間による対応(保守者がパッチ開発と配布に平均28日間かかる)によるタイムラグ短縮
ClearViewによって保護された、全て同じ(Firefox)ソフトウェアが動作しているコンピュータ共同体(アプリケーションコミュニティ)でRedチームの実験が行われた。 共同体メンバが協力して攻撃情報を学ぶ、それらの情報は数台が攻撃された後、全てのメンバ(攻撃を受けていないメンバも)へ免疫を供給するための情報として使う。 また、共同体は、効果的なパッチを入手するために要する時間を短縮する。

Redチームの実験では、１０のexploitコードを開発し、そのexploitコードを繰り返し共同体攻撃に使用した。 結果は以下である。

防御:
ClearViewは全ての攻撃を検知しアプリケーションを守った。

成功した継続的実行:
１０のexploitコードの内７つexploitコードに対してClearViewは自動的にパッチを生成し適用した。 パッチは根本的なエラーを修復し、攻撃中にアプリケーションの実行を成功させることができた。 ClearViewは自動的に１０のexploitコードのうちの７つのために、根本的なエラーを訂正し攻撃に対しても正常に実行することができるパッチを生成し適用した。 残りの３つのexploitコードうち２つは、ClearViewの構成を変更し、同様にうまくいくパッチを自動生成することができた。

パッチ品質:
ClearViewは、幾つかの候補修復パッチを、故障を取り除けないか、新たな悪影響(パッチを適用したアプリケーションをクラッシュさせるような)を導くようなパッチであると評価した。 ClearViewのパッチ評価機構は、それらのパッチを識別し破棄する。
Redチームは、正常な入力で、Firefoxが異常処理を行うようなパッチを検出できなかった。

誤検知が無い:
RedチームはClearViewの検知誤りを引き出すことはできなかった。
特にRedチームは、攻撃が無い状態で、ClearViewに対してパッチ適用を行わせることが出来なかった。 我々の技術は自動的に、致命的なエラーや攻撃から乗り切ることで、エラーとセキュリティ脆弱性でいっぱいの世界で、コンピューティング基盤の堅牢さと可用性を向上させると考える。

1.2 構成
この論文は以下の構成である。
学習:
Windows x86のストリップされたバイナリ上で、不変式を自動的に学習するために、どのように正常動作を自動的に観察するか示す。

不変式とパッチ:
不変式の集合とエラーとセキュリティ脆弱性を自動的に検知し、エラーを修復できるパッチを識別する。

不変式選択とパッチ評価:
そのように、選択した有望な相関不変式の集合を矯正することで、エラーへの自動的な対応をするかを示す。 そして、どのように候補修復パッチを評価し、サービスが途切れることなく、アプリケーションがエラーを乗り切ることができるパッチを見つけるか示す。 パッチ評価機構が絶えずパッチの効果を評価するので、それらが最初に適用されてから長時間たって、それらが無効か有害なパッチか識別し破棄することができる。
アプリケーション共同体:
マシンの共同体が互いに1つのグループとして、エラーと攻撃を乗り切る為に働きアプリケーションの実行を継続する。

 Redチーム評価:
敵対するRedチームのClearViewの評価結果を示す。 結果は、Redチームが開発した１０のセキュリティexploitコードの内 ７つに対して、ClearViewは、アプリケーションが攻撃を乗り切り、処理を継続して実行できるパッチを生成したことを示す。 誤検知は無かった。Redチームはエラーや攻撃の無い時にClearViewがパッチを適用させることができなかった。

本質的強さ:
それは、単純な生き残り技術で、エラーが発生してもシステムが停止せず継続的な実行の可能性を増加させることで、大規模なソフトウェアシステムが、エラーと攻撃に本質的に強いという更なる証拠を提供する。
この経験的に観測された強さは、最も強力なソフトウェアを作り上げる生産的方法は、エラーが発生した場面で、アプリケションおよび(または)実行環境に対して、自動的に生残り技術を適用することで実行継続を可能にできる、ということを示唆する。
このアプローチは、既存の脆いプログラム言語と実行環境の上でバグ無しシステムを開発する標準的な試みと、際立った正反対の立場である。 それはまた、大規模ソフトウェアシステムの本質的な複雑が、エラー固有の局所化された変更の悪影響から、(これらのシステムを)保護することができるという魅力的な証拠を提供する。

2. ClearView実装
本節は図1でのClearViewのアーキテクチャの以下のポンポーネントの実装を説明する。 学習(2.2)、モニタ(2.3)、相関不変式識別(2.4)、修復パッチ生成(2.5)、修復パッチ評価(2.6)
我々は、ソフトウェア信頼性コミュニティから以下の概念上のフレームワークを採用しする。
欠陥(defect)とは、アプリケーションのソースコードの誤りである。
エラー(error)とは、アプリケーションが何かが正しくなく働いた(計算間違いなど)時に発生する。
故障(failure)とは、観測されたエラーでありアプリケーション仕様の違反が利用者に顕在化することである。
本論文では、故障をClearViewモニタによって検知されたエラーのみを含むと狭義に定義する。
そのほかに、アプリケーションを停止を引き起こすクラッシュ(crashes)がある。
残りのエラーの種類は例外(anomalies)である。
例外は、アプリケーション仕様違反がアプリケーションの停止を引き起こさず、モニタでも検知できないエラーである。
exploitコードは、アプリケーションの仕様違反を引き起こす１つの入力である。
攻撃とは、アプリケーションへのexploitコードの提示である。

2.1 Determinaコンポーネント
Determina Managed Program Execution Environmentは、妥当な時間とメモリオーバーヘッドで(バイナリコードレベルで)アプリケーションを修正せずに効率的・透過的・包括的な操作を行うためDynamoRIO4を使用する。
全てのコードは、外部から許可されたプラグインを使って実行される。
プラグインは、新しいコードブロックを確認し(もし必要なら)新しいコードブロックを"キャッシュ"に入る前に変換する。
プラグインは、過去にキャッシュへ挿入されたコードブロックを削除することができる。プラグインは、この機能を使って、動作中のアプリケーションに影響を与えずパッチの適用と削除を行うことができる。
ClearViewは、この能力を使って不変式の確認と矯正を行うパッチの適用と削除を行う。 

Determina Memory Firewallは、挿入されたコードが実行される前に、全ての異常な制御フロー遷移と実行を停止させる動作を検知する。 具体的には、コードキャッシュ内の命令がキャッシュの外のコードへジャンプを試みる時、Memory Firewallは、制御フロー遷移[21]の妥当性確認を行う。 妥当性確認をパスした遷移は、Managed Program Execution Environmentが、コードキャッシュ(任意の要求された命令か、パッチを適用した後に)内へ目的コードブロックをリンクし、そして、その目的コードブロックへ分岐してコードキャッシュからの実行を継続する。 このプログラムの実装は、バイナリコード挿入攻撃からクライアントアプリケーションを保護する。

Determina Management Consoleは、大規模な分散クラアントマシン集合の監視と制御を行うことができる。それは、パッチを格納する中央サーバで実行され、各クライアント上で動作しているDetermina Node Managerインスタンスと安全に通信する。 各Node Managerは、対応するManaged Program Execution Environmentインスタンス(動作中と新しく起動されたアプリケーションに対して、適切にパッチ適用そしてパッチ削除する)と連携する。 幾つかのClearView Management Consoleプラグイン(Management Console機能を基に)がクライアントとClearViewの連携を調整するために構築されている。 それらは、適切にClearViewパッチの適用と削除を行う。

2.2 学習
学習コンポーネントは、アプリケーションの正常動作を観察し、正常動作モデルを推測する。 このモデルは、観察された動作の全てで満たされる不変式集合を含んでいる。 各不変式は、アプリケーションの特定の命令で、常に満たされる1つの論理式である。ClearViewがバイナリを扱うので、式の変数はコンパイルされたバイナリレベルで意味がある値（レジスターと記憶場所の値）である。

2.2.1 Daikon
ClearViewは、学習コンポーネントとしてDaikonを使用する。
Daikonは、2つのコンポーネントから実装される:
動作アプリケーションからトレースデータを取り出すフロントエンドと、トレースデータを処理し不変式を推論する核推論エンジン。
Daikonは、もともとソースレベルの不変式の学習のために開発された。
ClearView開発の成果として、我々は新しいDaikonのフロントエンド(X86フロントエンド)実装するためにDetermina Managed Program Execution Environmentを使った。 新しいフロントエンドは、基本ブロックの命令を計測(それらがコードキャッシュに入った時、それらの実行の適切なトレースデータを出力するため)する。
トレースデータは、命令が読む全てのオペランドの値と、計算する全てのアドレスを含む。
例えば 命令 "mov [ebp+12], eax" は、メモリアドレス ebp+12の値をレジスタeaxへ移動する。この命令は、1つのアドレス(ebp+12)を計算し、1つのオペランド(このアドレスの値)を読む。 命令が実行される度に、ClearView計測器は、このデータを含むトレースエントリを作り出す。

2.2.2 不変式の変数と場所
与えられた命令のために不変式を推論する時、核Daikon推論エンジンは、幾つかの戦略で変数の集合を決定する。
第一に、変数集合は(目標エラー集合を訂正できる有意味な)不変式の推論が可能であるほど、十分大きくなければならない。
第二に、推論処理が計算的に扱い安くできるほど十分に集合は小さくなければならない。
最後に、不変式の値は全ての可能な実行(観測された実行だけでなく)で定義されていなければならない。
各機械語命令(この命令を目標命令という)において、核Daikon推論エンジンは目標命令自身か、目標命令を呼び出す上位手続きの機械語命令(手続きの呼出し元)のどちらかによって、手続きの命令(2.2.3参照)上で計算される全ての変数を対象に推論する。 各不変式は、目標命令が計算した1つの変数を含まなければならない。

2.2.3 手続き制御フローグラフ
命令呼出し階層を計算するために、ClearViewは、実行された各手続きに対して制御フローグラフを構築する。 グラフのノードは"基本ブロック"であり、Determina Managed Program Execution Engineによって決定される。辺は"基本ブロック間の制御フロー"を表す。 制御フローグラフ構成アルゴリズムは、静的/動的な分析組み合わせを使用する。
この分析は、手続きの入口点の静的(ストリップされたX86実行ブログラムでは複雑な仕事である)検索の必要性を削減する。 それは制御フローグラフのデータベースを維持する。各基本ブロックが最初に実行されるか判定することで、新しい手続きを見つける。基本ブロックが既知の制御フローグラフで記録されていないなら、アルゴリズムはその基本ブロックを新しい手続きの入口点と想定する。 それから、基本ブロックの中で動的に跡をたどって、この新しい手順の呼出し階層フローグラフを造るために記号実行を使う。 新しい手続きのエントリ基本ブロックは、最初の基本ブロックとして使う。記号実行のアルゴリズムは、"手続きの終わり"を復帰命令か、分岐先が計算することができない間接分岐命令で判断する。
このアルゴリズムが、1つの静的手続きを複数の動的な手続きへ分解する可能性がある。 実際には、そのような手順分裂が頻繁に起こるというわけではない。 唯一の潜在的な欠点はこの方法で分割された手続きは、不変式推論エンジンが利用できる値の集合を減らすかもしれないことである。 そして、推論エンジンがその命令のために推論することができる不変式の集合を減ら可能性がある。 全ての制御フローパスが、最初に命令iを通って命令jに行くなら、命令iは命令jを支配する。 命令iが命令jを支配するなら、制御フローが命令jに到達するならいつでも、命令iは事前に実行されており、命令iで計算された全ての値は妥当である。

2.2.4 追加属性と最適化
ClearViewは、同じ手続きにおいて常に同じ値を持つ変数(それらの変数は、レジスタやメモリの値を示す)を識別するため制御フローグラフを分析する。
トレースデータから、その変数が最初に使われた命令を除き、その変数の出現を全ての取り除く。 この最適化は、不変式を推論する数(学習、不変式確認)を1/２に減らした。
他のClearViewの後処理は、スタックポインタオフセットを含む不変式を見つけるためにステップ分析する。 1つの手続きが割り当て・開放する局所変数と手続き呼び出しは、スタックポインタの値を変更する。 "sp1 = sp2 + c" のスタックポインタオフセット不変式は、手続きの入口点でのスタックポインタsp1と、その手続きでの変数ポインタでのスタックポインタsp2間の関係の結果から得る。 ClearViewは、この情報を、手続き呼出しを飛び越したり、外側の手続きに即時復帰するために、スタックポインタを適切に調整するために使用する。(2.5.1参照)
また、Daikon不変式の集合を、変数がポインタ値を持つ情報を含むように拡張した。 Daikonは、変数が負数か1～100,000までの値ならポインタ変数とは推論しない。それ以外はポインタ変数と判断する。 Daikonは、ポインタ変数を含む下限(lower-bound)不変式、上限(less-than)不変式の推論をスキップするために、これらの情報を使用する。 この最適化は学習、不変式確認、修復評価時間を減らす。

2.3 監視(モニタ)
ClearViewは、故障の検知と故障場所(故障が検知された時に命令のプログラムカウンタ)を提供する任意のモニタを組み込むことができる。現状の実装では、不当な制御フロー遷移を検知するためにMemory Firewall を使用している。 このモニタは常に動作中のアプリケーションで有効である。

Heap Guard:
モニタは、メモリの割当領域外アクセスを検知する。それは、割当られたメモリブロックの境界にcanary値を置き、全てのヒープ領域の書き込み時に書き込まれるメモリ領域がcanary値を含んでいるか確認する。 canary値の存在は、領域外書き込みか、(アプリケーションによる)割り当てられたメモリブロック領域内への正当なcanary値の書き込みのどちらかである。 Heap Guard がcanary値を検知すると、書き込まれる番地が割り当てられたメモリブロック領域内に存在するか確認するため、割り当てマップを検索する。 もし、存在すれば正常処理として続行し、もし存在しなければ、Heap Guardは、領域外書き込みを検知する。しかし、割り当てられたメモリブロック領域を飛び越えた書き込みは、領域外書き込みの検知に失敗する。
Heap Guardは、２つの点で便利である。第一に、領域外書き込みが検知できることで、結果的に不当な制御フロー遷移を引き起こさない。これはClearViewがMemory Firewallが検知できない領域外書き込みを検知できるようにする。
第二に、最終的に領域外書き込みが不当制御フロー遷移を引き起こしても、Heap GuardはMemory Firewallが検知するよりも早くエラーを検知できる。この早期検知は、成功パッチを見つけるClearViewの能力を高める。
Heap Guardは、アプリケーション実行に影響を与えることなく、動的に有効化/無効化できる。ClearViewは、例えば以下が可能である、アプリケーションが正常な実行の間は、Heap Guard無しで実行し、領域外書き込みエラーによる危険を上昇させる事象が発生したとき、Heap Guardを有効にする。

影のスタック(Shadow Stack):
ClearViewは、任意に補助的な影の手続きスタックを保持することができる。影のスタックはClearViewが呼出しスタックを追跡し故障場所を含む手続きの呼出し元の不変式を見つけることを可能にする。 これらの追加された不変式を矯正することは、ClearViewがエラーを修復するときに重要となる。
ClearViewが本来のスタックの解析を試みるより、影のスタックを利用するのには２つの理由がある。
第一に、幾つかの最適化(フレームポインタ削除、呼出し元/呼出し先の高度な最適化介入)は現実的には呼出しスタックを追跡を困難にする。
第２に、エラー(バッファオーバフロー)がスタックを上書きし、故障検知モニタを無効にしてしまう。影のスタックは、実際のスタック上の手続きアドレス保持をcall/return命令を計測することによって維持する。この仕組みは、効率的かつアプリケーションの動作に影響を与えず、有効化/無効化でするために、主にin-lineで実行される。

2.4 相関不変式の識別
故障場所が特定できた場合、ClearViewは、その故障に相関する違反した不変式の識別を試みる。相関不変式は２つの重要な属性を持つ。 第一に、それらは正常動作中常に充足されており異常時は充足されていない。第二に、故障が発生する前に、それらの不変式は違反している。
相関不変式を使うことで、正常動作環境(エラーを訂正でき、故障の取り除きとアプリケーションが正常動作を継続できる)へアプリケーションを戻せる。

2.4.1 相関不変式候補
ClearViewは、相関不変式候補の集合を入手するため、手続き呼出しスタックを使用する。モニタが故障を検知したとき、呼出しスタック上の手続きPの命令iであったと想定すると。手続きP上の命令iを支配する不変式は、相関不変式候補の集合である。 しかし、ClearView実装の最適化は、相関不変式候補の集合を制約する。 1つの不変式が２つの変数の値と相関しているなら、候補関連不変式の集合にその不変式を含むためには、不変式の命令は基本pブロックの命令iで起こらなければならない。 この制約は、不変式のチェックオーバヘッド(2.4.2)とClearViewが生成・評価(2.5)する修復パッチ候補の数の両方を大幅に減らす。実際に、この最適化は修復パッチの生成に影響せず、修復が成功するパッチを見つける総時間を減らす。
ClearViewは実質的に、効果のある修復を生成する相関不変式候補集合を確認するどんな戦略でも使用することができる。

3つの重要な考慮すべき問題
  1)有効な故障情報(現状の実装では、故障場所と可能であれば影のスタック情報を含む)による作業
  2)修復が成功するパッチ生成するために、十分大きな不変式の集合の作成 
  3)不変式を効率的にチェックすることが可能な不変式集合の大きさ制限(2,4,2)と、修復パッチ候補の評価(2.6)

影のスタックが利用可能でないなら、ClearViewは故障位置近傍の命令に相関している不変式で単に働くことができる。それはまた、互いに実行する傾向のある基本ブロック集団を学習する戦略を開発することが可能である。 そして、故障が発生した場所を含む基本ブロック集団からの不変式集合で働く。

2.4.2 相関不変式候補のチェック
ClearViewは、与えられた相関不変式候補の1つの集合で、各相関不変式候補が充足する/充足しないを決定するためのパッチ集合を生成し配備する。パッチは、その変数に相関する命令に到達した時、その変数の値を確認する。 パッチは、２つの変数が相関する２つの命令の第２番目の命令に到達した時、２つの変数の値の相関性を確認する。 不変式が第２番目の命令で確認されるとき、最初の命令に関連しているパッチは、後の検索のためにその変数の値を保存する。 パッチは、アプリケーションが実行されるときは常に、それぞれの不変式を確認する。確認は不変式とパッチ開発のきっかけとなる故障場所を識別する。それはまた、その不変式が充足する/しないを示す。この方法でパッチされたアプリケーションは、各不変式と故障場所の組み合わせた確認情報を生成する。

2.4.3 相関不変式の識別
モニタが故障を検知した時、ClearViewは以下のように、相関不変式候補の識別のために、不変式確認シーケンスを使用する。

非常に相関している:
1つの不変式が故障に非常に相関しているとは、モニタが故障検知する毎にその不変式が違反しており、他の全ての機会ではその不変式が充足している場合。
適度に相関している:
1つの不変式が適度に故障と相関しているとは、 モニタが故障検知する毎に、その不変式が違反しており、 モニタが他の故障を検知した時に高々1回、その不変式が違反していた場合。
僅かに相関している:
不変式が故障と僅かに相関しているとは、 モニタが故障を検知した高々1回で、その不変式が違反していた場合。
相関無し:
不変式が常に充足するなら、その不変式と故障とには相関は無い。

相関不変式は、それらがチェックされる毎回違反してる必要はない。 1つのシナリオとして、異常実行の最後の部分でエラー動作を顕在化する。 正常動作を示す最初の部分の動作の間、相関不変式は充足される。 2.5節で後述する候補修復生成段階は、実施する不変式の選択に格付けを使う。

2.5 候補修復生成
与えられた相関する不変式集合は、ClearViewが評価する候補修復パッチ集合を生成する。 各候補修復パッチは相関する1つの不変式に対応する。
最初に、修復パッチは不変式が違反していることを確認するように実装する。 もしそうなら、制御フローの変更/不変式の矯正(レジスタ値、メモリ番地の値を変更)をする。
ただ1つの変数を含む不変式のためのパッチは 、チェックと不変値操作を、その変数の命令で働かせる。複数の変数を含む不変式のためのパッチは、チェックと不変式操作を、対応する最後の命令で実行する。一般的に、1つの不変式の操作は複数の方法がある。
非常に相関した不変式が存在する場合、ClearViewの現状の実装では唯一それら不変式のために候補修復パッチを生成する。
非常に相関した不変式が存在しない場合、ClearViewは僅かに相関する不変式(存在すれば)のための候補修復パッチを生成する。 また、ClearViewが相関不変式の格付けを使うことによって、ClearView修復候補評価(2.6)が、対応する修復パッチのプライオリティ付けをして修復候補パッチを生成する。 ３つの不変式と対応する修復(Redチームの実験中に使われた)について次に説明する。

2.5.1 列挙型(One-of)不変式
列挙型不変式は v ∈ {c1,c2, . . . ,cn} の形式であり、ciは定数、vは1つの変数か式である。この属性は、変数vが実行中にとる全ての値を識別する。各観測値ごとに、以下の形式のn個の修復が存在する。
if ! (v == c1 || v == c2 || ... || v == cn) then v = ci

もし、アプリケーションがvを関数ポインタ(vはcall命令のターゲット)として使用するなら、単純にcallを飛び越える他の修復が存在する。
修復は、call *v を
if (v == c1 || v == c2 || ... || v == cn) then call *v
で置き換える。
不変式が違反している場合、修復はcallを飛び越える。

3つ目の修復は、呼出し元手続きに即時復帰する(実際のパッチでは、呼出し引数の削除と他のクリンアップを実施するためスタックポインタを調整する)
if ! (v == c1 || v == c2 || ... || v == cn) then return
この修復は任意の不変式のために使用できる、しかし、ClearViewは現状、列挙型不変式のために使用している。

論理的根拠:
列挙型不変式は、関数ポインタを使用する関数呼び出しのターゲットを特徴づける。 初期化されていないメモリの使用や、エラー関数ポインタを作る不正な型変換は、エラー関数ポインタを作ることができる。 多くのセキュリティ攻撃も、攻撃者は悪意のある関数ポインタを作成することができる脆弱さを利用する。 不変式の矯正による不当な制御フロー遷移の削除は、アプリケーションをエラーや攻撃を乗り切ることができる。

2.5.2 下限値(Lower-bound Invariant)不変式
下限不変値は、  
  c < v
cは定数 v は変数か式である。修復は以下の形式である。
   if ! (c <= v) then v = c
論理的根拠:
欠陥の1つは、配列やバッファの指標を負数にすることができる。 それは、アプリケーションが読出/書込するアドレスを、配列やバッファの先頭以下にすることができる。欠陥は、負数(大きな符号無し整数に調整して)を、memcpyなどの手続きへ長さとして渡すことができる。 メモリ複写の結果として、バッファの終わりを超えて書き込まれる。これらの結果は、下位値不変式(0 > v)を違反する典型的なエラーの結果である。 配列のバッファへ指標を戻す間接的な不変式の適用は、メモリ占拠を抑止し、そのアプリケーションがエラーから復帰を可能とする。

2.5.3 上限値( Less-than)不変式
上限値不変式は、
  v1 < v2
2つの変数や式と関連する。(下限値不変式は変数と定数の関係である)上位値不変式は、V2(下位境界不変式修復において)または、v1のどちらかを調整することで修復ができる。
修復は以下の形式:
  if !( v1 <= v2) then  v1 = v2
論理的根拠:
欠陥は配列・バッファの上位限界を超えた指標にすることができる。 配列・バッファの終わりを超えるアドレスをアプリケーションがアクセスすることができる。アプリケーションは、上限値不変式を違反することで、指標が、配列・バッファの上限を下回る必要があるという要求を捕える。 不変式の矯正は領域外の指標を、配列バッファの領域内へ戻す。 それは、メモリ改変を抑止し、そのアプリケーションがエラーから復帰を可能とする。

2.6 修復候補の評価
ClearViewは、最も効果的にエラーを修復し、アプリケーションを正常動作させるパッチを決定するため、各候補修復パッチを評価する。ClearViewは、パッチ適用した後、まだ故障が発生するか、新しい故障が発生するか、クラッシュするかを観察する。 ClearViewは、(とりあえず)修復後、失敗やクラッシュ無しで１０秒間アプリケーションが動作したらパッチは成功と判断する。修復は、修復採点を基本に評価される。
1つの修復が成功した時、その採点は加算される。
1つの修復が失敗した時、その採点は減算される。
ゴールは常に効果的な修復パッチを探すことである。 採点システムは常に成功する修復へ報酬を与えるように設計されている。 修復パッチが失敗するなら、システムは成功する修復パッチを探し続ける。
ClearViewは、以下の採点式を使う。
( s - f ) + b
s:成功した回数、fは失敗した回数、bは失敗しなかった場合のボーナス。

ClearViewは、同一スコア(例:一度も評価されなかった全ての修復パッチはスコアbを持つ)の場合以下のルールに従う。
初期修復パッチ優先:
ClearViewは、初期に実施された修復パッチを選ぶ。
基本ブロックや手続きにおいて、ClearViewは初期の命令から修復するものを選ぶ。ClearViewは異なる手続きの修復パッチ群の中で、呼出しスタックの下位(より初期に実行される)手続きの修復パッチを選ぶ。
この根拠は、最も早いエラーを修復することによって、エラー拡大を最小にすることである。

最小制御フロー変更:
制御フローを変更(即時復帰や、呼出しを飛び越したり)する修復は、状態に影響を及ぼす修復の後に優先する。1つの修復は1つの故障を取り除くかもしれないが、他の故障を露呈させるかもしれない。 この場合、ClearViewは、以下の処理を繰り返し行う。
  1)相関不変式を見つける。
  2)修復候補パッチを生成する。
  3)生成されたパッチを評価する。
ClearViewは、複数の不変式を矯正するため複数の修復パッチを生成する。Redチームの実験で、これらが実際に発生した。(4.4)
ClearViewは現在の手続きでは、成功する修復を見つけることができない場合、呼出しスタック上の各手続きに対して修復パッチの評価を繰返行う。

3.アプリケーション共同体
繰り返しエラーや攻撃にさらされる事によって、エラーや攻撃からどのように防御するのか学習する機会をClearViewへ与えるときはいつでも、我々の技術を適用させることが可能である。１つの適切な配備環境は、アプリケーション共同体である。
共同体は、同一のアプリケーションが動作しているコンピュータのグループであり、故障の検知と修復、そしてそれら自身を攻撃から防御することを協働する。
コンピュータ全体で、利用者に身近なソフトウェア環境を提供するので、このような単一環境は利用者に都合がよい。 利用者のデータと専門知識を、全コンピュータ基盤上で持ち歩けるようにする。それはシステム管理のオーバヘッドを削減するが、それらは攻撃者にも都合がいいかもしれない。
そして、攻撃者は共同体の至る所で一つの脆弱性を利用することができる。
ClearViewをアプリケーション共同体を保護するように構成することによって、我々はソフトウェア単一構成を弱点としてでなく、攻撃を無力化するための対抗策を強化する機会として見る。
アプリケーション共同体には以下の利点がある。
正確な学習:
学習コンポートネントは多くの異なる利用者、データセット、利用状況で働くことができ、不変式学習の確度を増加させ修復パッチの品質を向上させる。
学習オーバヘッドの軽減:
ClearViewは、各メンバがアプリケーションの小さな部分の学習を引き受けることで、共同体に渡って学習オーバヘッドを分散することができる。
高速修復評価:
共同体は候補修復パッチを並列して評価することで、成功するパッチを見つける時間を削減できる。
攻撃に晒されない:
幾つかの共同体メンバが攻撃され、ClearViewが成功パッチを見つけたら、そのパッチは共同体全体へ配布される。残りの共同体メンバは、攻撃を一度も受けなくても、その攻撃に対して免疫があるようになる。その上パッチはエラーを修復し、同じ脆弱性を利用した攻撃を乗り切るアプリケーションとなることが可能である。
ClearViewを実装したアプリケーション共同体アーキテクチャは、共同体マシンと共同体の動作を調整する中心サーバから成る。
各メンバのマシン上でDetermina Node Managerインスタンスが動作している。 中心サーバで動作しているDetermina Management Consoleによって、アプリケーションが動作しているメンバのマシンへのパッチ配布の調整と安全な通信(SSL)の提供をするManagement Consoleは、Node Managersへのパッチ配布の調整と、各マシン上のClearViewとセンターサーバ間の通信を仲介する。

3.1 譲渡型並列学習
我々は拡張したDaikonを、以下のように共同体のメンバ上で並列に働かせる。
各共同体マシンは、Daikonのローカル版が、そのマシン上で真である不変式を計算するためのデータを追跡する。 ClearViewは定期的に推論した不変式を中心サーバへアップロードする。 それらの不変式は、共同体の全メンバの実行環境全体で真である不変式のデータベースを更新するために使われる。 ClearViewは学習した不変式のみをアップロードする。 (ローカルDaikonが不変式の推論に使った生の追跡データではない。)
ClearViewは以下のように共同体メンバ全体の学習オーバヘッドを分散するように設計されている。
各共同体マシンは、追跡データ取得のために、アプリーケーショの"幾つかの手続き"を選択する。 その手続きのみを追跡データ生成のために計測する。残りのアプリケーションの手続きの実行は学習しない。(学習のオーバヘッドは無い) 実際に、アプリケーションの任意部分で学習することは、 各共同体メンバの学習オーバヘッドと、全体的な学習網羅性と許容できる不変式集合を入手する時間とのトレードオフを最適化する設計戦略によって、広範囲に渡る分散された学習戦略をとることができる。
1つの効率的な学習戦略は、すべての動作中のアプリケーションの微小部分を無作為に選択し、共同体の全てメンバから連続的に少しづつ入ってくる新し不変式を計測することである。 この戦略は、最新の利用パターンからの情報によって不変式の更新を維持することで学習オーバヘッドを最小にする。それはまた段階的学習を可能にする。
第一の学習段階は、それらが実行する入力と領域(典型的には手続き)を記憶する。 第二の学習段階は故障に対応するため、故障場所の近くの領域を計測する。 そして、これらの計測される領域を鍛える入力を再現する。
Daikonは、相関不変式の候補の集合を生成するため追跡データを処理する。 このアプローチの欠点は、故障への対応による学習は、成功パッチを手に入れるために必要な時間を増やすことである。 利点は、学習オーバヘッドの削減と、大きな不変式データベースの必要性を減らすことである。エラー時にどんな不変式でも破棄することは重要である。 現状実装されたシステムは、エラー時の不変式を単純に減らす。
より高度な戦略を適用することも可能である。 例えば、暫くの間、実行の好ましくない影響を明らかにするために十分な時間、新しく学習した不変式の編入を延ばす。
一定時間経過後に、好ましくない影響がシステムに現れないら、 その不変式を使って、センターの不変式データベースを更新する。

3.2 アプリケーション共同体管理
次に、ClearViewが故障の対応で共同体を管理する動作について説明する。
検知と故障通知:
共同体マシンの1つで動作しているClearView モニタは故障に遭遇すると、モニタはアプリケーションを停止し、Determinaの安全な通信機能で、中央ClearView Managerへ故障を通知する。 通知は故障場所と(可能なら)故障が発生した時の呼出しスタック情報を含んでいる。
相関不変式の識別:
中心のClearView Managerは、故障場所と呼出しスタック情報を使って、不変式データベースへアクセスし、相関不変式の候補を計算することで故障通知に反応する。 それら不変式を確認するＣコードの断片を生成・コンパイルして、不変式を確認するパッチを作る。 ClearView ManagerはパッチをDetermina基盤に提出する。 そして、Determina基盤は共同体のメンバ全員にパッチを配布する。 各メンバのDetermina Node Managersは、実行中のアプリケーションと、新しく起動されたアプリケーションへパッチを適用する。 パッチが実行されると、不変式確認の観測情報を生成しClearView Managerへ戻す。
2.4.3節で説明したように各観測は不変式を識別する。
故障はClearViewに不変式確認パッチの生成を引き起こし、不変式が充足されているか違反してるが判断する。
結果的に、1つ以上のアプリケーションに再度故障が発生するかもしれない。ClearView Managerは故障通知を受け取った時、不変式確認の観測結果(2.4.3節で説明した)を、相関不変式を求めるために分析する。 その後、Determina基盤を不変式確認パッチを削除するために使用する。 Determina Console Managerは、Determina Node Managersへ、マシン上で動作しているアプリケーションから不変式確認パッチを削除するよう命令する。 現状のClearViewは、不変式確認パッチを適用したアプリケーションから2番目の故障情報を受け取った時、このステップを実行する。 他の方式を実装することは容易である。
現状のClearViewは、影のスタックとHeap Guard監視を常に有効にしてアプリケーションを実行する構成である。 最初の故障が発生してから、それらの機能を有効にすることもできる。ClearViewが故障を取り除くパッチを見つけた後、または、共同体が一定時間内に１つの故障も発生しないと確認された時に元に戻すこともできる。

修復の生成と評価:
ClearView Managerは、相関不変式の全てに対して候補修復パッチを生成する。 不変式確認と矯正を行うＣコードの断片を生成しコンパイルする。 そして、Determina基盤をパッチを適用と削除のために使用する。 Determina Console Managerは、Determina Node Managersへマシン上で動作しているアプリケーションに対してパッチ(ClearView修復評価アルゴリズムを適切に実装する)を適用/削除するよう命令する。 理論的には、この修復アルゴリズムは、最終的に共同体全体(故障が発生していないアプリケーションを含む)へ適用する成功パッチを見つける。

多重並列故障:
共同体が同時に異なる故障に遭遇する可能性がある(Redチームはこのようなシナリオを実施した)。 すべてのClearViewパッチが特定の故障（故障場所によって識別される）に応じて適用される。 そして、すべてのClearView通信が最終的に対応する故障を認識する。 それが複数の異なる故障で発生する事象に対応するので、ClearViewはうまく共同体を運営することができる。

4. Redチームの演習
Redチームは、DARPAのApplication Communities program(www.darpa.mil/IPTO/programs/ac/ac.asp)の一端として、 DARPAに雇われたSparta,Inc.の独立した対抗するClearView評価チームである。 Redチームは11人の技術者集団である。 Redチームのゴールは、我々のアプローチよるClearViewの欠陥を見つけることである。Redチーム以外の演習の参加者は、Buleチーム(本論文の著者)、Whiteチーム(Mitre, Inc.の技術者)である。 Whiteチームは、交戦と仲裁ルールを定義した。
演習は2008/2/25-28 MITにおいて行われた。 演習中Redチームは１０のExploitコードを使ってClearViewで保護されたアプリケーション(Firefox 1.0.0)へ攻撃した。 それらの全てのExploitコードは、無防備なFirefoxでセキュリティ脆弱性を利用できることを確認した。
ClearViewは全ての攻撃を検知し防御し、攻撃が影響を与える前にFirefoxを終了したその上、ClearViewは１０のち７つの攻撃に対してパッチを生成することに成功した。 実際に、ClearViewの評価機構が効果的だと判断した全てのパッチは成功した。 アプリケーションは攻撃を乗り切り、攻撃後でもアプリケーションは正常に継続実行した。

4.1 評価ゴール
Redチームの演習の第一の目的は、バイトコード挿入(Exploitコード)攻撃を防御するClearView技術の効果を評価することである。 言い換えれば、攻撃はアプリケーションの制御フローを破壊しようと試みる(典型的には、アプリケーションの実行をダウンロードしたコードへ制御を移させる) 。もっと汎用的には、アプリケーションを権限の無い制御フロー遷移させる。 この特別な種類の攻撃は、それらは実際でも共通であり、もし成功すると特別重大な結果をもたらすので選択された。
Redチームの個別評価ゴールは以下である。
攻撃耐性: 
ClearViewが、アプリケーションを攻撃から防御し正常に継続実行可能なパッチを見つけることができるか判定する。
修復評価:
ClerViewが生成したパッチが、何らかの方法(正しい入力で異常動作を行うか、新しい利用可能なエラーが引き起こすこと)で、アプリケーションを悪化させるか判定する。
誤検知:
ClearViewのパッチ生成機構が正しい入力で発動してしまうか判定する。
基盤攻撃:
ClearViewのパッチ生成・配布機構が攻撃によって破壊されるか判定する。 本論文は、この質的な評価の詳細な結果を省略する。 しかし、要約するとDetermina製品（暗号化、認証、その他）ですでに実施されている標準的なセキュリティ対策は、この種類の攻撃から許容できるレベルの保護を提供すると判定された。

4.2 交戦ルール
交戦ルールは、Redチームの演習範囲を定義した。
- Redチームの攻撃はどのような種類に限定するか。
- 攻撃の成功/失敗をどのように判定するか。
- Redチームに与えらたBlueチーム情報へのアクセス範囲
Red,Blue,Whiteの各チームは互いに、Blueチームが防御するアプリケーション(改造されていないFirefox1.0.0のストリップされたX86バイナリ)を合意した。 Redチームは、攻撃用HTML、XUL、GIFファイルへFirefoxを誘導することによって、すべての攻撃を仕掛けた。
Firefox 1.0.0がこの演習で適切な幾つかの属性を以下に示す。
成熟したコード:
Firefoxコードは比較的成熟しテストされており、他の成熟したアプリケーションの正当な代わりとなると判断された。
脆弱性:
Firefoxのこのバージョンは、Redチームが無理に新しい脆弱性を発見する必要なく徹底的な評価をするのに十分な脆弱性を含んでいた。
ソースコード公開:
このアプリケーションのソースコードが公開されていた。 ClearViewはソースコードのいかなる情報を必要としないが、ソースコードはアプリケーションの動作の理解と、Redチームの演習中の観測された現象の解析を十分簡単にする。
自動化:
FirefoxはWebページの自動ローディングをサポートしていた。 これはRedチームの演習準備のための自動学習と演習において役立った。
高可用性要求:
将来に、利用者が必要とするアクセスしたいInternetコンテンツは、よりExploitコードを含むかもしない。(6.2) したがって、攻撃に遭遇すると(Exploitコードがあるコンテンツを除いてして)Firefoxを終了してしまうと、有用性は実質的に損なわれる。
Redチームの考えられる演習範囲と与えられた有効な資源から、より多くのアプリケーションを加えることは可能ではなかった。

4.2,1 攻撃範囲
Redチームの攻撃は３種類である。
  1) 制御フロー攻撃
  2) 自己免疫攻撃
  3) 誤検知攻撃
制御フロー攻撃は、アプリケーションの制御フローの破壊を試みる。
この攻撃は、制御フローが悪意あるコード(maliciou code)に到達するか、アプリケーションクラッシュを引き起こすことで、アプリケーションが後の入力を正しく処理継続することができなかったら成功したと判定される。
誤検知は、正しいWebページの読込みの反応として、ClearViewがパッチ適用することを引き起こした時、誤検知攻撃は成功したと判定される。
自己免疫攻撃は、ClearViewパッチ機構をアプリケーションに対抗するように変更を試みる。 この攻撃は、正しい入力(攻撃用入力でないもの)でアプリケーションの動作へ影響を与えるパッチが適用された場合成功したと判定される。
自己免疫攻撃は、パッチ版Firefoxが、正しいWebページを順に読み込んだ時、パッチされていないFirefox(同一ユーザ機能)同じ動作をしないとき成功したと判定される。
Redチームは、これらの制約の中で、完全に自由な攻撃ができる。
既知の攻撃、既知の攻撃の変形、順に異なるWebページをロードさせる攻撃は全て範囲内であった。 Redチームが攻撃を生成するとき、使うことが許された情報に制約がなかった。

4.2.2 Redチーム演習準備
Redチームが演習のするまでに、Blueチームは、既知のFirefoxの脆弱性に関連した１２のWebページを実験し不変式データベースを生成した。 学習は、それらの脆弱性に関連するアプリケーションの選択された領域に限定された。 Webページと不変式データベースはRedチームの演習する前に有効になった。 Redチームの演習の数カ月前、Blueチームは、ソースコード、ドキュメント(設計ドキュメント含む)、スポンサーへの提示資料、Blueチーム自身による弱点の分析の全てをRedチームへ提供した。
Redチーム演習に先立って、Blueチームは定期的にRedチームにソースコード、テストとドキュメンテーション最新版を提供した。 Redチーム演習の時点で、RedチームはBlueチームシステムのソースコード、テスト、ドキュメンテーションの全てへの完全なアクセスができた。
Redチームが演習中、Redチームは57の評価用Webページを選択した。 それらの正しいWebページは、Firefox機能範囲の確認、修復パッチの評価(パッチ版Firefoxで評価用ページが正しく表示されるか)、誤検知評価(任意の評価ページでClearViewのパッチ生成機構が駆動されるか)で使用された。 Redチーム演習前に、Blueチームには、それらのWebページは提供されない。
Redチーム演習のために、Blueチームは、すべてのマシンへFirefoxを配備し、マシンの小さな共同体を準備した。 Blueチームは、全てのFirefoxを、以下のClearViewの構成で実行開始した。
- Memory Firewall: 有効
- Heap Guard: 有効
- 影のスタック(Shadow  Stack): 有効
Redチームは、実験中この共同体を攻撃した。

4.3 攻撃評価
最初の演習段階は、Redチームの攻撃に対するClearViewの防御能力を評価した。
Redチームは、Firefoxの１０の欠陥を選択し、それぞれにつてい１つ以上のexploitコードを作った。
標的となった欠陥は、以下のエラーを引き起こす。
- チェックされないjavascript型
- 配列の領域外アクセス
- ヒープ、スタックのバッファオーバーフロー
- javascriptガベージコレクション欠陥
全てのexploitコードはFirefoxno脆弱性を、うまく活用することを確認していた。
Redチームは、以下の攻撃を行うためにexploitコードを利用した。

4.3.1 単一攻撃
各欠陥のために、Redチームはexploitコードを選択した。 そして繰り返し、共同体のFirefoxへexploitコードを提示した。 Redチームは、1つの攻撃に対するClearViewの対応が完了した時のみ新しい攻撃を行った。
ClearViewは、１０の全てのexploitコードに対して、対応する攻撃を検知し妨げた。

Bugzilla番号	提示回数	エラー型
269095	6	Memory Management
*285595	4	Heap Buffer Overflow
290162	4	Unchecked JavaScript Type
295854	5	Unchecked JavaScript Type
296134	4	Stack Overflow
311710	12	Out of Bounds Array Access
312278	4	Memory Management
320182	6	Memory Management
*325403	4	Heap Buffer Overflow

表1:数字は、ClearViewがexploitコードを検知しパッチを適用するまでに、そのexploitコードを含むWebページが提示された回数を示す。 *印の２つは、Redチーム演習中にパッチを生成できなかったが、後にClearViewの構成を変更してパッチを生成できたものである。


ClearViewは、７つのexploitコードに対して、Firefoxが攻撃を乗り切り、次の評価ページを正しく表示できるパッチを生成した。 Redチームは、パッチ版と非パッチ版Firefoxの違いを観測できなかった。 Redチームの演習(4.3.2)の後の調査で、残った３つのexploitコードのうち２つは、ClearViewの小さな構成変更で、パッチをうまく生成することができた。 表1は、ClearViewが攻撃からうまくFirefoxの実行ができるパッチを見つけて、適用するのに要求されたexploitコードを提示した回数を示す。 最小のexploitコード提示回数は4回である。
初回提示(攻撃)で、ClearViewはexploitコードに気づく。 ClearViewは候補相関不変式群を計算(2.4.1,2.4.2)することで反応する。 そして、相関不変式を確認するパッチを適用する。 次の２回目の提示(攻撃)の間に、ClearViewは相関不変式を計算するため、不変式の充足と違反情報を記録する。 それらの提示(攻撃)の後、ClearViewは不変式確認パッチを削除する。 そして、相関不変式を矯正するパッチを生成し適用する。(2.5,2.6)
もし、最初の相関不変式を矯正するパッチが成功していれば、ClearViewは４つのエラーを修復できた。
表1 は、290162, 296134, 312278,285595, 325403の欠陥のexploitコードからのエラーを最初のパッチで修復したことをと示す。
295854は最初のパッチではエラーを修復できなかった。 しかし、２番目のパッチで修復できた。 269095、320182は３番目のパッチが最初の成功パッチであった。
311710は別である、３つの個別の欠陥を含んでいる、各欠陥は同じ攻撃で利用される。 ClearViewは、4回目の提示の後、最初の欠陥からのエラーを修復した。 そして、攻撃は２番目の欠陥を利用する。 ClearViewは、この２番目の欠陥からのエラーを修復するため、別に４回の提示を必要とした。 そして、攻撃は３番目の欠陥を利用する。
ClearViewは、この最後のエラーを修復するため、別に４回の提示を必要とした。 Firefoxが攻撃を乗り切るためのパッチを入手するために、合計１２回の提示が必要であった。

スタック オーバーフロー:
296134は、文字列長の負数にする誤りを引き起こす。 この数値はmemcpyに渡され、非常に大きな符号無し数値として解釈される。 メモリ複写の結果、ダウンロードされたデータがスタック上の例外ハンドラを上書きする。 メモリ複写がスタック終端を超える時(ダウンロードされた)上書きされた例外ハンドラが実行される。
ClearViewは計算された文字列長が１以上となるように要求する1つの下限不変式を学習した。 ClearViewは、長さを'1'に矯正することで、この不変式を充足するパッチを生成した。このパッチは、スタック領域外への書込を修復し、Firefoxが攻撃を乗り切ることを可能にした。

未チェックjavascript型:
290162、295854は、ダウンロードされたjavascriptコードが、悪意あるコード(maliciousコード)とデータを含んだオブジェクトを生成する。 javascriptシステムルーチンは、オブジェクト型のチェックに失敗し、オブジェクトに対応するC++仮想関数呼出しを通してダウンロードされたコードを呼び出す。 ClearViewは、仮想関数呼出し元で、両方のエラーの選択(one-of)不変式を学習した。 これらの不変式は、呼出元が学習中に呼んだ関数のうちの1つを呼びだす。
ClearViewが修復評価中に適用した最初のパッチは、悪意あるコードに飛び込む代わりに、前回呼び出した関数を呼び出すように不変式を修復した。 このパッチは、290162を利用したエラーをうまく修復したが、295854を利用したエラーの修復には失敗した。 ClerViewは２番目に、呼出し命令(call)を飛び越すことで不変式を矯正したパッチを適用し、295854を利用したエラーをうまく修復した。

メモリ管理Exploitコード:
312278は、ダウンロードされたjavascriptコードが、誤ってガベージコレクションされるオブジェクトへのポインタを取得する。 そのポインタは、再配置されたネイティブFirefoxのC++オブジェクトを保持している。 ダウンロードされたjavascriptコードは、C++オブジェクトの仮想関数テーブルポインタの内容を(ダウンロードされた)悪意あるコードを指すように上書きする。ClearViewが選択(one-of)不変式を学んだ場所で、仮想関数呼出し元が悪意あるコードを呼び出す。
この不変式は、呼び出し元が唯一の関数だけを呼び出すことを示していた。
ClerViewが適用した最初のパッチは、前回呼び出した関数を呼び出すことでエラーが修復された。
269095 、320182 は、初期化されていない再配置メモリ領域を持つ。特定の条件下で、この非初期化メモリをC++オブジェクトと見なすことで、Firefoxを操作することができる。 そして、この非初期化によって1つの仮想関数が呼ばれる。
ダウンロードされたjavascripは、メモリが再配置される前に、適切に形式化された悪意あるコードとポインタを書き換えることで、 このエラーを利用することができる。 この場合では仮想関数が悪意あるコードを呼び出す。
ClearViewは、仮想関数呼出し元が悪意あるコードを呼び出すところで、選択(one-of)不変式を学習した。 ClerViewが適用したパッチの1つは、悪意あるコードが呼ばれる前に、呼出し元関数から復帰することで不変式を矯正した。 このパッチはFirefoxが攻撃を乗り切るのを可能にした。
ClerViewは、このパッチを試す前に、観測された関数の内の1つを呼ぶパッチと、その関数呼出し命令を飛び越し残りの処理を継続するパッチを試した。 これらの両方のパッチは、Firefoxが攻撃から回復しなかった。

配列領域外アクセス:
311710は、Firefoxに負数の配列インデックスを計算させる。 そして、配列からC++オブジェクトの取り出しを試みるためにインデックスを使う。 ダウンロードされたjavascripコードは、取り出されたメモリが、ダウンロードされた悪意あるコード指すポインタを操作した。 Firefoxが取り出されたオブジェクト上で仮想関数を呼び出すと、それはダウンロードされた悪意あるコードが呼び出される。
ClearViewは、配列インデックスが正数となることを要求する下限(lower-bound)不変式を学習した。
ClearViewは、配列インデックスを０にすることで、この不変式を矯正するパッチを適用した。 このパッチは、Firefoxが妥当なC++オブジェクトを取り出すようにし、仮想関数は正しいコードを呼出しFirefoxが攻撃を乗り切ることを可能とした。
このエラーを引き起こした欠陥は、３つの類似した手続き（明らかにコピー＆ペーストして作られた）に存在した。 これらの欠陥からの全てのエラーは、同様のパッチで修復された。

4.3.2 残ったExploitコード
Redチームの演習中、ClearViewは、Redチームの３つのExploitコードに対して修復パッチを生成できなかった。
285595は、使われていないNetscape のGIF拡張のためのコードを標的にしている。 このコードは、GIFファイルからとりだした値の符号をチェックしていない。 それはヒープオーバフロー攻撃に弱い。 Redチームの演習中、ClearViewの相関不変式識別コンポーネントは、スタックの一番下位の手続きの不変式のみを調べるよう構成されていた。 この欠陥に関連する不変式は、この手続きの1つ上の手続きで出現した。 従って、ClearViewは、このエラーを修正するパッチを作ることができなかった。
その後我々は、スタック上の上位手続きをの不変式も調べるようにClearViewの構成を変更し、このエラーを修復するパッチを生成することを確認した。
この相関不変式は、バッファインデックスを含む下限(lower-bound)不変式である。
修復は、インデックスを負数からゼロに矯正した、それによって領域外への書込をバッファ内へ戻した。 exploitコード自身がイメージファイル内に埋め込まれていたが、
その修復は攻撃を無効化し、Firefoxがイメージを正しく表示することを可能にした。

325403は、ダウンロードされたHTMLファイルが、２バイトUNICODE文字を保持するために、配置されたバッファに入らない程大きさを増すことができる。 整数の最大値に非常に近いバッファサイズを指定することによって、攻撃者はバッファサイズ計算を桁あふれさせることができる。それは、Firefoxが小さすぎるバッファを割り当てる原因になる。 引き続くmemcpyは、それから割り当てられたバッファの終端を越えて書き込む。
この攻撃は、演習で使われた学習サイトでは、Daikonが相関不変式を学習するための十分なカバレッジを準備できなかった。 その後我々は、拡張された学習サイトを使い、ClearViewが成功パッチを生成することができる不変式を学習したことを確認した。
相関不変式は、メモリをバッファへ複写するためのサイズに関連する上限(less-than)不変式である。 修復は複写サイズをバッファサイズに設定し、領域外書込を抑止する。

307259は Firefoxがソフトハイフンを含むホスト名を保持するバッファサイズの計算誤りを発生させる。 Firefoxが、このバッファへ幾つか項目を複写するとき、複写はバッファの終端を越えて書き込まれる。
この攻撃では、Daikonが推論した不変式では、エラーを捕らえるのに十分ではなかったため修復パッチは生成できなかった。
適切な不変式は、バッファ長と他のバッファ長の合計に関連していたので、Daikonの上限(less-than)不変式(2つの数に関連する)が生成されるべきであった。
十分な不変式の学習は可能であるが、学習コンポーネントのコストを増大させるだろう。

4.3.3 人間による修復との比較
人間による修復は、Redチームの実験で利用した欠陥にも有効である。
269095の人間による修復は、不当なオプジェクトの割り当て抑止をダグで表した。 以降のオブジェクト使用時は、このタグを確認しタグが不当ならエラーを返す。
また、全不当オブジェクトの関連するデータの再初期化を繰り返す。

285595の人間による修復は欠陥を含むコードを削除した。 このコードは、Netscape GIF拡張を実装していた。 人間による修復では、Firefoxからのこの拡張を削除した。

290162、295854の人間による修復は、javascriptオブジェクトの型を確認する。 もし確認が失敗すると、そのメソッド(または、オブジェクト上の1つのメソッドを呼び出す)は単純にnullを返す。

296134の人間による修復は、負数の文字列長を確認することを追加した。 もし確認が失敗すると、そのメソッドはエラーをログし復帰し複写を行わない。 人間による修復は、呼出しメソッドで文字列長の確認と割当バッファ長へ調整する。

311710の人間による修復は、アプリケーションが負数の配列インデックスの計算を引き起こす1つの条件を訂正する。

312278の人間による修復は、関連するオブジェクトへの参照を保持していることをガベージコレクタへ伝える。 ガベージコレクタがこの参照に1度気づくと、そのオブジェクトは回収されない。 オブジェクトを保持しているメモリは、javascriptには無効となる。

320182の人間による修復は、再配置オブジェクトを識別するフラグを設定する。続くコードはフラグを確認し、それらの再配置オブジェクトはきちんと初期化される。

325403のための人間による修復は、複写先配列が複写元配列のデータを保持するだけの大きさであることを確認する。 もし確認が失敗すると、大きな複写先配列を配置し複写を試みる。

人間による修復の幾つかは、エラーの近傍で一貫性確認を行う、そして確認が失敗すると、残りの処理はスキップする。 全てのClearViewのパッチは、同様な一貫性確認(不変式の充足確認)をエラー近傍で行う。 ClearViewの２つの修復パッチ(呼出しをスキップし、呼出し元へ復帰する)は、処理の残りの部分または全体をスキップするのと同様効果がある。 他の修復(値を上限値、下限値する)は、残ったエラーを局所化することで、アプリケーションが残った処理部分を安全に実行することを可能にする効果を持つ。
一般的に、ClearViewの修復は、エラーに続く正常ケースのコードをより実行する傾向にある。 人間による修復は、現処理を単純に中止する傾向にある。
我々は、この思い切ったアプローチは、保守者が"修復がエラーを取り除いたと確認することを簡単に確認するための結果だと考える。

人間による修復により近い確認と修復を作り出すようにClearViewを改良することは可能である。 例:動的メソッド呼出しで、オブジェクト型を自動的に推論し、そして、不変式確認が失敗したら、上位手続きにエラーコードを返すような、改良を行うことは可能である。
後続する大きな部分の計算をスキップする修復パッチを開発することもまた可能である。 幾つかの人間による修復は、ガベージコレクタへ参照の存在と再利用メモリの再初期化を伝える。それらの修復は故障場所から離れたコードに影響を及ぼす。 ClearViewは、より洗練された相関不変式の認識戦略(とより洗練された潜在力のある不変式)を適用し、同様の効果のある修復パッチを生成する必要がある。

4.4.3 多重可変攻撃
３つの欠陥において、Redチームは、標的欠陥のexploitコードの多重可変式を生成した。 Redチームは、各欠陥において攻撃中に異なる攻撃を挟み込んだ。 ClearViewは、単一攻撃と同じ攻撃数の後、同じパッチを生成した。 このパッチは、攻撃の全ての可変攻撃に対してFirefoxを防御した。

4.3.5 同時複数のExploitコード攻撃
Redチームは、異なる欠陥を目標としたexploitコードが挟み込まれた幾つかの攻撃を行った。 ゴールは、異なるexploitコードによる、異なる目標欠陥がClearViewのパッチを生成する能力そこなうか判定することである。
各ケースで、ClearViewは各攻撃の標的エラーを決定することができた。 異なるエラーに対して学習データを分離し、生成されたパッチ集合は互いにFirefoxを全ての攻撃をうまく防御した。 対応する単一攻撃の累計数と同じ攻撃数の後、ClearViewは、それらのパッチの生成が可能であった。

4.3.6 修復評価
Redチームは、全ての攻撃シナリオで、パッチ版Firefoxが評価用Webページを正しく表示するか判定することで修復品質を評価した。
最後の修復評価は、前の攻撃で生成された成功したパッチ全てを適用して行われた。Redチームは、このパッチ版Firefoxを全ての評価Webページを表示するために使用した。 各ケースにおいての表示は、パッチされていないFirefoxの表示と同一であった。 この結果は、Redチームは自己免疫攻撃を引き起こすことができなかった事を示す。
ClearViewの修復評価機構は、アプリケーションが悪影響を受けるパッチを破棄するように設計されている。 実際にRedチームの演習中、ClearViewは悪影響(アプリケーションがクラッシュする)のあるパッチを生成した。 しかし、修復評価機構はこれらのパッチを検知し破棄した。

4.3.7 誤検知評価
Redチームの誤検知評価は、ClearViewが評価用Webページを使用した。 ゴールは、ClearViewが失敗するパッチを生成することである。 この評価中、ClearViewは、まったくパッチを生成しなかった。 RedチームはClearViewが誤検知を引き起こすことができなかったことを示す。

4.4 性能
Redチーム実験は、以下のマシンを使用した。
- Dell 2950 rack-mount machine  16GBメモリ
- 2.3 GHz Intel Xeon processor × 2個
- 4core/1processor
- Firefoxは、ESXサーバのVMWare仮想マシン上で動作させた。
- XP Service Pack 2.
- OS Windows XP Service Pack 2
この環境では、296134は影響がなかった、
我々は、この296134を以下の環境で動作させた。
- 1.8 GHz AMD Opteron machine
- 4 Processeor core
- 8GBメモリ
- Windows XP SP2
この環境では、296134はエラーのきっかけとなった。 より遅いプラットホームでexploitコードを実行しているので、いろいろな活動のための実行時間は、一般的に、他のexploitコードを対応する時間より長い。

4.4.1 学習オーバーヘッド
１２の学習用Webページを読み込む時間は、学習無効状態で５.２秒必要であった。
同様のWebページを読み込む時間は、学習有効状態で１６００秒(３００倍遅い)必要であった。 Daikon x86 フロントエンドは、アクセスしたメモリとレジスタの値をダンプし記録する。 大部分のオーバヘッドは、Daikonフロントエンドで費やされた。
3.1で記述した並行アプリケーション共同体で学習オーバヘッドを分散することが可能である。

4.4.2 ベースライン オーバヘッド
表２は、いろいろなClearView構成下でFirefoxが、５７の評価用ページをローカルディスクから(ネットワークインターフェースを無効にした状態で)読み込む時に必要となる時間を示す。

我々はこの実験を、以下の環境で動作させている。
- Intel Core 2 Duo E6700 (2.66 GHz, 4MB L2 Cache, 3.25 GB RAM)
- Windows XP Service Pack3

Determina Managed Program Execution Environment(Memory Firewall有効)は、スタンドアロンのFirefoxより47%のオーバヘッドが増加する。 このオーバヘッドは、典型的な観測[4]より幾分大きい。 我々は、このオーバヘッドは、Firefoxのオブジェクト指向コンストラクタ(動的メソッドディスパッチ)を使用するためのものだと考える。
標準的なハードウェア分岐最適化技術で、結果として生じる間接的な分岐命令の基底にあるDynamoRIOコードキャッシュ実装は、他の命令パターン［4］の実装例より比較的効率的ではない。

ClerView構成	ページ読込時間[秒]	オーバヘッド率
Bare Firefox	7.5	1.0
Memory Firewall	11.04	1.47
Memory Firewall + Shadow Stack	14.90	1.97
Memory Firewall + Heap Guard	18.97	2.53
Memory Firewall + Heap Guard + Shadow Stack	22.70	3.03

表２:ページ読込時間とClearView構成によるオーバヘッドの差異

4.4.3 パッチ生成時間
ClearViewは、最初にexploitコードに遭遇してから、そのexploitコードの成功パッチを入手するまでの平均時間は、４.９分である。 これは、拡散している攻撃を停止させる時間は含んでいない。 Memory Firewallは攻撃が影響を与える前に、そのアプリケーションを停止するので拡散は存在しない。 この時間は、それに代わって攻撃中でもサービスを中断せず続行できるパッチされたアプリケーションを入手するまで、どの位の時間利用者は待たなければいけないかを示す。

４.９分は、以下の平均である: 
- 故障の検知
- 相関不変式候補の選択
- 相関不変式の認識のための不変式確認結果の収集
- 修復候補の評価
これらの平均には、ClearViewが３つの異なるエラーを順番に修復するために１３分かかったパッチ生成が含まれている。 ClearViewが1つのエラーを修復した後、同一のexploitコードが異なる欠陥からエラーを発生させた。

4.4.4 パッチ生成時間の詳細
ClearViewが成功パッチを生成する時間を考察するとき、1つの鍵は、開発者がexploitコードのためのパッチの開発と配布に28日間(平均)かかることをである。
この節では、ClearViewが４.９分(平均)間で同じことをする内訳を詳細化する。
表3は、成功パッチの生成のためにClearViewが必要な時間のコンポーネント毎の時間を示す。全ての時間は秒である。
311710を除き、1行が各exploitである。
最初の列はBugzilla番号。311710は３行持つ(311710a,311710b, and 311710c) 。上で説明した、Firefoxがその攻撃から最終的に乗り切る前に、ClearViewが修復した3つの異なるエラーを示す。我々は各エラーを行に分離した。

影のスタック、ヒープガード実行:
第２列は影のスタックとピープガードを有効にしてexploitコードの検知をするために必要な時間を示す。 Firefoxがexploitコードを処理するために再起動するとき、殆どこの時間(20～30秒)は、Determina Managed Program Execution Environment コード・キャシュのウオーミングアップに費やされる。
311710を除く全てのexploitコードのこの時間は大体の20～30秒である。 311710が、他のexploitコードより多くのFirefox機能を働かせるので、他より時間がかかる。 この列の数値を使って、唯一Memory Firewallを有効(最初の攻撃を検知したあと、Heap Guard と Shadow Stackは有効にされた)にした状態で、成功パッチ生成時間を計算することができる。 ClearViewは、Memory Firewallのみを有効にして、エラーが修復できる。 実際にHeap Guardは、Redチームの演習でClearViewの性能を改善しなかった。 Memory Firewall と Shadow Stackは、７つのexploitコードの成功パッチを生成するために必要だった。 Heap Guardは、ClearViewの構成変更後に、残りの２つのexploitコードの成功パッチを生成するために必要だった。

不変式確認パッチの生成と展開:
この列は、全ての不変式確認パッチを生成する時間を示す。 この時間は、パッチのために自動生成されたＣソースコードのコンパイルと、そのパッチをDeterminaパッチ管理システムへ提示するためにDLLへローディングする時間が含まれる。 全てのエントリは、t[x,y,z]の形式である。
  t  : 不変式確認を構築するために必要な時間 
  x  : 選択(one-of)不変式の数 
  y  : 下限(lower-bound)不変式の数 
  z  : 上限(less-than)不変式の数

296134は例外である。 296134は、ClearViewが他のexploitコードより多くの不変式確認パッチをコンパイルした。 そして、コンパイルは遅い計算プラットホーム上で行われた。 不変式確認パッチの展開列は、Determinaパッチ管理システムが、パッチを転送し、クライアントマシン上で動作しているアプリケーションへパッチを適用するために必要な時間を示す。

不変式確認パッチの実行:
この列は、exploitコードを２回検知するために、適所で不変式確認パッチを繰り返すために必要な時間である。
各エントリは、t(x/y)の形式である。
  t  :  exploitを2回検知するために必要な時間
  x  :  実行中に確認された不変式が違反した回数 
  y  :  実行中に不変式確認パッチが実行された回数

時間tは、ClearView Managerと、不変式確認、影のスタック、攻撃場所情報の各通信で必要な時間を含む。
前述のように、時間の多くは、Determina Managed Program Execution Environmentのコード・キャッシュのウオーミングアップに費やされた。 296134では、Windowsイベントキュー機構を使って、ClearView Managerに不変式確認の結果を伝えることに時間の相当な量を費やした。

修復パッチの構築と展開:
この列は、評価した全ての相関不変式のための修復パッチを構築するために必要な時間を示す。
各エントリは、t[x,y,z]の形式である。
  t  :  修復パッチを構築するために必要な時間
  x  :  相関選択(one-of)不変式の数
  y  :  相関下位(lower-bound)不変式の数 
  z  :  相関上位(less-than)不変式の数

全ての相関選択(one-of)不変式は、関数ポインタの不変式を含む。 2.5.1節で説明されているように、この不変式は３つの潜在的修復を持つ。 ClearViewは各修復毎に1つのパッチをコンパイルする。 他の不変式は、1つの修復パッチが1つの修復を持つ。
修復パッチの展開列は、それらのパッチをクラアントマシンへ展開するための通信に必要な時間を示す。 クライアントマシンは、ClearView Managerからの指示により、指定された修復パッチを1回に1つ適用する。

失敗修復パッチ:
この列は、Firefoxがあらゆる不成功修復パッチが完了するまでの時間を示す。
各エントリは、t(x)の形式である。
  t  :  Firefoxの実行が完了するまでに必要な時間
  x  :  失敗した実行回数

失敗回数が小さいのは、相関不変式の選択方針と修復パッチの評価優先の選択ルールの効果である。 296134は、不変式確認実行された回数と対応する不変式が違反した回数は紛失した。296134は、下限値不変式の数と上限値不変式の数は紛失した。

Bugzilla 番号	ShadowStack HeapGuard	不変式確認パッチ生成	不変式確認パッチ展開	不変式確認パッチ実行
269095	25.31	12.67 [1,0,1]	8.71	51.95 (4/28)
*285595	25.38	12.18 [0,5,0]	8.47	74.26 (6/2216)
290162	27.14	9.76 [2,0,0]	7.79	47.68 (2/2)
295854	32.81	8.82 [1,0,0]	9.20	66.29 (2/0)
296134	39.31	63.83 [0,42,10]	5.89	279.05 (?/?)
!307259	26.14	49.39 [0,4,26]	4.45	1235.53 (7444/29428)
311710a	52.00	14.22 [0,1,2]	9.19	151.29 (60/1460)
311710b	60.48	13.50 [0,1,2]	8.27	152.30 (60/1460)
311710c	51.56	17.56 [0,1,2]	8.38	161.44 (60/1460)
312278	24.30	8.56 [1,0,0]	7.22	48.49 (2/0)
320182	25.31	12.67 [1,0,1]	8.71	51.95 (4/28)
*325403	24.21	16.93 [0,0,2]	5.90	46.81 (4/0)

表3-前半:

Bugzilla 番号	修復パッチ生成	修復パッチ展開	失敗修復パッチ	成功修復パッチ実行	合計
269095	10.95 [1,0,0]	7.28	51.40(2)	34.50	202.77
*285595	11.48 [0,3,0]	8.79	-	31.84	172.40
290162	10.92 [1,0,0]	8.40	-	32.64	144.33
295854	10.34 [1,0,0]	8.10	31.11(1)	39.82	206.49
296134	30.27 [0,?,?]	6.23	-	50.22	474.80
!307259	39.66 [0,1,6]	6.28	347.69(7)	-	1709.11
311710a	11.34 [0,1,0]	6.83	-	69.05	313.92
311710b	13.38 [0,1,0]	5.48	-	57.60	311.01
311710c	16.17 [0,1,0]	8.16	-	64.02	327.29
312278	11.65 [1,0,0]	8.00	-	33.29	141.51
320182	10.95 [1,0,0]	7.28	51.40(2)	34.50	202.77
*325403	10.57 [0,0,2]	6.01	-	33.48	143.91

表3-後半:
ClearView攻撃処理時間。全ての時間はClearView Managerで測定された。 時間にはクライアントとClearView Manager間の通信時間を含む。 296134は遅いマシンで実行された。(4.4.4) *印はRedチーム演習中に修復成功パッチを生成できなかった攻撃であるが、後にClearViewの構成を変更して修復成功パッチを生成できた。 !印はRedチーム演習中も、その後でも修復成功パッチを生成できなかった。

成功修復パッチの実行:
この列は、成功修復パッチを適用したFirefoxを実行させるまでに必要となる時間を示す。 パッチを適用したFirefoxが起動してから10秒間攻撃を検知しないことで、このパッチがエラーの修復と攻撃検知の抑止すると判断された。 示されている時間には、この10秒が含まれる。 この時点で、ClearViewは、エラーを訂正し実行を継続する、1つのパッチの生成と識別を行った。 最後の列は、他の列の時間の合計である。 それは、攻撃に対応した修復成功パッチを自動的に入手するための総合時間を示す。

4.4.5 オーバーヘッド削減技術
現状のClearView攻撃対応システムには以下の３つの非効率的な処理が存在する。
・Determina Managed Program Execution Environmentのコード・キャッシュのウォーミングアップ
・共同体メンバとサーバとの通信機構でのWindowsイベントキューの利用
・不変式確認と修復パッチのコンパイル
キャッシュのウォームアップ時間は、前回実行時にキャッシュへ状態を退避し、スタートアップ時にその状態を再格納することで削減が可能である。
通信時間は、より効率的な通信機構を使用することで劇的に削減することが可能である。
コンパイル時間は、Ｃコードの生成の代わりに、バイトコードを直接生成することで削減が可能である。 我々は、これらの最適化が、ClearViewが成功パッチの提供時間を数分から数十秒となることが可能だと見積もっている。

4.5 他のアプリケーション
一般に、我々はFirefox結果が概して、ClearViewが他のサーバーアプリケーションのための結果を代表すると思っている。 ClearViewのパッチの多くは、他の技術(failure-oblivious computing、transactional function termination)と同様の効果を持つ。
下限値不変式、上限値不変式を矯正することで、メモリアクセス保護された領域外へのアクセスを領域内へ強制的に戻す。
failure-oblivious computingと同様に、この矯正により領域外書込のエラーの影響を局所化できる。そしてアプリケーション状態の広範囲な改竄を防ぐ。 transactional function terminationと同様に、矯正する選択不変式が、CALL命令の飛び越しか、呼出し手続きからの復帰を含む場合、他の脆弱性欠陥を含むコードの実行を抑止できる。
failure-oblivious computingとtransactional function terminationは、エラーと攻撃の範囲から乗り切るのためのサーバ範囲を広げる効果があることが示された。ClearViewは推論した不変式（アプリケーションの意味論面を捕らえている）に基づくので、原理的により的を絞った効果的な修復を生成できる可能性がある。 ClearViewは、広範囲な修復戦略を結合し複数修復候補の結果を評価することで、機能しない修復パッチや危険な修復パッチの適用を抑止する。 これらは、成功修復パッチの発見の能力を向上させる。
我々は、ClearViewの技術をサーバアプリケーションに適用した経験がない。 一般に、我々はこのClearView戦略が、計算結果が若干の変化(誤る)するのを許容できるアプリケーション（例えば感覚のデータと情報検索アプリケーションを処理するアプリケーション）の幅広い範囲に効果的であると予想する。
我々は、ClearViewの技術が以下のようなアプリケーションではあまり適切ではないと考えいる。
- 正確かつ論理的に定義された正当性要求を持つアプリケーション(コンパイラなど)
- 計算プロセスの長い連鎖のアプリケーション
- 可用性要求の少ないアプリケーション

5.限界
ClearViewのゴールは、全ての考えられるエラーを修復することではない。 コールは、現実的なエラーを修復することであり、エラーに遭遇してもサービスを継続提供できる高可用性を要求するアプリケーションを可能にする。 もちろん、完全にClearViewの範疇外のエラー(適正な不変式を学習できないような)は存在する。 しかし、エラーがClearViewアプローチの範囲内であっても、ClearViewはアプリケーションがエラーを乗り切る修復パッチを見つけることができない場合もある。

学習：
Daikonは不変式の特定の集合を学習するために予め設定されいる。 この集合は、与えられたエラーの修復パッチの生成を可能にする不変式を含まないだろう。そして、集合がそれらの不変式を含むとしても、学習が、Daikonがこの不変式を学習できるアプリケーションの十分な範囲を提供できないかもしれない。

モニタ：
ClearViewは現在、制御フロー遷移エラーの検知のためにMemory Firewallを使っている、領域外書込エラーの検知のためにHeap Guardを使っている。 他の種類のエラー検知のために、追加検知器が要求されるだろう。

候補不変式の選択：
全ての修復はClearViewが選択した候補相関不変式を矯正する。 たとえ、ClearViewがエラーを訂正すると思われる不変式を推論したとしても、 故障は、そのエラーから十分離て（ClearViewがエラーと相関する不変式を、候補不変式の集合に含んでいない）発生するかもしれない。

修復：
修復機構は、指定された不変式集合の矯正機構を伴っている。 各それらの機構は、特定の修復戦略に相当する。 それらの修復戦略が成功する修復を作らない可能性がある。 それは、ClearViewがアプリケーションの機能を損なうか、新しい脆弱性を作り出す可能性がある。

機能障害：
ClearViewの修復パッチがアプリケーションの機能を損なう可能性がある。 パッチが攻撃の反応で適用されるなら、機能障害は脆弱性を取り除くための許容できる代償かもしれない。 ClearViewが検知した故障（現状の実装では、不当な制御フロー遷移か領域外書込）だけにパッチを適用するという事実と、それが故障と相関する場合のみ、ClearViewが不変式を矯正する事実は、エラーまたは攻撃がない場合、パッチを適用する可能性を最小にする。 これらも適用されたパッチが正しい入力の処理を損なう可能性を最小にする。 そして、ClearViewパッチ評価機構は、故障を取り除けないか、アプリケーションのクラッシュを引き起こすパッチを識別し放棄する。
実際に、Redチーム演習中に、これらの悪影響を及ぼすパッチが生成された。 ClearViewパッチ評価機構は、これらの悪影響を及ぼすパッチを検知し、そのパッチを破棄した。

パッチ破壊：
敵が悪意のあるパッチをインストールさせるために、ClearViewパッチ機構を破壊することは、理論的に可能だ。 ClearViewは、商用Determinaパッチ配布機構上に構築されている。 それは、標準認証と暗号化機構でパッチ完全性を確実にする。

悪意あるノード:
理論的には、悪意あるノードやClearViewへエラー情報を与えるノードは、不適当なパッチの生成を引き起こす可能性がある。 パッチを共同体へ配布する前に、信頼されるノードでエラーの再現とパッチの評価を行うことで、これらの可能性を、軽減することが可能である。

6.関連研究
攻撃検知機構、自動フィルタ生成、チェックポイント、リプレイ技術、エラー耐性と修復に関連する研究を述べる。

6.1 攻撃検知機構
ClearViewは２つの攻撃検知機構を使用している:
- 悪意ある制御フローの検知と保護のためのプログラム監視 
- ヒープ領域外への書込検知と保護のためのヒープオーバーフローチェック

一般的に、ClearViewは、任意の攻撃検知技術(攻撃場所を提示する)で動作することができる。 例えば、改造したコンパイラで生成されたコードが攻撃(スタック上の復帰アドレスの上書き)を検知する Stack-Guard [9]、StackShield [39]がある。 StackShield は、関数ポインタの上書きを検知するために範囲チェックを実行する。 研究者はＣ言語上でメモリアドレスエラーを検知するために領域チェックコードを挿入するコンパイラを構築した。 これらの技術の欠点は、再コンパイルが必要なことである。 動的領域チェックのオーバーヘッドと場合によってはプログラム自身を変更する必要がある。 動的汚染分析は、関数ポインタや復帰アドレスなどの重要なデータの潜在的に悪意あるデータの兆しを見つける。 ClearViewがそれら全ての検知器と一緒に働くことは可能である。 しかし、高いオーバーヘッドと再コンパイルの潜在的な必要性、ソースコードの変更は、Windowsバイナリ上での動作と、通常実行中のオーバヘッドの最小化のというClearViewの哲学に反する。
提案された多くの保護技術の大きなオーバヘッドは、アプリケーションへの性能インパクトを削減する試みの契機になった。 一般に提案された囮技術は［38、33、1］は、アプリケーションの重装備版を走らせることになる。 しかし、製品版は新しい攻撃に対して無防備のままである。 囮が攻撃された時、装備は攻撃を検知できる。 そして、対策として保護されたアプリケーションの製品版を開発する。 この技術は、実質的にどんな攻撃検知にも適用することができる。 そして、対策機構を直接製品アプリケーションへ配備することはあまりに高価である。

断片化方式(各アプリケーションは唯一の小さな実行部分を実装することによっ)でマシン共同体に渡る高価な攻撃検知機構を配置することは可能である。[23]
広範囲のアプリケーションに渡る攻撃分析するシステムと対象的に、ClearViewが使う攻撃位置の特定は、それが装備するアプリケーション領域を劇的に小さくするシステムである。 それは、配備を高度にすることが可能である。 しかし、総合オーバヘッドを小さく保ちながら、アプリケーションの注目する領域の中で高価な分析を展開できる。 この潜在的欠点は、ClearViewが、アプリケーション論理の根底に存在するエラーを修復できる不変式を逃すかもしれないことだ。

6.2 自動フィルタ生成
アプリケーションを攻撃から保護する標準的な手法は、それらが脆弱アプリケーションに到達する前に、exploitコードを検知し破棄するフィルタを開発することである。
Vigilante[8]は囮を使って攻撃を検知する。 そして、同じ制御フローを辿る(同じ脆弱性を攻撃する)exploitコードを検知するフィルタを動的に生成する。
Bouncer[7]は、より多くのexploitコードを除去するため、Vigilanteのアプローチを一般化する記号技術を使用する。
ShieldGen[11]は、exploitを得るために自警攻撃検知技術を使う。 各exploitコードの変形を生成し、それらの変形が、脆弱性を利用するかテストする。そして、それら全ての変形を除去する汎用フィルタを作る。
Sweeper[42]は、効果的な攻撃検知ために、アドレス乱数化を使用する。 この技術はアプリケーションの保護版を開発するには十分効果的でる。 しかし、確率的な保護しか提供されない、従って、アプリケーションには脆弱性が残っている。 Sweeperは、より高価な攻撃分析技術（例えば、メモリアクセスチェック、動的感染分析、動的なバックワードスライス）を組み合わせて攻撃再現に使用する。 脆弱性アプリケーションに到達する前に、exploitコードを破棄するフィルタを生成するため情報を使う。 Sweeperも脆弱性に特化した実行フィルタを構築する、そしてそれは、攻撃に関係する命令を、攻撃を検知するために選択した。
攻撃への反応は、攻撃からの復旧のためのロールバックと再現を使用することである。exploitコードを含む入力を破棄することは、使用者に攻撃者がアクセスしたいコンテンツへのアクセスを与えることができない。 たとえば、合法的なWebページ、イメージ、プレゼンテーションのような役に立つ情報源がexploitコードがこっそりと侵入することは十分にあり得る。 攻撃者は、利用者を騙してexploitコードを含んでいる（脆弱なアプリケーションによって）コンテンツにアクセスさせる目的で、魅力的なコンテンツを作成するかもしれない。 Internet上の現状有効なコンテンツの多くが広告収入を得る目的で作られたと考える。代替(おそらく違法な)ビジネスモデルは、単に広告の替わりに攻撃を行う。 これらの全てのケースで、アプリケーションがexploitコードを含む入力を、攻撃を成功させるように処理することを要求する。
ClearViewは、アプリケーションの入力がexploitコードを含む情報であっても、利用者が有益な情報や欲しい情報にアクセスすることが可能である。 Redチーム演習で、ClearViewはヒープーバフローエラーの1つを修復した。 例:expoitコードを含むか、脆弱性エラーを発生させるデータを含むイメージファイルを参照することを可能にした。

6.3 チェックポイントと再現
伝統的かつ幅広く使用されているエラー回復機構は、システムを再起動して操作を再現することである。 ※最新状態のシステムバックアップが必要であるが。
システムがうまく回復するまで、再帰的により大きなサブシステムを再開することも、価値があるかもしれない。 チェックポイントは基本的な再起動処理の性能を向上することができる、 そして、再現無しに失われた状態を最小にすることを助ける。
チェックポイントは、攻撃やエラーの影響で、システムを前回退避された操作状態に戻すことを放棄させることを可能にする。 前回処理した要求(リクエスト)を再現するか、検知されたexploitコード含まない操作の組合せの幾つかのケースで、このアプローチは、攻撃反応機構[37, 26, 34, 35, 42]として提案されている。
ClearViewの攻撃からの実行を継続するアプローチと、チェックポイントと再現アプローチの比較において幾つかの欠点を持つ。 それらは、システムが攻撃から回復するためサービス割り込みを含む(これらのサービス割り込みは、システムが繰り返される攻撃に対して防御するまで繰り返し発生する)。 潜在的な故障の再現は、チェックポイントや再現機構の範囲外の外部プロセスやマシンへの干渉が問題となりうる。

6.4 エラー耐性と修復
Transactional function termination [36, 33](関数呼出し時の状態を保存し、領域外アクセスした関数から復帰する)、 failure-oblivious computing [29](領域外書込を抑止し、領域外読み出しの値を加工する)、 boundless memory blocks [28](領域外書込を次の対応する読み出しのためにハッシュ表に格納する)、 DieHard[3](ヒープ領域を過剰に準備し、領域外アクセスを未使用のメモリへ割り当てる)は、アプリケーションが領域外アクセスのようなエラーの耐性を持つように設計されている。 これらの技術は、学習を必要としない、また、候補不変式の選択と評価のための繰り返し実行を必要としない。
ClearViewとの違いは、確認と修復をアプリケーションの慎重に、攻撃時に目標とした領域のみに限定して適用し、各修復の実行中の評価を行う。 ClearViewは、エラーと相関している特定の不変式を確認した時点で、より有益なエラー報告を提供することもできる。 前のプロジェクト[13]において、我々は自動的にデータ構造の一貫性制約を推論と、それら制約を矯正する修復を生成するシステムを開発した。 このシステムは(異なる)Redチームによって評価された。 ClearViewと対照的に、この前のシステムはソースコードを必要として、(以降の改良なしで)一度だけ学習して、常に修復された状態で終わらせるために、静的に評価された修復を適用した。 その修復品質を評価するための修復以降の実行を観察しなかった。
ASSURE [35] は、トランザクション型関数(transactional function termination) を、エラー発生時点の呼出しスタック上の任意関数がトランザクション処理するためのシステムを可能する一般化を行った。 トリアージマシン上での攻撃再現は、修復の成功させるために終了させる関数を評価するシステムを可能にする。 適用されたパッチは、関数の開始時点のチェックポイントを取得する。 エラーへの対応はチェックポイントを戻すことである。 そして、関数を終了させるためと、呼出し元が実行継続するための効果的なエラーコードを返す。
Exterminator [25]は、ランダム化アドレス空間を使用して、ヒープ領域の領域外書込の検知と紐付いた参照によるアクセスを行う。 割当てメモリブロックの大きさを増加させることで検知された領域外書込、または、アクセスが対応する不当参照(dangling references)を通して完了するまでメモリブロック開放遅延を対応させることによって、エラーを訂正する。 Exterminator は、暴露なしで領域外書込、不当参照(dangling references)のパッチを共同体メンバに与えるために複数の利用者からの免疫パッチを統合できる。
研究者は、対象プログラムで検知された欠陥を自動的に修復することを目的として抽象構文木空間の生成と検索に、遺伝子のプログラミング技法を使用した。[16]
テストスイートは、各生成された抽象構文木の効果(要求される動作の保存と望まれない動作の破棄)を評価するために使用された。 これらの全ての技術は、アプリケーションを予想された操作環境外に連れて行くことができる。 従って、これらは新しい例外とエラーを導く可能性がある。
もちろん、ClearViewのパッチもアプリケーションへ悪影響を及ぼす可能性がある。 ClearViewは各パッチ開発の進行中に評価が行われる、それは、悪影響を及ぼすパッチを素早く破棄する。

7.結論
ソフトウェアシステムにおけるエラーは、我々の計算基盤の完全性と有用性に重大な脅威を与える。
開発者の手操作に頼るエラーの発見と修復は、アプリケーション利用者へサービス提供ができないか、長期間アプリケーションの脆弱性が晒されたままとなる。
ClearViewの自動エラー検出と修復技術は、全く人間の干渉なしで、新手のセキュリティ攻撃に対して、ほとんど即時に修復パッチを提供することができる。
その結果は、攻撃対して免疫があり、サービスを提供を邪魔されることなく継続できるアプリケーションである。 ClearViewは高可用性条件のアプリケーションに目標が定められている。そのために、パッチを適用したアプリケーションの予想外の動作の僅かな可能性は、サービス停止の危険性より望ましいと考える。
我々のアプローチの実用性はRedチームの評価で確認された。
ClearViewが、(Redチームが利用できた新しい攻撃方法を導入することなく)自動的にセキュリティ脆弱性修復する。 我々は、ClearViewの範囲外で重要な信頼性とセキュリティ問題があると認める。
それでも、ClearViewは重要で現実的な問題に対処して、我々のコンピューティング基盤の完全性と可用性性を改善する可能性を提示している。

Acknowledgments.  割愛

8.References
[1] ANAGNOSTAKIS, K., SIDIROGLOU, S., AKRITIDIS, P., XINIDIS,K., MARKATOS, E., AND KEROMYTIS, A. D. Detecting targeted attacks using shadow honeypots. In USENIX Security (Aug. 2005).http://dcs.ics.forth.gr/Activities/papers/replay.pdf
[2] AUSTIN, T., BREACH, S., AND SOHI, G.
Efficient detection of all pointer and array access errors. In PLDI (June 2004). http://delivery.acm.org/10.1145/180000/178446/p290-austin.pdf?key1=178446&key2=8765292621&coll=GUIDE&dl=GUIDE&CFID=71789700&CFTOKEN=44296420[3] BERGER, E., AND ZORN, B. DieHard: probabilistic memory safety for unsafe languages. In PLDI (June 2006). http://www.cs.umass.edu/~emery/pubs/fp014-berger.pdf
[4] BRUENING, D. Efficient, Transparent, and Comprehensive Runtime Code Manipulation. Ph.D., MIT Department of Electrical Engineering and Computer Science, Cambridge, MA, Sep. 2004. http://groups.csail.mit.edu/cag/rio/derek-phd-thesis.pdf
[5] CANDEA, G., AND FOX, A. Recursive restartability: Turning the reboot sledgehammer into a scalpel. In HotOS (Schloss Elmau,Germany, May 2001). http://roc.cs.berkeley.edu/papers/recursive_restartability.pdf
[6] CONDIT, J., HARREN, M., MCPEAK, S., NECULA, G. C., AND WEIMER, W. CCured in the real world. In PLDI (June 2003). http://www.eecs.berkeley.edu/~necula/Papers/ccured_pldi03.pdf
[7] COSTA, M., CASTRO, M., ANTONY, ZHOU, L., ZHANG, L., AND PEINADO, M. Bouncer: securing software by blocking bad input. In SOSP (Oct. 2007).

http://research.microsoft.com/en-us/um/people/mcastro/publications/bouncer.pdf
[8] COSTA, M., CROWCROFT, J., CASTRO, M., ROWSTRON, A.,ZHOU, L., ZHANG, L., AND BARHAM, P. Vigilante: End-to-End Containment of Internet Worms. In SOSP (Oct. 2005). http://research.microsoft.com/pubs/66830/vigilantesosp.pdf
[9] COWAN, C., PU, C., MAIER, D., WALPOLE, J., BAKKE, P.,BEATTIE, S., GRIER,A., WAGLE, P., ZHANG, Q., AND HINTON,H. StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks. In USENIX Security (January 1998). http://www.usenix.org/publications/library/proceedings/sec98/full_papers/cowan/cowan.pdf [10] CRANDALL, J., AND CHONG, F. Minos: Control Data Attack Prevention Orthogonal to Memory Model. In MICRO (Dec. 2004). http://www.microarch.org/micro37/papers/20_Crandall-Minos.pdf
[11] CUI, W., PEINADO, M., WANG, H. J., AND LOCASTO, M. E. ShieldGen: Automatic Data Patch Generation for Unknown Vulnerabilities with Informed Probing. In IEEE S&P (May 2007). http://research.microsoft.com/en-us/um/people/helenw/papers/shieldgen.pdf
[12] DEMSKY, B., ERNST, M. D., GUO, P. J., MCCAMANT, S.,PERKINS, J. H., AND RINARD, M. Inference and enforcement of data structure consistency specifications. In ISSTA (July 2006). http://www.cs.washington.edu/homes/mernst/pubs/infer-repair-issta2006.pdf
[13] DEMSKY, B., AND RINARD, M. Data structure repair using goal-directed reasoning. In ICSE (May 2005). http://www.cag.lcs.mit.edu/~bdemsky/publications/icse05.pdf
[14] ERNST, M. D., PERKINS, J. H., GUO, P. J., MCCAMANT, S.,PACHECO, C., TSCHANTZ, M. S., AND XIAO, C. The Daikon system for dynamic detection of likely invariants. Science of Computer Programming 69, 1.3 (Dec. 2007), 35.45. http://www.cs.washington.edu/homes/mernst/pubs/daikon-tool-scp2007.pdf
[15]ERNST, M. D., PERKINS, J. H., GUO, P. J., MCCAMANT, S.,PACHECO, C., TSCHANTZ, M. S., AND XIAO, C. The Daikon system for dynamic detection of likely invariants. Science of Computer Programming 69, 1.3 (Dec. 2007).
[16] FORREST, S., WEIMER, W., NGUYEN, T., AND GOUES, C. L. A genetic programming approach to automated software repair. In GECCO (July 2009). http://www.genetic-programming.org/hc2009/1-Forrest/Forrest-Paper-on-Repair.pdf
[17] GRAY, J., AND REUTER, A. Transaction Processing: Concepts and Techniques. Morgan Kaufmann, 1993.
[18] JIM, T., MORRISETT, G., GROSSMAN, D., HICKS, M., CHENEY,J., AND WANG, Y.
Cyclone: A safe dialect of C. In USENIX (June2002). http://www.cs.umd.edu/projects/cyclone/papers/cyclone-safety.pdf
[19] JONES, R., AND KELLY, P. Backwards-compatible bounds checking for arrays and pointers in C programs. In AADEBUG (May 1997). http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.42.3156
[20] KENDALL, S. C. Bcc: run-time checking for C programs. In USENIX Summer (1983).
[21] KIRIANSKY, V., BRUENING, D., AND AMARASINGHE, S. Secure Execution via Program Shepherding. In USENIX Security (Aug.2002). http://groups.csail.mit.edu/cag/rio/security-usenix.pdf
[22] LITZKOW, M., AND SOLOMON, M. The evolution of condor checkpointing. In Mobility: processes, computers, and agents (1999),ACM Press/Addison-Wesley. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.39.8734&rep=rep1&type=pdf
[23] LOCASTO, M. E., SIDIROGLOU, S., AND KEROMYTIS, A. D. Software self-healing using collaborative application communities. In SNDSS (Feb. 2005). http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.107.2699&rep=rep1&type=pdf
[24] NEWSOME, J., AND SONG, D. Dynamic Taint Analysis for Automatic Detection,Analysis, and Signature Generation of Exploits on Commodity Software. In NDSS (Feb. 2005). http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.83.2141&rep=rep1&type=pdf
[25] NOVARK, G., BERGER, E., AND ZORN, B. Exterminator:Automatically correcting memory errors with high probability. Communications of the ACM 51, 12 (Dec. 2008). http://delivery.acm.org/10.1145/1260000/1250736/p1-novark.pdf?key1=1250736&key2=8968292621&coll=GUIDE&dl=GUIDE&CFID=71793990&CFTOKEN=30617380 [26]QIN, F., TUCEK, J., SUNDARESAN, J., AND ZHOU, Y. Rx: treating bugs as allergies.a safe method to survive software failures. SIGOPS Oper. Syst. Rev. 39, 5 (2005), 235.248. http://wwwse.inf.tu-dresden.de/wiki/images/2/20/Natalia_Khokhlova_handin.pdf
[27] RINARD, M. Acceptability-oriented computing. In OOPSLA Companion (Oct. 2003). http://delivery.acm.org/10.1145/970000/966060/p57-rinard.pdf?key1=966060&key2=9788292621&coll=GUIDE&dl=GUIDE&CFID=71794235&CFTOKEN=27625332 [28] RINARD, M., CADAR, C., DUMITRAN, D., ROY, D. M., AND LEU,T. A dynamic technique for eliminating buffer overflow vulnerabilities (and other memory errors). In ACSAC (Dec. 2004).
[29] RINARD, M., CADAR, C., DUMITRAN, D., ROY, D. M., LEU, T.,AND WILLIAM S. BEEBEE, J. Enhancing Server Availability and Security Through Failure-Oblivious Computing. In OSDI (December2004). http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88.5974&rep=rep1&type=pdf
[30] RINARD, M., CADAR, C., AND NGUYEN, H. H. Exploring the acceptability envelope. In OOPSLA Companion (Oct. 2005). http://portal.acm.org/ft_gateway.cfm?id=1094866&type=pdf&coll=GUIDE&dl=GUIDE&CFID=71794675&CFTOKEN=31738555
[31] RUWASE, O., AND LAM, M. S. A Practical Dynamic Buffer Overflow Detector. In NDSS (February 2004). http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.5.6065&rep=rep1&type=pdf
[32] SHACHAM, H., PAGE, M., PFAFF, B., GOH, E.-H., MODADUGU,N., AND BONEH, D. On the Effectiveness of Address-Space Randomization. In ACM CCS (Oct. 2004). http://delivery.acm.org/10.1145/1040000/1030124/p298-shacham.pdf?key1=1030124&key2=4929292621&coll=GUIDE&dl=GUIDE&CFID=71794842&CFTOKEN=99750158 [33]SIDIROGLOU, S., GIOVANIDIS, G., AND KEROMYTIS, A. D. A dynamic mechanism for recovering from buffer overflow attacks. In ISC (Sep. 2005).
[34] SIDIROGLOU, S., LAADAN, O., KEROMYTIS, A. D., AND NIEH, J. Using rescue points to navigate software recovery. In IEEE S&P (May 2007). http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.64.7751&rep=rep1&type=pdf
[35] SIDIROGLOU, S., LAADAN, O., PEREZ, C., VIENNOT, N., NIEH,J., AND KEROMYTIS, A. D. Assure: automatic software self-healing using rescue points.
In ASPLOS ’09 (2009). http://delivery.acm.org/10.1145/1510000/1508250/p37-sidiroglou.pdf?key1=1508250&key2=9959292621&coll=GUIDE&dl=GUIDE&CFID=71795173&CFTOKEN=88572754 [36]SIDIROGLOU, S., LOCASTO, M. E., BOYD, S. W., AND KEROMYTIS, A. D. Building a reactive immune system for software services. In USENIX (Apr. 2005).
[37] SMIRNOV, A., AND CHIUEH, T. DIRA: Automatic Detection,Identification and Repair of Control-Hijacking Attacks. In NDSS (Feb. 2005). http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.74.3148&rep=rep1&type=pdf
[38] SPITZNER, L. Honeypots: Tracking Hackers. Addison-Wesley, 2002.
[39] Stackshield. www.angelfire.com/sk/stackshield.
[40] SUH, G., LEE, J., ZHANG, D., AND DEVADAS, S. Secure Program Execution via Dynamic Information Flow Tracking. In ASPLOS (Oct. 2004). http://portal.acm.org/ft_gateway.cfm?id=1024404&type=pdf&coll=GUIDE&dl=GUIDE&CFID=71796756&CFTOKEN=43321397
[41] Symantech internet security threat report. www.symantec.com, Sep. 2006. [42] TUCEK, J., NEWSOME, J., LU, S., HUANG, C., XANTHOS, S.,BRUMLEY, D., ZHOU, Y., AND SONG, D. Sweeper: A lightweight end-to-end system for defending against fast worms. In EuroSys (Mar. 2007). http://delivery.acm.org/10.1145/1280000/1273010/p115-tucek.pdf?key1=1273010&key2=8950392621&coll=GUIDE&dl=GUIDE&CFID=71796896&CFTOKEN=53242397 [43]YONG, S. H., AND HORWITZ, S. Protecting C programs from attacks via invalid pointer dereferences. In ESEC/FSE (2003). http://delivery.acm.org/10.1145/950000/940113/p307-yong.pdf?key1=940113&key2=2760392621&coll=GUIDE&dl=GUIDE&CFID=71797018&CFTOKEN=80164595

2012 を観た

日本沈没の世界版だ。
殆どがCGだ。
テーマパークのアトラクションのような映画。
ストーリーは殆ど無い。

音楽三昧 その2

ショパン:ワルツ集 アリス=紗良・オット

演奏内容を批評できるような者ではないですが、跳ねるような若さが感じられてとても心地良い。
でも。このピアノの音はどうなのか? 高音をあえてフィルタリングしているのか?
高音の弾かれるような音がしないなあ。
他の演奏、例えば↓のピアノの音と比べると、何だ? という感じ。
何かくすんだ音だ、録音がダメなのか、ピアノがダメなのか、演奏場所がダメなのか、私の耳がダメなのか?

幻のショパン・レコーディング1965 アルゲリッチ(マルタ)

1965年の演奏なので、たぶんテープ録音からCDへ録音しているので、ヒスノイズがあるんだけど、そんなことは関係なくピアノが迫ってくる。
ショパンの曲は、ときおり垣間見える(聞こえる)荒々しさがすきだ。
この演奏は、そんな荒々しさと、彼女の若さの荒々しさが重なって凄い演奏だ。

ショパン:24の前奏曲集 アルゲリッチ(マルタ)

1960年、1967年、1977年の録音。
このポロネーズ 第6番 と 幻のショパン 1965 を聞き比べる違いにびっくりする。

ベートーヴェン:ピアノソナタ第8番&第14番&第23番 ギレリス(エミール)

ベートーヴェン:ピアノ協奏曲第5番「皇帝」/ピアノ・ソナタ第17番「テンペスト」 グルダ(フリードリヒ)

ラフマニノフ:ピアノ協奏曲第2番/他 グリモー(エレーヌ)

臨場感ある演奏だ、彼女の息づかいまで聞こえてしまう。
amazonのレビューでは歌っていると書いてあったが?

ショパン:ピアノ協奏曲第1番&第2番 ピリス(マリア=ジョアオ)

演奏がやさしい。

アコースティック・フレイクス 渡辺香津美 吉田美奈子

戦場の掟

戦場の掟 スティーヴ・ファイナル

この本には、驚くべきイラク戦争の実態が、警備会社の社員という”傭兵”の個人的な生きざまから垣間見ることができる。
イラク戦争の実態は、この著者のように、実際に戦場い行かなければわからないだろう。
でも、この本を読むと、著者や傭兵やイラク人の置かれている、緊迫した異常な現実が感じ取れる。

民間警備会社の警備員は、イラクで米軍(他国も)と契約しいろいろな警備活動を行う。
軍は危険な警備の仕事を、これらの民間警備会社へアウトソーシングしてる。
その市場規模は、総額８５０億ドルになり、米国政府の戦費の１／５である。

傭兵（民間警備会社の武装警備員）の数
イラク戦争に出征している米軍兵は約３万人である。
傭兵の数は定かな統計数値はない。
国防総省の２００５年の推定は２万５０００人。
会計検査院の推定では、４万８０００人。
２００８年８月でも、イラクで活動している民間警備会社の武装警備員の総数は、議会予算局の報告もまちまちである。
イラク民間警備会社協会（PSCIA)が２００８年２月に３万人と推定している。

傭兵が従うべき法は無い
米軍兵士は、統一軍事裁判法の下で活動している。
しかし、傭兵は、イラクの法律、米国の法律、統一軍事裁判法、イスラム法、ジュネーブ法等の世界で通用している法律が適用されない。
本来であれば、民間警備会社の武装警備員は、米国の軍事域外管轄法(MEJA)の対象になる。 これは国防総省が外国で雇う民間人を裁くために司法省が制定したものだが、イラクでは全く適用されていない。
イラクの武装警備員は、全くどんな法律にも裁かれず、武器を携帯し使用できる。
特に交戦規定がないので、現場の警備員の判断で武力行使できる。
イラク民間人への誤った攻撃、意図した攻撃がある。

傭兵の心
傭兵に志願する者の動機は、基本的には金のためだ。
だから、兵士と違い、警備員同士に固い結束は無い。
傭兵の中には、スリルや戦場の緊張感が忘れられずやってくる者もいる。
悪質なのは、人を殺すことに興味を持っている者もいるということだ。
この本に登場する人物は少なくとも戦争によるPTSDで、何らかの心の問題を抱えている。

矛盾
イラクの民間警備会社は、米軍や他の国の軍隊と契約する。
契約内容は、輸送車両の護衛等だ、だから、傭兵は兵士を守っていることになる。
顧客の中に、当然日本の自衛隊も含まれる。
傭兵が警備中に戦闘で死亡しても、米国の兵士死亡者数には数えられない。
また、その死者の数も正確にはわかっていない。
だから、傭兵が何人戦死しようと米国軍はなんの影響もない。
武装警備員という名の兵士は民間人であり、米国では、イラク戦争より前には、このような民間人が戦争行為を行うことは無かった。

米国が起こしたイラク戦争は、まさにパンドラの箱を開けた状態である。
米国や世界は、この戦争をどうやって終わらせるのか、また、イラク復興をどう実現するのか。

ブルースクリーン irql_not_less_or_equal

Windows Vista で ブルースクリーンが出て非常に困った。

私のPCには、ノートン™ アンチウイルスを使っている。
何かの拍子に、Windows Defenderを有効にしてしまった。
そうしたら、PCを使っていると、以下のブルースクリーンが表示されるようになってしまった。

STOP 0x0000000A IRQL_NOT_LESS_OR_EQUAL 

 

この情報だけだと、まったく原因がわからなかった。
Vistaを起動すると、ノートン™ アンチウイルスがウィルスパターンファイルが見つからない というような警告を出していた。
それで、Windows Defenderとノートン™ アンチウイルスが競合していると思った。

そこでセルフモードで、Windows Defenderをアンインストールしようとしたが、
Windows Defenderが見つからずアンインストールができない。
そこで、ノートン™ アンチウイルスをアンインストールしようとしたが、
”セルフモードでは、削除できない” と警告が出る。

困ったので、以下の手順で直した。
１）セルフモードで起動
２）C:\Program Files 配下のノートン™ アンチウイルスのディレクトを削除
３）Windows Vistaを起動
    起動するとノートン™ アンチウイルスのインストールが不十分だと表示されるが無視する。
４）プログラムの削除で、ノートン™ アンチウイルス を削除する。
５）ノートン™ アンチウイルスの代わりに、Microsoft Security Essentialをインストールする。

時間封鎖

時間封鎖〈上〉 (創元SF文庫) ロバート・チャールズ ウィルスン

時間封鎖〈下〉 (創元SF文庫) ロバート・チャールズ ウィルスン

地球が、突然膜（SPIN)に覆われる。
膜に覆われた地球の時間が、宇宙に対して非常に遅く進むようになる。
時間の進みかたは、地球時間の１秒が、地球以外の宇宙では3.7年となる。
地球の外側から眺めると、ほぼ凍りついた状態となる。

この時間差は、人類にとっては致命的である。
数十年で、太陽の寿命に達してしまい、地球上の生命は存続できなくなる。
この時間差を弱手に取って、壮大な実験を人類は行う。
この異常な状況の中での、３人の主人公の数十年に渡るドラマである。

膜（SPIN)とは何か？ 誰がなんの目的で作ったのか？
時間的にも、空間的にも壮大な結末が印象的だ。

この小説の構成は、場面が時間的に不連続に進む。
これは著者の意図したことなんだろうけど、読んでいると結構つらい。
もうちょっと、ストレートに読ませてくれよ っていう感じ。

でも、ストーリーは非常に面白い。

渡辺香津美 深遠なるギターの世界

長野県信濃美術館･東山魁夷館ギャラリーコンサートを観た、聞いた。

信濃美術館に渡辺香津美さんが来るなんて、思ってもいなかった。
会場は東山魁夷館で、チケットは完売されていて、約200人くらいのギャラリだった。
椅子が普通のパイプ椅子なので、ちょっと座り心地が悪い。
席は全席自由なので、早めに行って良い席を取るのが肝心 ... みたいだ。
私は、17時40分頃行ったら、良い席は殆ど無かった。

渡辺さんは、喋っている時は紳士で、物静かなんだけど、演奏すると非常に情熱的だ。
素人が演奏技術を褒めてもどうしようもないんだけど、ギターを奏でる技は"職人"という感じだ。

演奏した曲
・レノン＝マッカートニー／アクロス・ザ・ユニヴァース
・渡辺香津美／ブルー・スティール
・ジャコ・パストリアス／スリー・ビューズ・オブ・ア・シークレット
・ハロルド・アレン／オーバー・ザ・レインボウ
・ヴィクター・ヤング／ステラ・バイ・スターライト
・ジャンゴ・ラインハルト／ニュアージュ～マイナー・スゥイング
・渡辺香津美／東山魁夷作品に触発されたImprovisation
・W.A.モーツァルト(渡辺香津美 編)／ピアノ協奏曲 第23番 イ長調 K.488 第2楽章より
・W.A.モーツァルト(渡辺香津美 編)／トルコ行進曲による即興演奏　
・マイルス・デイビス／マイルストーンズ
・チック・コリア／スペイン
・渡辺香津美／ジャミング・イベリコ
・アンコール

東山魁夷作品に触発された即興演奏は興味深かった。
演奏したあとの感想で、途中から馬をイメージして演奏したと言っていた。
私の中では、東山魁夷の白馬の絵が強く印象に残っており、このような演奏者と観客がシンクロするような雰囲気が非常に心地良いと感じた。

トルコ行進曲による即興演奏は、本邦初公開であったらしいが、非常に素晴らしかった。
のりのりのトルコ行進曲だったなあ。

圧巻はジャミング・イベリコだ。
この曲の由来の説明は可笑しかったけど、演奏はまったく凄かった。
シビレました。

美術館の中で演奏するので、音はどうなのかと思ったけど良かった。
飾られている東山魁夷の絵と演奏の両方を堪能でき、非常に贅沢な時間だった。

[関連]
nowadays 吉田美奈子&渡辺香津美

御即位20年記念 特別展「皇室の名宝―日本美の華」

若沖の絵を見た!

特別展「皇室の名宝―日本美の華」 が東京国立博物館で行われている。

やっと行けた、今日を逃すと、展示品が変わってしまい、若沖の「動植綵絵」が見れなくなる。

午後5時過ぎに入館したが、やはり「動植綵絵」の前は結構な人だかりだ。

それでも、見れないことはなく、動植綵絵 30幅 + 旭日鳳凰図 を堪能した。

約250年前に書かれた絵であるが、鳳凰は非常に艶かしいし、虫や蛙はユーモラスだ。

見てるととっても楽しいだけど、本人はどんな思いでこの30幅を描いたのか。

若沖の思い描く"極楽浄土"なのかもしれないなあ。

この30幅を描くのに10年位しかかかっていない、1年で3幅の生産性だ。

結構大変な労力だと思う。

でも、絵を描くことが、本当に好きだったんだろうな。

若沖は、青物問屋の家督を40歳で弟に譲り、亡くなるまで絵を描き続けた。

世間の雑事には関心がなく、絵を描くことに精力を注いだ.... と言われている。

しかし、近年の研究では、若沖は浮世の雑事にも精力的に活動していたという記録が出てきたそうだ。

伝えられる人物イメージとは違うようだ。

また、若沖の新しい絵も、滋賀で発見されたりして、没後200年以上たっても、話題の人だ。

若沖以外にも「皇室の名宝」が沢山見られた。

特に「七宝四季花鳥図花瓶」は凄いです。

.

数学的にありえない

アダム ファウアー(著)

原題は“Improbable”なので、数学的にありえないわけではない。
「経験的には、ありえそうもない頻度で起こる事象」とでもいったらいいのか。
この題名の意味は、読んでみるとよく分かるんだけど。

アクション活劇なんだけど、ストーリのベースとなっているのは、確率、量子力学の解釈、不確定性原理、多世界解釈といった、現代科学の専門家でも考えが異なる物理学の根本だ。

話は荒唐無稽だが、その理論は荒唐無稽ではなく緻密に説明されている。
登場人物も皆個性的だし魅力的だ。
テンポがよく、非常に面白い小説だ。
読んで損はしないな。

この小説を読むと、"自由意志は何か"を、考えてしまう。

新世界より

貴志 祐介

書店に、この1000ページ近い本が置いてあり、その厚さのインパクトで衝動買いしてしまった。

こういう世界観を描けることがすごいなあ。

読むと、いろいろな感想を持つんだけど、娯楽として読むと楽しめるなあ。

社会批判とか人間性とか、こだわって読むと損をするな。

少年少女の冒険活劇だ。

音楽三昧

CD3800を手に入れてから、いろいろCDを買ってしまう。
amazonで手軽に買えちゃうのが原因だ。
気がつくと、音楽の女神ばっかりだ。
でも、最後に SOIL&“PIMP”SESSIONS で〆る。

モーツァルト:ヴァイオリン協奏曲第3番&第5番 Anne-Sophie Mutter

モーツァルト:ヴァイオリンソナタ第25番&第28番&第32番&第42番 Hilary Hahn

メンデルスゾーン:ヴァイオリン協奏曲 他 Hilary Hahn

リスト:超絶技巧練習曲 Alice-Sara Ott

ツィゴイネルワイゼン/ヴァイオリン名曲集 Anne-Sophie Mutter

ブラームス:ヴァイオリン協奏曲 他 Hilary Hahn

smile 宮本笑里

フライ・ミー・トゥ・ザ・ムーン Nichi Parrott

6 SOIL&“PIMP”SESSIONS

CD3800を買った後

CD3800はどんなものか早速聞いてみた。

オーディオセットは20年以上前に購入したものだ。
買った当時はレコードを聞きいていたが、引っ越しとかして、その後、十数年間はほとんど聞いていなかった。
今回CD3800を買ったことで、現役復帰した。

アンプ SANSUI AU-D907X DECADE
スピーカ Victor SX-10spirit
CDプレーヤ CEC CD3800

ショパン:ピアノソナタ第2番&第3番 Martha Argerich

録音された時期は古いが、非常に心地よい。
これは演奏が良いからなのか、録音良いからなのか。

ラフマニノフ:ピアノ協奏曲第3番 Martha Argerich

1980年代に録音されたものだが、オーケストラは何となく臨場感がないなあ。
このオーディオセットの限界なのか。
会場の雑音(セキとか)が気にきになる。

チャイコフスキー:ピアノ協奏曲第1番 Martha Argerich

ピアノ協奏曲第1番では、ピアノとオーケストラの音が重なり、ピアノが負けてしまう。

バッハ:シャコンヌ Hilary Hahn

これはすばらしい。
非常に臨場感があり、演奏者の動きまで分かるようだ。
バイオリンの音色が素晴らしい。

ライブ・アット・ピットイン MJQ

なかなか、心地良い。
ライブ盤なので、非常に臨場感がある。

CD3800は、その値段からしたら大満足だ。
私のオーディオセットで、十分CDが聞ける。