講義のアウトライン（前半）
情報エレクトロニクスシステム特論
第2回：ソフトウェア（検証）の基礎
ソフトウェア検証とその重要性
– ソフトウェア検証とは？
– なぜ必要なの？
– 検証事例
– 検証器のデモ
ソフトウェア検証と数学
小林 直樹
ソフトウェアの（形式的）検証とは？
ソフトウェアが意図通りの動作をするかどうかを数理科
学的手法を用いて実行前に機械的に解析・検証
– 常に正しい結果を出力するか？
– 途中で異常終了をしないか？
– 不正にデータやネットワークにアクセスをしないか？（c.f. コン
ピュータウィルス）
– パスワードなどの個人情報を外部に漏らさないか
解析・検証結果の正しさは理論的に保証
(c.f. テスト実行によるデバッグ）
ソフトウェア検証の今後の展望と課題
テスト実行 vs 形式的検証
テスト実行
– 典型的な入力について実際に実行して動作を
確認する（c.f. 車の試験走行）
– 絶対に誤りがないという保証はできない
形式的検証
– 実行前に、ソフトウェアを分析し、動作に問題
がないことを検証
– 絶対に誤りがないことを理論的に保証
ソフトウェアの検証の重要性（１）
人命や財産にかかわるさまざまなシステム
がソフトウェアによって制御
– 飛行機など交通システムの制御プログラム
– 原子力発電所・医療器具などの制御プログラム
– 銀行の口座管理システム（ATM等）
– 電子商取引・電子マネー
– 電子政府
⇓
ソフトウェアの欠陥が人命や財産が失われる
大事故に直結！
ソフトウェアの欠陥による問題の例
ひかり電話のソフトウェアによる不具合（２００６年）
エレベータ制御ソフトウェアの欠陥
（２００６年）
東京証券取引所のシステムの不具合（みずほ証券
の誤発注問題など）
ウラニウムプラントでの放射能漏れ事故
（２００１年１２月、オーストラリア）
種々のコンピュータウィルス
Ariane 5ロケットの墜落（1996年６月、ヨーロッパ）
放射線治療器具の誤動作による医療事故（アメリカ）
このままだといずれもっと重大な事故が...
朝日新聞２００６年４月９日
動かないコンピュータ 裁判の行方
（記事は略）
日経コンピュータ2008年5月号
「バグ頻発 デジタル製品」
発表のアウトライン
ソフトウェアの検証の重要性（２）
ソフトウェアの品質を保証するための規格制定の
動き
– IEC61508
• ソフトウェアを含む電子機器の安全性の国際規格
• 最高レベル(SIL4)では形式的手法の使用を強く推奨
– ISO26262
• 車載ソフトウェアの機能安全性に関する規格
• 欧州の標準規格になる可能性大
⇓
形式的手法を用いることがソフトウェアを
組み込んだ製品の販売の必須条件に
ソフトウェア検証とその重要性
– ソフトウェア検証とは？
– なぜ必要なの？
– 検証事例
– 検証器のデモ
ソフトウェア検証と数学
ソフトウェア検証の今後の展望と課題
– Linux の一部（バークレイなど）
– Windowsのデバイスドライバ（マイクロソフト）
“Things like even software verification, this has
been the Holy Grail of computer science for many
decades, but now in some very key areas, for
example, device driver verification we’re building
tools that can do actual proof about the software
and how it works in order to guarantee the
reliability.” - Bill Gates, 2002.
型推論
– ML
– TyPiCal
抽象解釈
– ASTREE, ...
モデル検査
– BLAST, SLAM
– Spin
定理証明支援器
– Coq, Isabelle, PVS, ...
検証できる性質
Airbus社の飛行機制御ソフトウェアの検証
（フランス）
smart card の検証（オランダ）
OSの一部のコードの検証（米国）
自動化、効率
ソフトウェア検証手法と
検証ツール
ソフトウェア検証の具体事例
2007 Turing Award Winner
1996 Turing Award Winner
NEW YORK, February 4, 2008 –
ACM, the Association for
Computing Machinery, has named
Edmund M. Clarke, E. Allen
Emerson, and Joseph Sifakis the
winners of the 2007 A.M. Turing
Award, widely considered the most
prestigious award in computing, for
their original and continuing
research in a quality assurance
process known as Model Checking.
For seminal work introducing
temporal logic into computing
science and for outstanding
contributions to program and
system verification
Amir Pnueli
Edmund M. Clarke
1980 Turing Award Winner
「ソフトウェアは硬い」
For his fundamental
contributions to the
definition and design of
programming languages.
C. Antony R. Hoare
日経エレクトロニクス２００５年１２月号
講義のアウトライン
ソフトウェア検証とその重要性
– ソフトウェア検証とは？
並行プログラムの検証器TyPiCal
複数のプロセスが互いに通信をしながら動作する
並行プログラムを解析
request
– なぜ必要なの？
– 検証事例
– 検証器のデモ
ソフトウェア検証と数学
ソフトウェア検証の今後の展望と課題
reply
request?x.reply!”ok” | request!task.reply?y
送信
並行実行
受信
各通信がいずれ必ず成功するか否かを検証
例：キャンセル要求を送信したらいずれ必ずサーバに受理
されるか（c.f. 東証のシステム）
５人の哲学者問題
デッドロック状態
講義のアウトライン
ソフトウェア検証とその重要性
ソフトウェアと他の製品との違い
（c.f. 数学と物理学）
ソフトウェア検証と数学
– ソフトウェアと他の製品との違い
– ソフトウェアの動作は数学的に定まっている
ハードウェア
（車、包丁、ス
キー板、...)
– ソフトウェア検証 = 定理証明
– ゲーデルの不完全性定理とソフトウェア検証
ソフトウェア検証の現状と今後の展望
テスト実行の結果を信頼できるか？
フェルマーの最終定理：
an + bn = cnを満たす正の自然数a,b,c,n(n≥3)は
存在しない
テスト至上主義者の証明(?)：
a=1, b=1,c=1,n=3 では成り立たない
a=2, b=5,c=3,n=4 では成り立たない
a=4, b=7, c=2,n=6では成り立たない
...
以上、十分たくさんの数について等式が成り立たな
いことを確認したので、フェルマーの最終定理は正
しい。
ソフトウェア
支配する 製品完成までの流れ
法則
物理学 設計・シミュレーション→
実装→
テスト（実証）
数学！
設計・検証（証明）→
実装→
テスト→
検証（証明）
テスト実行の結果を信頼できるか？
仮説：
ソフトウェアAにはバグがない
とある企業での仮説の検証手法：
月曜日にテストして正しく動作
火曜日にテストして正しく動作
...
日曜日にテストして正しく動作
以上、すべての曜日で正しく動作することを確認し
たのでAにはバグがない
講義のアウトライン
ソフトウェア検証とその重要性
ソフトウェア検証と数学
– ソフトウェアと他の製品との違い
– ソフトウェアの動作は数学的に定まっている
– ソフトウェア検証 = 定理証明
– ゲーデルの不完全性定理とソフトウェア検証
ソフトウェア検証の現状と今後の展望
ソフトウェアの意味は
数学的に定まっている！
(c, σ0) ↓σ1 :
「初期状態σ0の下でプログラムcを実行すると
状態σ1 で終了する」
の定義：
(a, σ0)↓n
───────────
(X:=a, σ0)↓[n/X]σ0
(b, σ0)↓true
(c0, σ0)↓σ1
───────────
(if b then c0 else c1, σ0)↓σ1
{(c,σ0,σ1) | (c, σ0) ↓σ1 }は
F(S) = {(X:=a, σ, [n/X]σ0) | (a, σ0)↓n }
∪{(c0;c1, σ0, σ2) |
(c0, σ0, σ1),(c1, σ1, σ2) ∈ S}
∪...
の最小不動点（F(S)=Sを満たす最小の集合S)
(c1, σ1)↓σ2
(c0;c1, σ0)↓σ2
(b, σ0)↓false
(c1, σ0)↓σ1
───────────
(if b then c0 else c1, σ0)↓σ1
(b, σ0)↓true (c;while b do c, σ0)↓σ1
(b, σ0)↓false
──────────────
─────────
(while b do c, σ0)↓σ1
ソフトウェアの意味は
数学的に定まっている！
(c0, σ0)↓σ1
───────────
(while b do c, σ0)↓σ0
ソフトウェア検証 = 定理証明
gcd ≡
while not(X=Y) do
if X<Y then Y:=Y-X
else X:=X-Y
は初期状態でX>0かつY>0ならば停止する
⇔
Sを Fの最小不動点とすると、
σ0(X)>0 かつσ0(Y)>0ならば、
あるσ1が存在して、
(gcd, σ0, σ1) ∈ S
が成り立つ
ソフトウェア検証は難しい？
以下のプログラムは停止するか？
i := 1;
while not (a>0 & b>0 & c>0 & n>2 & an + bn = cn)
{
a := factor_of(i, 2); /*** i = 2a3b5c7n... ***/
b := factor_of(i, 3);
c := factor_of(i, 5);
n := factor_of(i, 7);
i := i+1;
}
...それでもソフトウェアの検証は有効
完全性を諦める
検証器で受理する
正しく動作する
ソフトウェア
ソフトウェア
誤りのある
ソフトウェア
不完全性定理とソフトウェア検証
ゲーデルの第一不完全性定理（の帰結）
– 自然数の算術（+, ×）を含む論理体系の任意の論理式
の真偽を正しく判定するアルゴリズムは存在しない
ソフトウェア検証
= （自然数を包含する論理体系における）定理証明
⇒ 「完全無欠な」ソフトウェア自動検証器は
作れない！
...それでもソフトウェアの検証は有効
完全性を諦める
検証器で受理する
正しく動作する
ソフトウェア
ソフトウェア
誤りのある
ソフトウェア
人手を借りる
ソフトウェア
検証すべき性質
自動生成
ソフトウェアの
正しさの
必要十分条件
（論理式）
人間＋
証明支援器
Yes
or
No
ソフトウェア自動検証器の仕組み
ソフトウェア自動検証器の仕組み
検証すべき性質（停止性、型エラー、デッド
ロックなど）を制限
ソフトウェアの動作を抽象化（完全性を断念）
⇒
検証の問題が決定可能な数学の問題に帰着
有限集合上の性質（SATなど）
言語（正規言語など）の包含関係判定問題
線形計画問題
検証すべき性質（停止性、型エラー、デッドロックな
ど）を制限
ソフトウェアの動作を抽象化（完全性を断念）
⇒
検証の問題が決定可能な数学の問題に帰着
講義のアウトライン
ソフトウェア検証とその重要性
ソフトウェア検証と数学
ソフトウェア検証の現状と今後の展望
– ソフトウェア検証をとりまく現状と問題点
– 今後の展望と課題
なぜこれでうまく行くのか？
そもそもソフトウェアは（普通の）人間が書くもの
⇒ 規模は大きくても、個々の動作原理は単純
（正しさがフェルマーの最終定理の正しさに
依存するようソフトウェアは普通書かない）
ソフトウェア検証を取り巻く現状
産業界での適用はまだ限定的
– Airbus社の飛行機制御ソフトウェアの検証
（フランス）
– smart card の検証（オランダ）
– Windowsのデバイスドライバの検証（米国）
– 一部の組み込みシステム（日本）
多くのソフトウェアは未検証のまま無保証に
近い状態で流通
– Windows updateを一年に起動する回数は？
ソフトウェア検証の現状の問題
検証技術の研究者側の問題
– 自動化がまだ不十分（使いこなすには専門知識
が必要）
– 扱えるソフトウェア、検証できる性質が不十分
ソフトウェア検証の現状の問題
ソフトウェア開発者側の問題
– 検証技術を使うための基本的素養の欠如
• ソフトウェアの仕様を正しく記述できない
• ソフトウェアの動作環境を正しくモデル化できない
– 「形式的検証は役に立たない」という迷信
– モラルハザード
• ソフトウェアに誤りがあっても重大な賠償責任が生じな
い(c.f. 製造物責任法）
• 「不具合をテストで検出するのは極めて困難」
（みずほ誤発注問題に関する訴訟の東証側の鑑定意
見。日経コンピュータ2008年5月号より）
ソフトウェア検証の現状の問題
日本のソフトウェア産業の構造的問題
– 基本ソフトウェアはほとんど輸入
– 大企業はソフトウェアの上流工程の設計のみ。
実装は下請けへ
• 場合によっては下請けからさらに（情報科学を学んで
いない）学生アルバイトプログラマへ？
• 下請け会社は大規模な研究費を投じて新しい技術を
研究する余力なし (c.f. Microsoft Research)
ソフトウェア検証をとりまく今後の展望
検証技術は着実に進歩
– 自動化、適用範囲の向上
計算機性能の向上
ソフトウェアの規模や適用範囲、開発リスクの
増大
– ソフトウェアの既存の（テスト偏重の）開発手法の
行き詰まり
⇒ソフトウェアの形式的検証の活躍の場の増大
さもなくば...
コンピュータ社会の崩壊
第2部：代表的なソフトウェア検証手法
型推論
モデル検査
定理証明支援器
型に基づくプログラム検証
型とは？
– 狭義には、値の種類（int, float, int→int,...)
– 広義には、値の性質を抽象化したもの
• int(ρ): メモリ領域ρにおかれた整数
• File(r*c): read-only で最後にcloseすべきファイル
型推論
– 型を自動推論する仕組み
– ML, Haskellなどの言語にすでに実用化
– 型を一般化することによってプログラムのさまざ
まな性質を自動推論可能
MLにおける型の役割
値の種類を規定
– int: 整数の型
– int→int: 整数を引数にとり、整数を返す関数の型
型を自動推論
型推論に成功すれば実行時型エラーが
起きないことを保証
型推論の例
fun twice f x = f (f x)
αf = αx → αf
x
型推論の例
型推論の例
fun twice f x = f (f x)
αf = αx → αf x
αf = αf x → αf(f
αf = αx → αf x
αf = αf x → αf(f x)
αtwice = αf → αx → αf(f
x)
型推論の例
x)
プログラム検証のための型の拡張例
fun twice f x = f (f x)
αf = αx → αf x
αf = αf x → αf(f x)
αtwice = αf → αx → αf(f
fun twice f x = f (f x)
x)
型方程式を解く
α f = α x → αx
αf x = αf(f x) = αx
αtwice = (αx → αx ) → αx → αx
File(r*c): 最初に何回かreadした後、
一回closeすべきファイルの型
File((r+w)*c): 何回かreadまたはwriteした後、
一回closeすべきファイルの型
拡張された型の推論例
let rec f(n, x) =
if n=0 then close(x)
else (read(x);f(n-1, x))
in
let r = newr*c()
in f(3, r)
let rec f(n, x: R(ρ) ) =
if n=0 then close(x)
else (read(x);f(n-1, x))
in
let r: R(η) = newr*c()
in f(3, r)
拡張された型の推論例
R (ρ) ≤ R (c)
let rec f(n, x: R(ρ) ) =
if n=0 then close(x)
else (read(x);f(n-1, x))
in
let r: R(η) = newr*c()
in f(3, r)
9
拡張された型の推論例
R (ρ) ≤ R(r); R (ρ)
型に基づくプログラム検証の応用例
例外解析
R (η) ≤ R (ρ)
ファイルやメモリなどの使用法の検証
sem(η) ⊆ r*c
配列アクセスの検証
ρ ≤ c + (r; ρ )
η≤ ρ
sem(η) ⊆ r*c
sem(μr.c + (r; ρ )) ⊆ r*c
セキュリティプロトコルの検証
並列プログラムのデッドロックやレース（がな
いこと）の検証
型に基づく検証の利点と欠点
利点
– （ほとんどの場合）全自動
– 高速
– プログラムの一部がなくても（その仕様があれ
ば）検証可能
第2部：代表的なソフトウェア検証手法
型推論
モデル検査
定理証明支援器
欠点
– 検証できる性質が限定
– 検証精度が粗い（many false positives)
モデル検査
検証対象（ソフトウェア検証の場合はソフト
ウェアそのもの）を有限状態遷移系Mとしてモ
デル化
検証したい性質を時相論理式ϕとして記述
Mがϕを満たすか否かを自動検証
ハードウェアやプロトコル検証に多くの適用例
最近ではソフトウェア検証への適用が進む
モデル化の例
(Y:=X; X:=Y+1)
X=0, Y=0
pc=0
X=0, Y=0
pc =1
X=1, Y=0
pc =2
時相論理(CTL)
モデル化の例
(Y:=X; X:=Y+1)
||
(Y:=X; X:=Y+1)
X=0, Y=0
pc =(1,0)
X=0, Y=0
pc=(0,0)
X=1, Y=1
pc =(2,1)
X=1, Y=0
pc =(2,0)
X=2, Y=1
pc =(2,2)
X=1, Y=0
pc =(2,1)
X=0, Y=0
pc =(1,1)
X=0, Y=0
pc =(0,1)
ϕ ::= p 原始命題
ϕ1 ∧ ϕ2
¬ϕ
ある遷移列のある時刻でϕが成立
EF ϕ
EG ϕ ある遷移列で常にϕが成立
EX ϕ ある一つの遷移をした後にϕが成立
AF ϕ どのような遷移列でもある時刻でϕが成立
AG ϕ どのような遷移列でも常にϕが成立
AX ϕ どのような（一つの）遷移をした後でもϕが成立
X=1, Y=0
pc =(2,2)
X=1, Y=0
pc =(1,2)
X=1, Y=0
pc =(0,2)
X=1, Y=1
pc =(1,2)
仕様の例
時相論理(CTL)
EF p
(Y:=X; X:=Y+1) || (Y:=X; X:=Y+1)
AG p
EG p
p
p
p
p
p
X=0 ∧ pc=(0,0) ⇒ EF (X=2)
p
...
...
p
...
...
...
...
p
...
...
...
...
p
...
...
初期状態のXの値が０ならば、X=2となりうる
X=0 ∧ pc=(0,0) ⇒ AF (X=2 ∧ pc=(2,2))
初期状態のXの値が０ならば、どの実行においても
終了時にX=2が成り立つ（不成立）
X=0 ∧ pc=(0,0) ⇒ AG (X≤2)
初期状態のXの値が０ならば、どの実行においても
Xの値は常に２以下
モデル検査の応用
CPUの設計の検証
種々のアルゴリズムの検証
– IEEE Futurebus+の検証 [Clarke et al. 1992]
• モデル検査により、IEEE標準のcache coherence
protocol のバグを発見
ソフトウェアの検証（next slide)
ソフトウェアモデル検査
ソフトウェアの（自動）抽象化＋モデル検査
ソフトウェアモデル検査ツール
– BLAST
• Linuxのデバイスドライバなどの検証に適用
– SLAM
• Windows のデバイスドライバなどの検証に適用
モデル検査の利点と欠点
利点
– 型推論に比べて詳細な性質を検証可能
– モデル作成後は自動
– 誤りがある場合に反例を生成
欠点
– 効率（状態爆発）
– モデル作成の際に人手が必要な場合あり
第2部：代表的なソフトウェア検証手法
型推論
モデル検査
定理証明支援器
定理証明支援器とは？
定理証明器を用いたソフトウェア検証
手法１: 検証条件生成器を用いる手法
対象（数、関数、データ、プログラムなど）や
その性質を表す命題およびその証明を形式
的に記述するための言語を提供
証明の正しさを機械的に検査
注釈つきプログラム
Verification Condition Generator (VCG)
証明を行う手助け（半自動証明）
検証条件
証明からプログラムを抽出
定理証明支援器
VCGの出力例
VCGへの入力例
Require Export Why.
let rec div (m:int) (n:int) : int {variant m} =
{ m >=0 and n > 0 }
関数が停止する理
if m < n then
由（再帰呼び出しの
関数の
たびに減少する値）
0
入力仕様
else
1 + div (m-n) n
{exists r:int. (0 <= r < n and m = result*n + r)}
関数の出力仕様
(* Why obligation from file "div.mlw", line 7, characters 3-50: *)
(*Why goal*) Lemma div_po_1 :
forall (m: Z),
forall (n: Z),
自動生成された
forall (HW_1: m >= 0 ∧ n > 0),
検証条件の一つ
forall (HW_2: m < n),
(exists r:Z, (0 <= r ∧ r < n) ∧ m = (0 * n + r)).
Proof.
(* FILL PROOF HERE *)
ここに証明を書く
Save.
(* Why obligation from file "div.mlw", line 6, characters 9-20: *)
(*Why goal*) Lemma div_po_2 :
...
定理証明器を用いたソフトウェア検証:
その他の方法
論理と計算（Curry-Howardの対応）
構成的プログラミング
– Curry-Howardの対応に基づき、証明からプロ
グラムを自動抽出
プログラミング言語の意味論からプログラム
および仕様までをすべて定理証明支援器の
中で記述し、証明
Curry-Howardの対応による証明の表現
A ∧ Bの証明: (Aの証明, Bの証明)
A ∨ Bの証明 : inl(Aの証明）またはinr(Bの証明）
A → Bの証明：
Aの証明をもらってBの証明を返す関数
例. A → (B → (A∧B))の証明：
λx:A.λy:B.(x, y)
(A ∨ B) → (A → C) → (B → C) → Cの証明：
λx: A ∨ B.λy: A → C.λz: B → C.
case x of
inl(a) => y a
| inr(b) => y b
証明 = プログラム
命題 = 型
証明の検査 = 型検査
証明の標準化 = 計算
Curry-Howardの対応による証明の表現
（述語論理）
∀x:S.P(x)の証明：
Sの要素xを引数としてP(x)の証明を返す関数
∃x:S.P(x)の証明：
Sの要素aとP(a)の証明の組
例. (∀x:nat.x<x+1) → ∀y:nat.∃z:nat.(y<z)の証明:
λp: (∀x:nat.x<x+1) .λy:nat. (y+1, p y)
証明とプログラム抽出
∀x:S.∃y:T.P(x,y) の証明：
λx:S. (e, “P(x,e) の証明”)
P(x,e)の証明部分を除いて得られる
λx:S. e
は、型Sの値aを受け取ってP(a,ｂ）を満たすbを返す関数
例：∀x: nat list.∃y: nat list.
(sorted(y) ∧ permutation(x,y))
を証明すれば、その証明からソーティング関数を抽出できる
定理証明器の利点と欠点
利点
– 原理的にはどのような仕様でも検証可能
欠点
– 自動化が困難
– 論理学に関する専門知識が必要
定理証明支援器（Coq, Isabelle など）の
応用事例
数学への応用
– ４色問題の証明
– フェルマーの最終定理の証明（n=3,4の場合）
– 代数学の基本定理の証明
情報科学への応用
– ゲーデルの第一不完全性定理の証明
– 種々のアルゴリズム（ソーティング、暗号アルゴリズム、
Presburger算術など）の証明
– 種々のソフトウェア（コンパイラ、JavaCardなど）の検証
レポート課題（一つ選択）
本講義で取り上げなかったソフトウェアの不
具合による事故、損害の事例を挙げよ
次の項目のいずれかについて、調べたことを
まとめよ
– MLの型推論アルゴリズム
– モデル検査器 Spin
– LTL
– 定理証明支援器 Coq
© Copyright 2024 Paperzz
