•3 likes•718 views

Download to read offline

Report

對於formal verification充滿好奇，於是花了些時間自學並分享於若渴計畫，此分享目的是讓有興趣的朋友可以抓住關於formal verification paper的重點而不迷失於名詞解釋中。 Q&A紀錄與補充: https://hackmd.io/s/SJ2hFiDd-

Follow

- 1. Introduction: Formal Verification for Code @若渴 2017.8.20 <ajblane0612@gmail.com> AjMaChInE
- 2. Outline • The ToyList sample in Isabelle/HOL – Induction – Simplification • Backward proof • Program verification using the axiomatic techniques of Hoare • Papers • Attack views
- 4. Proving Theorems on a Computer p.4, http://ghourabi.net/Lecture/L051016.pdf 半自動，一半要自己組合證明
- 5. Higher Order Logic (HOL) • HOL is predicate calculus that allows variables to range over function and predicates( ) • HOL is sufficient for expressing most mathematical theories • HOL is also a mechanical proof development system ∀, ∃, ∄ Peter V. Homeier, etc., “Trustworthy Tools for Trustworthy Programs a Verified Verification Condition Generator”
- 6. HOL system theorem you want to prove Isabelle’s proof search
- 7. 2. Functional Programming in HOL, “Programming and Proving in Isabelle/HOL” For example, ToyList
- 8. 定義List可以加入element，並證明 rev(rev(xs)) = xs HOL system Theorem you want to prove Isabelle’s proof search ToyList model
- 10. Isabelle Keyword: datatype • 定義一個型態的操作，for example: Evaluation: value “Cons True (Cons False Nil)” ? List Cons True (Cons False Nil) 也看成是True #(False# Nil) Cons True [ False Nil] [True False Nil] * Isabelle有做term match動作 * constructors: Cons, Nil
- 11. Isabelle Keyword: primrec (1) • The keyword primrec indicates that the recursion is of a particularly primitive kind where each recursive call peels off a datatype constructor from one of the arguments. Input 1 Input 2 Output Input 1 Input 2 Output function constructor當成要展開對象 有constructor，但無須展開 app function的符號
- 12. Isabelle Keyword: primrec (2) value "rev (a # b # c # *+)“ ? rev (a # b # c # []) (rev b#c) @ (a#[]) rev(c) @ (b # [])@ a # [] rev(c) @ b # ([]@ a) # [] rev(c) @ b # a# [] … c#b#a#[]
- 13. 透過 Isabelle syntax(datatype/ primrec) 定義出一個functional modeling，接 下來利用此functional modeling可以 proof哪些theorems ?
- 14. 建立 Theorem • It establishes a new theorem to be proved, namely rev (rev xs) = xs. • It gives that theorem the name rev_rev, for later reference. • It tells Isabelle (via the bracketed attribute simp) to take the eventual theorem as a simplification rule: future proofs involving simplification will replace occurrences of rev (rev xs) by xs.
- 15. 由於Properties of recursively defined functions are best established by induction
- 16. apply(induct xs) apply auto • tactic (theorem proving function): “induct” tells Isabelle to perform induction on variable xs. • “auto” tells Isabelle to apply a proof strategy called auto to all subgoals. isabelle不能proof done，@@?
- 17. 進一步來看(1) apply(induct xs) 只是 induction的描寫 因為定義是對constructor做展開，所 以加入constructor來做展開
- 18. 進一步來看(2) apply(auto) 自動induction proof 證明 Isabelle無法繼續再證下去了，因為找不到現有定義的equations
- 21. 進一步來看(4) 對constructor展開=> ToyList.list.Con x1 app( xs ys) 然後再做app
- 24. 特別來看(6) = ToyList.list.Cons x1 app xs ToyList.list.Nil假設正確
- 25. 終於 • 定理rev_rev指定simplification rule，也就是isabelle看 到rev(rev xs)就取代為xs • ?xs 為free variable，也就是定理rev_rev在做 simplification rules時 ?xs 為任意list
- 26. Review • the standard (interactive) theorem proving procedure: state a goal (lemma or theorem) after building functional modeling; proceed with proof until a separate lemma is required; prove that lemma; come back to the original goal. • a specific procedure that works well for functional programs: induction followed by all-out simplification via auto.
- 27. Until now, we have proved theorems using only induction and simplification, but any serious verification project requires more elaborate forms of inference.
- 28. Backward Proof: Isabelle Style • Backward proof: “To prove P ∧ Q, prove that P is true and prove that Q is true” • For example: ?A match P ?B match (Q;P) subgoal 1 subgoal 2 Isabelle code: apply(rule conjI)
- 29. Backward Proof: Isabelle Style • Backward proof: “To prove P ∧ Q, prove that P is true and prove that Q is true” • For example: subgoal 1 Isabelle code: apply(rule conjI) apply(assumption) apply(erule conjI) apply (erule theorem): use when the conclusion of theorem matches the conclusion of the current goal and the first premise of theorem matches a premise of the current goal
- 30. Backward Proof: Isabelle Style • Backward proof: “To prove P ∧ Q, prove that P is true and prove that Q is true” • For example: ?A match Q ?B match P Isabelle code: apply(erule conjI) apply(rule conjI)subgoal 1 subgoal 2
- 31. Backward Proof: Isabelle Style • Backward proof: “To prove P ∧ Q, prove that P is true and prove that Q is true” • For example: Isabelle code: apply(erule conjI) apply(rule conjI) apply(assumption) apply(assumption) 可改為使用blast prover: apply(blast)
- 32. Backward Proof: Isabelle Style • Backward proof: “To prove P ∧ Q, prove that P is true and prove that Q is true” • For example:
- 33. Note of Logical Rules • I 為 Introduction rules • E為 Elimination Rules • Elimination rules work in the opposite direction from introduction rules • A;B means A=>B or for example: Isabelle / Proof General Cheat Sheet
- 34. 這能做啥?
- 35. Program Verification • Program verification has recently received renewed attention from the Software Engineering community. One very general reason for this is the continuing and increasing pressure on industry to deliver software that can be certified as safe and correct. A more specific reason is that program verification methods fit very naturally the so-called Design by Contract methodology for software development, with the advent of program annotation languages like JML. Program verification fits in as the static, formal component of a methodology that encompasses also other validation methods like dynamic checking and testing. Jorge Sousa Pinto, etc. “Verification Conditions for Source-level Imperative Programs”
- 36. HOL system ToyList’s theorems ToyList model 如果程式的list可以轉成要推導定理的描述，那就 可以由Isabelle來驗證list的正確性。 Isabelle’s proof search
- 37. Program Verification using the Axiomatic Techniques of Hoare: Specification • 撰寫specification，specification可用Hoare tripe 表達，而Hoare triple由 {P}C{Q}組成，P為precondition，C為commands，Q為postcondition • Design by Contract (specification) Hoare tripe
- 38. Program Verification using the Axiomatic Techniques of Hoare: Inference System premise -> conclusion {x==1} y:0 {x==1 &&y==0} proof done?
- 39. Program Verification using the Axiomatic Techniques of Hoare: Inference System premise -> conclusion {x==1 &&y==0} i:=1 {x==1 && y==0 && i==1} proof done ? • Program behavior是否可以往下正確執行可由 axiomatic semantics (property)、operational semantics (computation) 、denotitional semantics (effect of executing a program) 所描述。其實你可以當成模擬器，只是變數 可以範圍執行不用明確的值。
- 40. Program Verification using the Axiomatic Techniques of Hoare: Verification Conditions(VC) {precondition} {postcondition} {VC1} C {VC2} {VC1} • VCGen可產生proof tree (proof obligation) ，再對此proof tree進行 proof，for example: {VC1}->{VC2} 一開始產生proof tree時，是沒有被 proof的。 • VCGen algorithms will be given as functions that take as input a Hoare triple and return a set of proof obligations (HOL) • Different proof trees to be constructed for the same conclusion specification
- 41. Program Verification using the Axiomatic Techniques of Hoare: Implementation specification syntax Proof obligation Sematic (Hoare inference system) program They can be Implemented by Isabelle
- 42. Abstract Syntax For example: Jorge Sousa Pinto, etc. “Verification Conditions for Source-level Imperative Programs” 從program切token收集成e, b, C, A, S集合。 S = {s1,s2,s3}
- 43. Semantic • Hoe to define behavior of a grammatically correct program state state’ e, b, C, A, S集合 中的element當 作function (variable values)
- 44. Semantic of the Above Syntax(1) function Jorge Sousa Pinto, etc. “Verification Conditions for Source-level Imperative Programs” Hoare triple
- 45. Semantic of the Above Syntax(2) Jorge Sousa Pinto, etc. “Verification Conditions for Source-level Imperative Programs”
- 46. Hoare Logic- {P}C{Q} • {P}C{Q} is true if and only if, for all states satisfying P, executing C terminates in a state satisfying Q. • Given a specification in the form of a Hoare triple {P} C {Q}, how can its validity be checked? – One could think of testing the program by running it with a battery of initial states satisfying the precondition P, and checking whether Q is satisfied after execution if the program terminates. – An another way is program-proof system that is a set of inference rules that can be seen as fundamental laws about programs. Hoare triple {P}C{Q} is derivable in the inference system of Hoare logic. {P} C{Q} 兩個方法的差別在於程式變數在一個範圍內，是否這個範圍都驗證到。 Jorge Sousa Pinto, etc. “Verification Conditions for Source-level Imperative Programs”
- 47. Inference System of Hoare logic (Axiomatic Semantics) Jorge Sousa Pinto, etc. “Verification Conditions for Source-level Imperative Programs” one rule for each command construct in the programming language the consequence rule, which allows us to derive a specification from another specification by strengthening the precondition or weakening the postcondition. For example:
- 48. p.19 Petros Papapanagiotou, “Program Verification Using Hoare Logic“
- 49. p.20 Petros Papapanagiotou, “Program Verification Using Hoare Logic“
- 50. p.21 Petros Papapanagiotou, “Program Verification Using Hoare Logic“
- 51. p.22 Petros Papapanagiotou, “Program Verification Using Hoare Logic“
- 52. precondition strengthening postcondition weakening p.23 Petros Papapanagiotou, “Program Verification Using Hoare Logic“
- 53. • if some Hoare triple can be proved using system H, then it is indeed valid according to the semantics (program behavior/state information) S = {s1,s2,s3} semantically valid (derivable) proof obligation proof done Jorge Sousa Pinto, etc. “Verification Conditions for Source-level Imperative Programs” syntax Proof done The Relationship between Hoare System and the Semantics of the Language
- 54. The Relationship between Hoare System and the Semantics of the Language • if some Hoare triple can be proved using system H, then it is indeed valid according to the semantics proof done proof done Jorge Sousa Pinto, etc. “Verification Conditions for Source-level Imperative Programs” S = {s1,s2,s3} semantically valid (derivable) proof obligation syntax proof done
- 55. • if some Hoare triple can be proved using system H, then it is indeed valid according to the semantics proof done proof done proof done Jorge Sousa Pinto, etc. “Verification Conditions for Source-level Imperative Programs” S = {s1,s2,s3} semantically valid (derivable) proof obligation syntax proof done The Relationship between Hoare System and the Semantics of the Language
- 56. Jasmin Christian Blanchette, etc., “Automatic Proof and Disproof in Isabelle/HOL” (ToyList sample) The new of teaching Isabelle is to let students think up intermediate properties and rely on automatic tools to fill the gaps.
- 57. Proof Search of Sledgehammer • It is Isabelle’s subsystem • Proof discovery using external provers Jasmin Christian Blanchette, etc., “Automatic Proof and Disproof in Isabelle/HOL”
- 59. • Build formal memory models (semantics) based on verification framework of Schirmer that provides the com language is intended to be a generic target for embeddings of sequential imperative programming language and completes with machine-checked HOL operational sematics, Hoare logic and VCGen. Harvey Tuch, “Formal Memory Models for Verifying C Systems Code” 增加 formal memory models 基本上就是擴充 syntax, semantics, VCGen支援更完整 的C spec
- 60. Gerwin Klein, etc., “Refinement in the Formal Verification of the seL4 Microkernel” forward simulation refinement steps in L4.verified 為什麼有兩個specification? The detailed model of kernel behavior
- 61. Thomas Sewell ,etc. ,“Translation Validation for a Verified OS Kernel”
- 62. • Remotely attacking network cards • A good question to ask is: would a system with a formally verified microkernel also be vulnerable to such an attack? And the answer is yes! Thomas Sewell ,etc. ,“Translation Validation for a Verified OS Kernel” Formally verified microkernel boot loader firmware hardware model建的不夠多啊
- 63. 那就多建models? • The seL4 kernel is a general-purpose OS microkernel measuring about 9500 source lines of C code and 600 lines of assembly code • It represents a large body of existing work, with over 200,000 lines of Isabelle/HOL proof • 建到人生都進去了，想浪漫一下嗎? Thomas Sewell ,etc. ,“Translation Validation for a Verified OS Kernel”
- 64. Reference • Isabelle Installation, https://www.cl.cam.ac.uk/research/hvg/Isabelle/installation.html • Theorem Proving 定理証明, http://ghourabi.net/Lecture/L051016.pdf • Tobias Nipkow, etc., A Proof Assistant for Higher-Order Logic • CS221: “Recursion, induction, loop invariants, call stacks”, http://slideplayer.com/slide/7351313/ • Peter V. Homeier, etc., “Trustworthy Tools for Trustworthy Programs a Verified Verification Condition Generator” • Jorge Sousa Pinto, etc. “Verification Conditions for Source-level Imperative Programs” • Norbert Schirmer, “Verification of Sequential Imperative Program in Isabellel/HOL” • Harvey Tuch, “Formal Memory Models for Verifying C Systems Code” • Jasmin Christian Blanchette, etc., “Automatic Proof and Disproof in Isabelle/HOL” • Isabelle / Proof General Cheat Sheet • Petros Papapanagiotou, “Program Verification Using Hoare Logic“ • Thomas Sewell , etc., “Translation Validation for a Verified OS Kernel” • Gerwin Klein, etc., “Refinement in the Formal Verification of the seL4 Microkernel” • Norbert Schirmer, “Verification of Sequential Imperative Program in Isabellel/HOL” • Joanna Rutkowska, On Formally Verified Microkernels (and on attacking them) • Theorem Proving with Isabelle/HOL An Intensive Course, http://isabelle.in.tum.de/coursematerial/PSV2009-1/