BOGOR – A Flexible Framework For Creating Model Checkers

1. BOGOR – A Flexible Framework For Creating Model Checkers Presented by : Roli Shrivastava 20 March 2007

2. Model Checking What is Model Checking?

3. Model checking is a process of checking whether a given model satisfies a given logical formula MODEL CHECKING • Effective technology for verification and debugging in hardware and more recently in software domains. • Detecting coding flaws that are hard to detect using existing quality assurance methods • Verifying that system models and implementations satisfy crucial temporal properties Model checking

4. WHATS WRONG with EXISTING TOOLS?? • Motivation for domain-specific model checking….. • Existing Model Checkers tools are Spin, FDR and NuSMV • support fixed input languages • state-space representations • reduction and exploration algorithms. • Model-driven development : • Domain-specific model checkers are more effective than general purpose model checkers. • Product-line architectures and reusable middleware infrastructure. Model checking

5. Continued… • Synergistic blending of automated quality assurance technique. • Sheer variety of application domains and computation models. Model checking

6. SOLUTION to the ABOVE PROBLEM BOGOR • Developed by the SAnToS Group at Kansas State University and the ESQuaReD Group at University of Nebraska (Lincoln). Bogor is an extensible and customizable software model checking framework • state of the art software model checking algorithms • Visualizations • user interface designed to support both general purpose and domain-specific software model checking. BOGOR

7. WHY BOGOR? In contrast to many model checkers, • Bogor is a highly modular and extensible software model checking framework • well-designed API using design patterns make it possible to add/replace/refine module implementations • crucial features for domain-specific customizations BOGOR -Features

8. WHY BOGOR continues… • Features: • Direct Support of OOL • Extensible Modeling Language • Open Modular Architecture • Design for Encapsulation • Pedagogical Materials BOGOR -Features

9. FEATURES in DETAIL • Direct support of features (object-oriented) • dynamic creation of threads and objects • object inheritance • virtual methods • exceptions, garbage collection, etc. • Bogor's modeling language can be extended • new primitive types • expressions, and commands associated with a particular domain (e.g, multi-agent systems, avionics, security protocols, etc.) • a particular level of abstraction (e.g., design models, source code, byte code, etc.). BOGOR -Features

10. FEATURES contd… • Bogor's open architecture well-organized module facility allows new algorithms • for state-space exploration, state storage, etc • new optimizations (e.g., heuristic search strategies, domain-specific scheduling, etc.) • Bogor has a robust feature-rich graphical interface implemented as a plug-in for Eclipse • Bogor is an excellent pedagogical vehicle for teaching foundations and applications of model checking • it allows students to see clean implementations of basic model checking algorithms • to easily enhance and extend these algorithms in course projects BOGOR -Features

11. Cited: http://courses.projects.cis.ksu.edu/index.php

12. BIR : BOGOR Intermediate Representation • Supported types - basic: boolean, int, long, float, double - range types: int (lower, upper), long (lower, upper) - enumeration types: enum cards {spades, hearts, clubs, diamonds} - Non-primitive types • record, array, string, lock, extensions All types in BIR are bounded (finite) (e.g., int: -2147483648 to 2147483647) have a default value (e.g., int, long: 0) BIR

13. BIR Cont’d • Scope: functions and threads have own namespace, but can’t hide with global declarations • Locations: control pts in threads • Jump and Catch statements • Actions: assign, assert, assume, lock, throw, exit BIR

14. BIR: HIGH LEVEL / LOW LEVEL SYNTAX • High level Syntax • Used for manual understanding and model construction • Includes high-level programming constructs: • atomic, while, if, else-if, else, try, catch, skip, return, choose • During model checking, converted to low level • Low level Syntax • Used for automatic model extraction • Interleaving only happen between locations • Basic syntax: • loc[ation], live, do, when, visible, goto, catch, return BIR

15. Example: CounterExample • High-level system CounterExample { int i := 0; active[3] thread MAIN() { atomic choose when <i < 1> do i := i + 1; when <i < 2> do i := i + 2; else do i := i + 3; end end } } BIR Cited: http://bogor.projects.cis.ksu.edu/manual/ch02s14.html

16. BIR Low Level system CounterExample { int i := 0; active [3] thread MAIN() { boolean temp$0; boolean temp$1; boolean temp$2; ANY_THROWABLE atomicCatch$Local; loc loc0: do { Atomic.beginAtomic(); } goto loc1; loc loc1: do invisible { temp$0 := i < 1; temp$1 := i < 2; temp$2 := !((temp$0 || temp$1)); } goto loc2; loc loc2: when temp$0 do invisible { } goto loc3; when temp$1 do invisible { } goto loc5; when temp$2 do invisible { } goto loc7; loc loc3: do { i := i + 1; } goto loc4; loc loc4: do { } goto loc9; loc loc5: do { i := i + 2; } goto loc6; loc loc6: do { } goto loc9; loc loc7: do { i := i + 3; } goto loc8; loc loc8: do { } goto loc9; loc loc9: do { Atomic.endAtomic(); } goto loc10; loc loc10: do { } return; loc atomicCatch: do { Atomic.endAtomic(); throw atomicCatch$Local; } goto atomicCatch; catch ANY_THROWABLE atomicCatch$Local at loc1, loc2, loc3, loc4, loc5, loc6, loc7, loc8 goto atomicCatch; } extension Atomic for edu.ksu.cis.bogor.projects.bogor.ext.atomicity.AtomicModule { actiondef beginAtomic (); actiondef endAtomic (); } throwable record ANY_THROWABLE {} } Cited: http://bogor.projects.cis.ksu.edu/manual/ch02s14.html BIR

17. Cited: http://courses.projects.cis.ksu.edu/index.php

18. COMPONENTS and MODULES • Front-End Components provide access to in-memory representations of BIR models • Interpretative Components provide access methods and data structures to interpret BIR models • Model Checking Components provide implementations of model checking algorithms Modular Architecture - BOGOR

19. Tier1 : Front End Module The following slides discuss about the Front End Module

20. Cited: http://courses.projects.cis.ksu.edu/index.php

21. Cited: http://courses.projects.cis.ksu.edu/index.php

22. Cited: http://courses.projects.cis.ksu.edu/index.php

23. SUMMARY OF TIER-1 • Bogor, like an Interpreter/compiler has front-end module • to process a BIR model textual representation • Build an in-memory representation suitable for analysis/model checking • The basic front-end has • Lexer • Parser • Well-formed-ness checke • + some data structures ( AST, symbol table etc) Tier-1 Summary - BOGOR

24. TIER 2 : Interpretative Component Module The slides following would discuss this component

25. Cited: http://courses.projects.cis.ksu.edu/index.php

26. Cited: http://courses.projects.cis.ksu.edu/index.php

27. I-VALUE FACTORY • Values are created using the I-Value Factory • Provide access methods to :- i) get the type of the value. ii) create the default value of a certain type. iii) create new int values, with or without types. Tier-2 I-value - BOGOR

28. I-STATE FACTORY provide methods to: • create the initial state i) needs to provide an interface to wrap state data: for example, global values, the local values of each thread, and the location of each thread, and the thread ids ii) can be extended to provide additional information • create thread descriptors (guaranteed to be unique) Tier-2 I-state - BOGOR

29. IExpEVALUATOR MODULE • evaluates an expression in a given context ISchedulingStrategyContext • contains methods to access the state and the executing thread id Tier-2 I-expEval - BOGOR

30. I-ACTION EVALUATOR MODULE • execute an action in a given context ignore the array of IBacktrackingInfo for now • action executions usually change the state Tier-2 I-action - BOGOR

31. SUMMARY OF TIER-2 • BOGOR Interpretative components are similar to an imperative Language interpreter’s • has a module to evaluate expressions • Has a module to evaluate actions • Factories are used to create Values and States , thus decoupling usage and creation • Several Data-structures are generated/ used for model checking Tier-2 summary - BOGOR

32. Tier 3 : Model Checking Module The coming slides discusses Model checking Module in detail.

33. Cited: http://courses.projects.cis.ksu.edu/index.php

34. I-SEARCHER MODULE • Navigating the State Space • I-Searcher controls how we traverse the state space graph. Tier-3 I-searcher - BOGOR

35. Cited: http://courses.projects.cis.ksu.edu/index.php Tier-3 I-searcher - BOGOR

36. Cited: http://courses.projects.cis.ksu.edu/index.php

37. I-SCHEDULER MODULE Cited: http://courses.projects.cis.ksu.edu/index.php Tier-3 I-scheduler - BOGOR

38. STEPS FOR SCHEDULING Cited: http://courses.projects.cis.ksu.edu/index.php Tier-3 I-scheduler - BOGOR

39. Continues…. Cited: http://courses.projects.cis.ksu.edu/index.php Tier-3 I-scheduler - BOGOR

40. WHY Do We Need I-Scheduler • 􀂄 Used to: • determine enabled transitions • determine which transition to take • create strategy information • 􀂄 DefaultSchedulingStrategist • Full state-space exploration • the scheduling policy ensure that each state is visited • At each choice point, the info contains • the number of enabled transitions, and • the last chosen transition index • advise() simply increase the last chosen transition index until all are chosen Tier-3 I-scheduler - BOGOR

41. I-BACKTRACKING • Since the analyzer is not holding states in the stack, if it needs to back-track and return to a previously encountered state, it needs an “undo” operation to run the transitions in the reverse direction. • Information needed to backtrack • state, thread ID, etc. • scheduling information like • which nondeterministic choice was made, if any • specific info for each kind of action, transformation, etc. Tier-3 I-backtracking - BOGOR

42. I-STATE MANAGER MODULE • Used to keep track states that have been visited before storing the states • Also, assigns a unique number for each stored state (state id) • Hence uses the number instead of the actual state in the DFS stack. Tier-3 I-state-manager - BOGOR

43. SUMMARY FOR TIER-3 • Implementations of Model checking functional aspects are modular • Can be customized to a specific-domain application: • Search algorithms can be customized to used heuristics to find bugs faster • Scheduler can be customized to enforce a specific scheduling policy • State manager can be customized to allow different encodings Tier-3 Summary- BOGOR

44. IS BOGOR FLEXIBLE ?? ( KIASAN ) • Kiasan – A Verification and Test-Case Generation Framework for Java based on Symbolic Execution • Built by customizing the following Bogor Modules: • IValueFactory: • Concrete value representations symbolic value representations. • IStateFactory: • State representations of the data structure symbolic data values and to include data constraints. • IStateManager: • Kiasan’s symbolic execution engine performs stateless Search. • The traditional state matching is changed to never store states stage. • JVM Extension Interpretation: • The JVM code in Bogor a code that interprets byte codes including exploration of conditional paths as well. Kiasan

45. Capabilities of KIASAN • automatic checking of code against user-supplied contracts • flexible control over the depth/coverage of checking by adjusting tool parameters • automatic generation of both abstract and concrete execution path • automatic generation of JUnit test cases Kiasan

46. Bogor within the development Process • Eclipse-Based Graphical user Interface • Eclipse like Bogor is implemented in JAVA => tight integration of Bogor and its GUI contents and extensions. • Encapsulation in other tools • Developing Bandera, Cadena ( for CORBA ) by customizing BOGOR. • Helped in space and time improvements (more than 3 times as compared to SPIN / dSPIN) • Placement of model checking in a development process • Model checking at design time • Space state will be smaller

47. SUMMARY of EXPERIENCE using BOGOR • In 1 year Bogor has been downloaded more than 1000 times by individuals in 32 countries. • Till date, more than 35 substantive extensions of Bogor. • Has around approx 23 APIs • Extensions requires generally few 100 lines of code • Mostly modeled from the already existing extensions • It is a robust and well-reasoned foundation : used for modern Software systems. Summary of Exp

48. ANY QUESTIONS??