Source Code Formal Verification. Riccardo Sisto, Politecnico di Torino

Transcription

1 Source Code Formal Verification Riccardo Sisto, Politecnico di Torino

2 Formal Verification: Not Just High-Level Models How to improve correctness up to the coding phase? Possible solutions: Automatic code generation from (verified) models Direct code verification (by safe model extraction) 2

3 Automatic Code Generation High-Level Model Properties Testing Formal Verification Low-Level Model Code Generator Implementation Choices Implementation (code) 3

4 Direct Code Verification (by model extraction) Abstract Model Formal Verification Model extraction, Abstraction, Slicing,... Interpretation of results Testing Implementation (code) Properties Results referring implementation 4

5 Discussion Direct code verification hides models (only code view) In principle could be applied even when only code is available (no design documentation needed) 5

6 Slicing Abstraction technique for source code Consists of Computing an (enlarged) influence cone of all observable elements (i.e. those referred in the formula to be verified) Generating a new abstracted source code where all the elements not included in the influence cone have been removed 6

7 Other Preliminary Static Analyses Dataflow and controlflow analyses used by optimizers can give useful information for model construction: Elimination of useless variables/statements Function inlining (with static polymorphism resolution) Cycle unrolling pointer analysis 7

8 Tools For concurrent Software: Several deadlock analysis tools for Ada (1994, ) JCAT Java deadlock analysis (Politecnico di Torino, 1998) JPF Java model checking (NASA, 1999) Bandera Java model checking (KSU, 2000, 2006) Feaver/Modex ANSI-C model checking (Bell labs, 2002) TCBMC ANSI-C bounded model checking (Bell labs, 2005)... For sequential software: SLAM (Microsoft research, 2002) BLAST (Berkeley University, 2002) CBMC (Carnegy Mellon, 2004) 8

9 Feaver/Modex (cm.bell-labs.com/cm/cs/what/feaver) Model checking on ANSI-C sources using Spin Basic idea: smooth migration from testing to automated formal verification Extends the unit testing concept Can be integrated in systems for testing and revision control Used at Bell Labs on com software (e.g. telephone switches) Reference: G.J. Holzmann and M.H. Smith, An automated verification method for distributed systems software based on model extraction, IEEE Trans. on Software Engineering, 28(4),

10 Architecture ANSI-C Sources Default Generator Test Driver Model extractor Promela Source Abstraction Map Spin Feaver (GUI) Requirements Spin (simulator) error run.prx Checker (exe) Checker (C source) C compiler 10

11 Abstraction map A table of items of the form: C statement corresponding model Can be used to define Which statements are relevant for the model How these should be mapped to abstract models The default table is empty (no relevant statement) and can be populated automatically Maximum table size is the number of statements in the program 11

12 Abstraction Map Sample 1 (x->drv->trunk) false 2!((x->drv->trunk)) true 3 fenable(x,cfbl) true 4!((fenable(x,CFBL))) true 5 ((x->cwswit&swport)==0) (cswit&swport)==0 6! ((x->cwswit&swport)==0)!(cswit&swport)==0 7 x->cswit&=~swport cswit&=~swport 8 x->cswit =~Swport cswit =~Swport 9 x->drv->disconnect(x) acs!ctdis 10 x->drv->ring(x,ctring,ipc) acs!ctring 11 memcpy true

13 Test Driver It closes the system: Provides input and consumes output Creates processes It is not written in C, but in Promela (an extended version) The default version Can send any input at any time 13

14 Properties The most common properties are builtin It is possible to write assertions in the code which are then checked automatically It is possible to express LTL properties Default Properties are the built-in ones 14

15 Srengths of Feaver/Modex No much knowledge on formal verification needed Similar to well-known V&V techniques based on testing 15

16 Just to have an idea of tractable programs Honeywell DEOS (Digital Engine Operating System) real-time operating system for modular avionics The DEOS kernel is written in C lines of code 20 classes, 6 threads The DEOS kernel has been verified/debugged by Bandera (using the C/C++ frontend) Some new bugs not detected during testing have emerged using Bandera 16

17 Just to have an idea of tractable programs PathStar (Call processing software, Lucent) lines of C code 1000 of which relevant for the interesting properties. PathStar has been analyzed by TrailBlazer (a system based on Feaver) Abstraction map: 250 entries Test driver: 450 lines Generated Promela code: 2600 lines 17

18 Some Open Problems Automatic Filtering of results False errors elimination Automation in abstraction selection Support and automation for compositional verification 18