On the Reliability of Correct Programs

Transcription

1 On the Reliability of Correct Programs Marie-Claude Gaudel LRI, Université de Paris-Sud & CNRS April 2010 LAAS 1

2 Programs? Everybody knows what it is Let us try: A program is a piece of text in a (hopefully) well defined language There is a syntax, some semantics, and compilers A program is a very detailed solution to a much more abstract problem [Ball, 2005] {i=0 ; read(x); repeat { i++ ; perd(x, i); } until term(i,x) ; April 2010 LAAS 2

3 Why are programs useful? They can be compiled and then embedded into some system {i=0 ; read(x); repeat { i++ ; perd(x, i); } until term(i,x) ; output input April 2010 LAAS 3

4 Interlude {i=0 ; read(x); repeat { i++ ; perd(x, i); } until term(i,x) ; CORRECT! April 2010 LAAS 4

5 Interlude (cont) A map is not the territory A program text, or a specification text, or a model, is not the system April 2010 LAAS 5

6 Systems? A system is a dynamic entity, embedded in the physical world It is observable via some limited interface/procedure It is not always controllable Quite different from a piece of text (formula, program) or a diagram input output April 2010 LAAS 6

7 Systems are the actual objects of interest How to guarantee that a system satisfies certain properties? Properties? Texts in natural languages whenever a request is made it holds continuously until it is eventually granted no buffer overflows Formulas in a given specification logic G( request (request U grant)) Sets of mandatory or forbidden execution paths in some graphical model Constraints on some well-known quantities: WCET, MTTF, etc Beware the abstraction gap (between the entities in the system and the concepts mentioned in the properties) April 2010 LAAS 7

8 All that is well-known? Found on the web September 25, 2009, news of a respected university «Professor XXX,, said for the first time a team had been able to prove with mathematical rigour that an operating-system kernel - the code at the heart of any computer or microprocessor - was 100 per cent bug-free and therefore immune to crashes and failures.» April 2010 LAAS 8

9 All that is well-known? Found on the web September 25, 2009, news of a respected university «Professor XXX,, said for the first time a team had been able to prove with mathematical rigour that an operatingsystem kernel - the code at the heart of any computer or microprocessor - was 100 per cent bug-free and therefore immune to crashes and failures.» Some blogger s comment: «Yup, it's only as secure as the properties you've defined and proven THAT SAID: If the core of the OS has been proven to have many strong properties, e.g. it can't crash under reasonable hardware assumptions, then building a more complex (and well tested!) OS on that proven core could be very profitable!» April 2010 LAAS 9

10 Program Proving and System Testing April 2010 LAAS 10

11 A few words on Program Proving Program {i=0 ; read(x); repeat { i++ ; perd(x, i); } until term(i,x) ; + Logical Assertions Theorem Prover Seen as a formula (for instance, good old {Pre} Prog {Post}) Static Analyser Libraries axiomatisation Proof envt SAT solver April 2010 LAAS 11

12 Progresses and Tendencies Significant and continuous progresses Great theorem provers: HOL/Isabelle, Coq, PVS Powerful static analysis techniques: Astree Tendency Environments specialised for given couples <programming language, specification/assertion language> : Java/JML, C#/Spec# The assertion language is tailored for the programming language Libraries of abstract modelling types (collections, etc) Specialised theories and tools for specific errors: arithmetic overflow, out of bound array indexing, Domain-aware theories and tools (f.i. device drivers) Big industrial investments: HP, Microsoft Research, Big academic investment: VSI Grand Challenge, April 2010 LAAS 12

13 Achievements and challenges Side-effects and aliasing handled by various program logics Reasoning about heap structures and aliasing, but pb with invariants of complex object structures Reasoning on breaking out of loops, or catching exceptions solved by logics for abrupt termination Dynamic method binding and inheritance partially handled by behavioural subtyping Gap between some abstract modelling types and concrete types (quantifications, _.equals() versus = ) Non-termination (loop variants, model-checkers) handled in various cases [Leavens, Leino, Muller, FAC 2007] Open issue: impact of such proofs on the reliability of the resulting system April 2010 LAAS 13

14 From the VSI Manifesto «A verified program is one that has been proved to satisfy certain desirable and clearly specified properties, and to be free of certain rigorously specified kinds of error. The proof itself is free from error, because it has been checked or even generated with the aid of software tools» «The lack of collaboration with other areas of computing is also a current weakness. Formal methods researchers must recognize the need to collaborate outside of the formal methods community in areas such as requirements analysis, testing, and fault tolerant systems, in seeking ways to aid the cause of reliable software.» April 2010 LAAS 14

15 A few words on System Testing The actual system is executed for a finite set of selected inputs NB: selected test sequences for reactive systems These executions are observed, and a decision is made on their conformance w. r. t. some specification Issues : Selection Oracle Control, non-determinism Assessment of the result of a test campaign Selected test input Oracle failure/ correct Ouput, observation April 2010 LAAS 15

16 ??? Run-time verification, Model-checking programs, Coverage in model-checking, Bounded model-checking, Model-based testing, Zoom in on What people call Model Based Testing What is Test Generation using Model-checking April 2010 LAAS 16

17 Models: an heavily overloaded* term Models as they are used for model-checking are just annotated graphs A finite set of states, S Some initial state, s 0 A transition relation between states, T S S A finite set of atomic propositions, AP A labelling function L : S P(AP) Richer similar notions: Labelled Transition systems, LTS Finite State machines, FSM Control Graphs State charts, * For a physicist a model is a differential equation; For a biologist, it may be mice or frogs April 2010 LAAS 17

18 Model-Checking Model ϕ, Temporal Formula Model Checker valid Counter example Algorithmic approach: exhaustive exploration of the model A well-known example: SPIN, where models are described in Promela and checked against LTL formulas Big issue: size of the model (esp. due to concurrency). Huge models are attainable but it is not enough April 2010 LAAS 18

19 Model-based testing Selection, driving and oracle are based on some model Almost everything may be considered as a model (may be not wrong ) Examples of considered models: Annotated graphs, control graphs Pre- and Post-conditions, invariants Finite State Machines (FSM), possibly extended (EFSM) Labelled Transition System (LTS), possibly with distinction between inputs and outputs Back to [Chow 78] for FSM, [Brinksma 88] for LTS, and then many others Selected test input Oracle failure/ correct Ouput, observation April 2010 LAAS 19

20 Control and Observation A popular test strategy: transition coverage s x:y-> s is a transition. In state s, input x must produce output y and move to state s Questions control: how to put the System Under Test into a state equivalent to s? observation: how to check that after receiving x and issuing y, the SUT is in a state equivalent to s? See next slide Meta-question: what brings transition coverage? The number of tests is finite, NO MORE! April 2010 LAAS 20

21 One of the model-based tests for s -x/y-> s? h/answ s s w/λ*(s s,w) homing sequence s h I* => answ O*: then the SUT state should be equivalent to s s. w I*: in the formal description, w leads from s s to s. x/y? z/λ*(s, z) z belongs to the separating set of s preamble transition execution observation April 2010 LAAS 21

22 Too big models? => Random Testing These methods can be classified into three categories : those based on the input domain Adaptive random testing Stochastic optimisation (simulated annealing, genetic algorithms) those based on the environment (usage model) and those based on some knowledge of the behaviour of the SUT (some SUT model) Random walks NEW: Coverage-biased random selection April 2010 LAAS 22

23 Coverage-biased random selection Old classical idea for simulation and testing: random walks An isotropic random walk in the state space of a model (a control graph, etc) is: a sequence of states s 0, s 1,, s n such that s i is chosen uniformly at random among the successors of the state s i-1, It is easy to implement and it only requires local knowledge of the graph. Numerous applications in Testing (protocols), simulation Model-checking (recent works) April 2010 LAAS 23

24 Drawback of classical isotropic random walks The resulting coverage is dependent on the topology a c d Classical random walks, length 3: Pr(a; c; d) = = Pr(b; e; f) = 0.5 Uniform random sampling of traces, length 3: Pr(a; c; d) = Pr(b; e; f) = 0.1 b f e April 2010 LAAS 24

25 Uniform generation of bounded paths in a graph Counting [Flajolet et al.]: Given any vertex v, let l v (k) be the number of paths of length k that start from v we are on vertex v with m successors v 1, v 2,..., v m condition for path uniformity: choose v i with probability l vi (k-1)/l v (k) Application to various criteria based on paths Generalisation to node coverage, branch coverage Assessment of the quality of the coverage Application to C programs (AuGuSTe) and to models The RASTA group, LRI, [ISSRE 2004], [Random Testing Workshop 2006], [Random Testing Workshop 2007], [MBT/ETAPS 2008], [MSR 2009] April 2010 LAAS 25

26 ??? Run-time verification, Model-checking programs, Coverage in model-checking, Bounded model-checking, Model-based testing, Zoom in on What people call Model Based Testing What is Test Generation using Model-checking? Is it the miracle we wait for? April 2010 LAAS 26

27 Test generation using modelchecking Exploits the fact that model-checkers may yield counter-examples Given ϕ, a required property of the SUT Given a model M of the SUT Model-check M for ϕ The model-checker will reject ϕ and produce a counter-example, i.e. a trace that satisfies ϕ, i.e. a test sequence for ϕ Popular, most model-checkers have been experienced for test generation Nice, but April 2010 LAAS 27

28 New issues, and good old ones ϕ must be a formula in some temporal logic (not always convenient) An example: ϕ: AG( request (request U grant)) ϕ: EF(request (request U grant)) One counter-example is not enough (because of the universal quantification) => exhaustivity and coverage issues The finite model is an over-approximation of the system Feasability, constraint solvers April 2010 LAAS 28

29 Some Conclusions (1) Significant advances in Model Checking, Program Proving, System Testing Each one makes use of the other ones in some occasions Very good specialised tools Some politically correct and frequent comments: All these methods are now used together, and this convergence will lead to great results Model-checking is very powerful and solves most problems in static analysis and model based testing and, more generally, in verification April 2010 LAAS 29

30 Some Conclusions (cont.) We are not so far Many tricky scientific issues, f.i. Standard temporal logics can specify only regular properties; correctness of procedures w. r. t. pre- and post conditions are not regular [Alur 2005] Integration of model-checking and program proving is not as clear as it is claimed by some authors. Constraint solving remains a bottle-neck: most success stories on large programs static analysis or testing are either limited to linear arithmetic, or not fully automated Dealing with the abstraction gap in proving (reasoning with equality) and testing (oracle) is not solved in general April 2010 LAAS 30

31 Last Conclusion But the trickiest issue is April 2010 LAAS 31