Automating the Verification of Floating-Point Programs

C. Fumex, C. Marché, and Y. Moy
VSTTE 2017, Jul 2017, Heidelberg, Germany. Springer, 10712, 2017, LNCS

Transcript

1. Automating the Verification of Floating‑ Point Programs C. Fumex, C. Marché, and Y. Moy.: VSTTE 2017, Jul 2017, Heidelberg, Germany. Springer, 10712, 2017, LNCS. @tyabu12
2. 0. 概要 2
3. 背景 演繹的プログラム検証において, 浮動小数点演算を扱うのは困難 証明成功と証明自動化の度合いは, バックエンド証明器がサポート するロジックによる, 浮動小数点演算の解釈方法に強く依存 やったこと 浮動小数点演算の検証を, 複数の技術を組み合わせ, 所望特性を別部分に 切り離して証明 どうやったか 抽象解釈を用いて式の数値範囲を計算し, 複数の自動証明器を用いて検証 を行うようにした 浮動小数点数演算の表現には, 様々な戦略を頼った 戦略の一つは, 近年 SMT‑LIB 標準に追加された浮動小数点演算のネ イティブサポートに基づく 3
4. 4. 実験 現在の SPARK ツール群を用いた検証を行った SPARK ツール群: SMTソルバ (CVC4, Alt‑Ergo, Z3), と静的アナラ イザ (CodePeer) 2つの証明器を追加した AE‑fpa: FPサポート付き Alt‑Ergo のプロトタイプ COLIBRI: 制約ソルバ技術に基づく証明器 4
5. 4.1 Small Representative Examples FP 演算を用いた22個の産業プログラムの証明 線形/非線形演算, 整数 ↔ FP 変換, 単精度・倍精度を組み合わせた, 現実的で多様な FP 演算 2014年の SPARK では証明できず 今回の実験では全て証明できた 5
6. 4.2 A Case Study safety‑critical なソフトウェアに埋め込まれたコードの検証 装置が, 重力加速度と引力から受ける, 速度を計算するプログラム 4.1 節のツール群により証明 6
7. 5. 結論 筆者の提案する浮動小数点プログラムの自動検証は汎用定理に基づく 1. FP 演算のモデル化は Why3 の仕様言語で記述 2. 定理は IEEE 標準に忠実 → Coq の Flocq ライブラリや SMT‑LIB の FP 定理に対応付けることが可能 3. Why3により生成される VC 群は, (FP 定理のネイティブサポートあ り, またはなしで) 区間解析をする CodePeer アナライザや, SMT ソ ルバーに送られ, 検証される VC の様々なソルバによる検証は, 検証プロセスの高水準な自動化を可能 にする 7
8. 5. 関連研究 8
9. FP演算の形式化 FP 演算は対話演繹検証システムにおいて形式化されてきた: PVS, ACL2, HOL‑light, Coq (mid 1990s) ハードウェアコンポーネントやアルゴリズムの抽象的概念を表現 → 健全性を証明 代表的な事例 ACL2における, AMD‑K7 マイクロプロセッサの FP 乗算/除算/平方 根命令の形式検証 HOL‑light における, 初等関数演算のための証明済みアルゴリズム 9
10. FP 演算の特性の検証手法 明確な C における FP 演算に関連した特性の検証手法が提案 (Boldo, Filliâtre, 2007) 証明には, Caduceus ツールと Coq が使われた Caduceus における FP のサポートは, Coq の代わりに自動証明器 を使うために, Frama‑C 環境と Jessie プラグインに移植された Frama‑C/Jassie によるいくつかの事例研究を経て, 複雑な VC の検 証は, いまだ Coq や PVS を用いた検証も必要であることがわかっ た しかし, 自動ソルバ Gappa の貢献により, 自動化の観点では重要な 向上が起きた 10
11. FP 検証における抽象解釈の成功 FP プログラム検証に対する抽象解釈の使用は, 工業的な状況で, 間違いな く非常に良い成功を起こした FP ランタイムエラーを見つけるために, 15 の関係抽象値域を用いた (Miné, 2004) → Astrée ツールに実装。Airbus A380 の制御コマンドソフトウェ アにランタイムエラーがないことを検証 Fluctuat 抽象解釈に基づく別のツール ランタイムエラーがないことの検証だけにとどまらず, 有限/無 限精度における同じコードの実行の比較, giving some bounds on the difference between the two. 11
12. 以前の SPARK の制限 GNATprove における以前の float のサポート SPARK のすべての FP 値を Why3 の実数値に translate し, それぞ れの算術演算後に暗黙に丸め特性を付与していた FP 値 ↔ 実数の対応付けが (無限大や NaN を除くと) 単射でない 例: FP値 +0 と ‑0 は, 実数 0 に translate される → もし入力言語が ‑0 と +0 を区別している場合, プログラムの translate は健全でない 公理集合の無矛盾性と適合性は review によってのみ保証 12
13. 筆者の提案手法 抽象解釈 (区間解析) と定理証明 (近年の SMT ソルバの FP サポート) な どの様々な技術を組み合わせ ランタイムエラーだけでなく, ユーザーにより与えられる関数特性 の検証を可能. しかも高水準の自動化 提案手法は, ビットレベル演算のサポート向上と同様の過程を従っ ているので, その際は SMT ソルバの bitvector のネイティブサポー トを利用した 13
14. Future Work 筆者の提案手法は, SPARK の現在の産業使用の, FP 演算による典型的な 例で成功 → しかしこの方法は, プログラムのより発展的な関数特性(実数の純粋数 学演算に関するなど) の証明に対しては, Frama‑C や Why3 などの先進 的な検証には及ばない 短期的な視点としては, 両手法を統合すること 進行中の SOPRANO プロジェクトの, プロトタイプバックエンドソ ルバ COLIBRI と AE_fpa の向上 14