1 / 21

ASE2011 Session05: Analysis, Verification and Validation

ASE2011 Session05: Analysis, Verification and Validation. Scalable and Precise Symbolic Analysis for Atomicity Violations DC2 : A Framework for Scalable, Scope-Bounded Software Verification Formalizing HW/SW Interface Specifications Safe Asynchronous Multicore Memory Operations.

jin-ratliff
Download Presentation

ASE2011 Session05: Analysis, Verification and Validation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. ASE2011 Session05: Analysis, Verification and Validation Scalable and Precise Symbolic Analysis for Atomicity Violations DC2: A Framework for Scalable, Scope-Bounded Software Verification Formalizing HW/SW Interface Specifications Safe Asynchronous Multicore Memory Operations 担当者:横川智教(岡山県立大学) FSE/ASE2011勉強会

  2. A05-1 Scalable and Precise Symbolic Analysis for Atomicity Violation Malay K. Ganai (NEC Labs America) FSE/ASE2011勉強会

  3. Background コンカレントシステムにおけるバグの原因の45.7%は 原子性(Atomicity)の違反に関するもの [1] 原子性の違反を検出するツールBESTの開発 [1] S. Lu et al., “Learning from mistakes: A comphrensive study on real world concurrency bug characteristics,” In Architectural Support for Programming Languages and Operating Systems, 2008. FSE/ASE2011勉強会

  4. BEST(Binary instrumentation-based Error-directed Symbolic Testing) Target Binary Test Harness • Stage1:Trace Generalization • バイナリを実行し,メモリアクセス等のイベントを記録 • Concurrent Trace Model(CTM)を作成 • Stage2:Simplify CTM • ローカル処理を合成 • 実行不能/冗長なコンテクストスイッチを削除 • Stage3:Inferring Atomic Specification • CTMからAtomic Regionを抽出 • atomicと証明済/non-atomicと既知のものを削除 • Atomic Propertyを生成 Stage5: Debug Traces • Stage4:Property-specific Symbolic Analysis • Atomic Violation(NAV)とFeasible Schedule(Ωsched)を記号表現 • NAV∧Ωschedの充足可能性判定 FSE/ASE2011勉強会

  5. Contributions Generalization: 扱えるスケジュールに制約がない Precision: 実行可能なスケジュールの全てかつそれのみを記号表現 Scalability: CTMの簡単化により問題のサイズを削減 制約ベースの検証 → 明示的なスケジュールの列挙が不要 Feasibility: Causal AtomicityやCausal Mutual Atomicityなどの 様々なAtomicity Propertyを検証することが可能 FSE/ASE2011勉強会

  6. Evaluation 9種のマルチスレッドアプリケーション(C/C++/Java) に対してBESTツールを適用 A. Atomicity Analysis (Tab. 4) スレッド数に対する問題サイズの変化の測定 • 17個のバグを検出 • CAと比較して,CMAの検出コストは小さい B. Reduction Step (Tab. 5) 削減手法の組み合わせに関する効果の測定 • 削減効果は大きい(最大で2×106倍) • CAと比較して,CMAに関する削減の度合いが大きい FSE/ASE2011勉強会

  7. A05-2 DC2: A Framework for Scalable, Scope-Bounded Software Verification FranjoIvancic, GogulBalakrishnan, Aarti Gupta (NEC Labs America) SriramSankaranarayanan (University of Colorado) Naoto Maeda, Hiroki Tokuoka, Takashi Imoto, Yoshiaki Miyazaki (NEC Corporation) FSE/ASE2011勉強会

  8. Background Software Model Checkingへの要求 Scalability: 1MLOC以上のソースコードが扱えなければならない Performance:  与えられた時間内に検証を完了しなければならない Accuracy:  誤検出が多くてはならない ソフトウェア検証フレームワークDC2の開発 FSE/ASE2011勉強会

  9. DC2(Depth-Cutoff with Design Constraints) Scope bounding:  ネストの深い関数を排除することでモデルサイズを制限 Automatic specification inference:  関数の外部環境(グローバル変数,呼び出し等)の制約を推測 スタブ関数の推測 プログラム解析ツールSpecTackleの開発 Environment refinement:  反例を元に抽象モデルを詳細化 CEGER(CounterExample-Guided Environment Refinement) NECが開発したソフトウェア検証ツールVARVELの一部として実装 FSE/ASE2011勉強会

  10. Depth Cutoff in DC2 fun. f() assume(pre_f) call g1(); call g2(); fun. g1() assert(pre_g1) call h(); call h_stub(); fun. h() … fun. h_stub() assert(pre_h) inferred stub assume(post_h) fun. g2() assert(pre_g2) … (本文Fig.3より抜粋) FSE/ASE2011勉強会

  11. Evaluation A. DC2の適用(Tab. 4) DC2適用前後のSuccess Ratioと#Likely Bugsを測定 • 定められた期間で検証が完了した割合が増加 • 検出数の増加および誤検出の減少 B. CEGERの適用 Zister Benchmark (Tab. 6) • 検出率が向上(7/90→10/13) • 検出数も増加 Industrial Benchmark (Tab. 7) • より少ない検出数でバグを発見 • 被験者は非専門家であったが効果があった FSE/ASE2011勉強会

  12. A05-3 Formalizing Hardware/Software Interface Specifications Juncao Li, Thomas Ball, Vladimir Levin, Con McGarvey (Microsoft Corporation) FeiXie (Portland State University) FSE/ASE2011勉強会

  13. Background ドライバ(SW)とデバイス(HW)の依存性 ドライバを開発時にはデバイスが完成している必要がある 開発サイクルの長期化 HW/SWインタフェースのモデル化 Software Inter face Hardware ドライバ(SW)開発 デバイス(HW)開発 HW/SWを並行して開発することが可能 FSE/ASE2011勉強会

  14. Contributions Relative atomicity: トランザクションの優先度を相対的な原子性として表現 Specification of HW/SW interface protocols: 仕様記述言語modelCを開発 C言語のセマンティクスに3つの制約(範囲付き整数,再帰  呼出回数の制限,動的メモリ割り当ての禁止)と2つの拡張 (Relative atomicityおよびnon-determinism) Protocols coverage: HW/SWインタフェースのプロトコルを厳密にモデル化 Application and evaluation criteria: MODEL-DOC rationを始めとし,4つの評価基準を提示 FSE/ASE2011勉強会

  15. Formal specification framework atWritePortA() atWritePortB() Σ={{wr_a},{wr_b},{no_evt},..} Software Model (LPDS) Hardware Model (BA) Output2PortA() atRun_DIO() Output2PortB() Isr() I={{intr},{no_intr},..} RunIsr() (本文Fig.5より抜粋) FSE/ASE2011勉強会

  16. Evaluation 提案するモデル4つの評価基準をもとに評価 Correctness assurance: 仕様の不整合をCコンパイラで検出 Manual effort: 仕様化するプロトコルの複雑さをドキュメントの規模を元に測定 False positives: over abstractionに起因する偽陽性 Comparison with the English specification: モデルとドキュメントの関係解析のためMODEL-DOC ratioを導入 モデルを記述するmodelCの行数 ドキュメントのページ数 MODEL-DOC = FSE/ASE2011勉強会

  17. A05-4 Safe Asynchronous Multicore Memory Operations MatkoBotincan, Mike Dodds (University of Cambridge) Alastair F. Donaldson (Imperial College London) Matthew J. Parkinson (Microsoft Reseach Cambridge) FSE/ASE2011勉強会

  18. Background マルチコアシステムにおいて非同期メモリ操作は非常に重要な技術 Cell,CUDA,OpenCLなどでも利用される 不正な非同期操作に起因するバグは検出・分析が非常に困難 ある環境では正しく動作し,他では重大な障害を引き起こす 形式的検証が必要とされる マルチコアプログラムの安全性検証手法の提案 ツールasyncStarとしての実装 FSE/ASE2011勉強会

  19. Contributions マルチコアプログラムを対象としたプログラム論理の構築 スレッドのfork/joinと非同期メモリ操作を考慮 マルチコアプログラム論理の自動証明 SMTソルバの利用 ツールasyncStarの実装 Industrial Benchmarkによる評価 FSE/ASE2011勉強会

  20. asyncStar coreStar SMT solver Theorem prover APRON Abstraction Symbolic execution asyncStar Pre/post conditions Loop invariants coreStarIL program VMC program (Verified Multicore C) VMC frontend (本文Fig.5より抜粋) FSE/ASE2011勉強会

  21. Evaluation Cell Broadband Engine SDKのベンチマークを用いて評価 バグを含まないもの(Correct)と含むもの*(Buggy)に対して asyncStarを適用した結果を測定 *Wait命令を取り除くことで作成 証明および反証は現実的な時間で終了(~8416秒程度) 要素数の変化は検証コストに影響を与えない 本質的なボトルネックではない FSE/ASE2011勉強会

More Related