Automated creation of verification models for C-programs

1. Automated creation of verification models for C-programs Yury Yusupov Saint-Petersburg State Polytechnic University Prof. Vsevolod Kotlyarov Motorola Software Center The Second Spring Young Researchers Colloquium onSoftware Engineering Saint-Petersburg May 29-30 2008

2. IntroductionProblems, goals, and solution One of the features of modern design – software component reuse Problems:how to reuse legacy code? Goals:to quickly understand legacy components for their reuse in a new product Solution:apply verification technologies • Automatic modeling of a legacy component at a higher abstraction level • Formal verification of model properties

3. Verification process Requirements Program system Implementation Formalization: Analysis of program or requirements and creation of model in formal language System properties System model Verification: Searching inconsistencies and checking system properties Verdict: the system does or does not meet its requirements

4. Types of errors found with verification Documentation inconsistencies – typos, missing or incorrect references, absence of definitions, etc. Transition inconsistency (non-determinism) –non- deterministic behavior. Safety violations – prohibited events may happen, security violation (unauthorized usage of a system) is a particular case. Deadlocks – incomplete specifications. Unreachability –unreachable (never used) system states. Certain run-time errors – like an uninitialized attribute usage or out of bounds error – lists overflow, incorrect array indexing, enumerated type overflow.

5. VRS-based verification process correction Behavior formal model in form of formalization verification System basic protocols VRS verdict reqs Behavior properties System can be presented with requirements, source program code, or UML model

6. Basic protocol –a simple MSC diagram, which specifies: pre-condition - the state of the system where the system shall perform some activity process part - the activity itself (transmission of a message or performance of an action) post-condition - the state of the system after the activity is performed pre-condition process part action message post-condition

7. Goal of the work Source system representation Behavior formal model in form of formalization basic protocols Reqs semi-automatic basic protocols UML automatic basic protocols C-program manual Problem: high efforts for manual formalization of source code Goal: reduce manual efforts through automation

8. Proposed solutionKlocwork™ as a tool for formalization • Static analysis • Control flow visualization • Graphical view of a program structure • … • Automated analysis of C, C++, and Java source code – checkers • Detect a wide variety of code defects and security vulnerabilities • Klocwork™ allows to write additional C and C++ code checkers • 2 application programming interfaces (API) • Code style analysis (AST – Abstract Syntax Tree) • Control and data flow (MIR – Medium-level Intermediate Representation) Klocwork provides automated source code analysis and creation of intermediate views of code

9. Klocwork™ extensibility featureDefect detection with checkers Source code custom checker custom defect Klocwork™ defects are reported defects enable/disable source file is analyzed, defects are detected config Klocwork + custom checker = instrument for C code analysis and translation into basic protocols

10. Custom checker: realization Source code Basic protocols Klocwork interface Checker interface Module of basic protocol generation Code analysis and AST creation Pre-condition Process part • Nodes • handling module: • expression • function call • if-then-else • for • while • switch-case • … Post-condition Tree traversal module Abstract Syntax Tree

11. The autoformalization featurebased on Klocwork™ toolset • BPX (Basic Protocol eXtractor) • plug-in for Klocwork in form of DLL (dynamically loaded library) • ~3.1 KLOC in C • Input data • Abstract Syntax Trees of source files • Output data • Basic protocols in MSC-PR (Phrase Representation) format • Reflect usage and change of variables • Reflect function calls • Preserve program control flow • Represent program semantics • Preserve the project structure Automatic extraction of basic protocols from Klocwork AST

12. … int function() { int a,b,c; c = 3; if ( c>5 ) {a = 1; } b = a; return 0; } … Simple example Basic protocols automatically extractedfrom a C-code

13. Verification of C-programswith extended VRS technology correction formalization C program verification Behavior formal model in form of basic protocols VRS KlocWork™ verdict BPX reqs Behavior properties

14. Creation of multilevel models and architecture recovering System High-level system model File level Function level Source code module level … … … … … Forward engineering Reverse engineering

15. 10x Manual approach Time Automatic approach 1x medium large small Size of project source code First experiment results for C-projects • Decreasing: • formalization time • manual efforts • errors in program model • (human factor) • Simplifying: • program logic understanding • verification process Formalization time reduction ~10x vs manual formalization

16. Further work • Verification of large C-projects with VRS technology • Investigating the scalability limits • Creation multilevel behavior models • Generation of multilevel behavior scenarios • Adaptation to Java code • Reusing AST traversal and basic protocol generation algorithms for JAVA checker creation

17. THANK YOU • Q&A