Verified Systems by Composition from Verified Components

1. Verified Systems by Composition from Verified Components Fei Xie and James C. Browne

2. Research Goal • Goal: • Construction of reliable and secure software systems from reliable and secure components; • Framework: • Composition of verified systems from verified components.

3. Research Challenges • How to verify components? • How to compose verified components to build larger verified components effectively?

4. Synergism between CBD and MC • Component-Based Development (CBD) • Introduces compositional structures to software; • Helps minimizing state spaces to be explored. • Model Checking (MC) • Provides exhaustive state space coverage; • Strong at detection of composition errors.

5. Agenda • Motivations • Our Approach • Component Model for Verification • Case Study: TinyOS • Verification of Components • Related Work • Conclusions and Future Work

6. Highlights of Our Approach • Temporal properties are specified, verified, and packaged with components. • Larger components are composed incrementally. • Component reuse considers component properties. • Verification of a property of a composed component • Reuses verified properties of its sub-components; • Follows abstraction-refinement paradigm; • Is based on compositional reasoning.

7. Compositional Reasoning • To verify a property on a software system • Step 1: Verification of component properties; • Step 2: Validation of circular dependencies; • Step 3: Derivation of the system property from component properties. • Previous work: in top-down system decomposition; • Our approach: inbottom-up component composition.

8. C1 C2 Eventually (A) Eventually (B) A = FALSE B = FALSE X X ? Eventually (A) and Eventually (B) Why validate circular dependenciesbetween component properties?

9. Agenda • Motivations • Our Approach • Component Model for Verification • Case Study: TinyOS • Verification of Components • Related Work • Conclusions and Future Work

10. Component • A component, C, has four parts: • Executable representation (models or sources); • Interface (procedural, messaging, …); • A set of externally visible variables; • A set of verified temporal properties of C.

11. Component Property • A property of C, is a pair, (p, A(p)). • p is a temporal property; • A(p) is a set of assumptions on environment of C. • pis verified assumingA(p)hold. • The environment of C • is the set of components that C interacts with; • varies in different compositions.

12. Component Composition • Connect executable representations of sub-components through their interfaces; • Selectively merge interfaces and visible variable sets of sub-components; • Verify properties of composed component by reusing properties of sub-components.

13. Instantiation of Component model on AIM Computation Model • Asynchronous Interleaving Message-passing • A system consists of a finite set of processes. • Processes execute asynchronously. • At any moment, only one process executes. • Interactions via asynchronous message-passing.

14. Instantiation of Component model on AIM Computation Model (cont.) • Component • Represented in Executable UML (xUML); • Messaging interface; • Composition • Establishing mappings among input and output message types of sub-components.

15. Agenda • Motivations • Our Approach • Component Model for Verification • Case Study: TinyOS • Verification of Components • Related Work • Conclusions and Future Work

16. TinyOS [Hill, et. al, `00] • A run-time system for network sensors from UC Berkeley; • Component-based • Different requirements of sensors; • Physical limitations of sensors; • High reliability required • Concurrency-intensive operations; • Installation to many sensors.

17. Agenda • Motivations • Our Approach • Component Model for Verification • Case Study: TinyOS • Verification of Components • Related Work • Conclusions and Future Work

18. Designer Property xUML Model Error Report S/R Query S/R Model Error Track Background:Verification of Closed AIM System Property Specification Interface xUML IDE Error Visualizer xUML-to-S/R Translator Error Report Generator COSPAN Model Checker

19. Verification of Primitive Components • Given a component and a property: • Create a closed system from the component and an environment process, env; • Constrain env with assumptions of the property; • Verify the property on the constrained system. Compositional Reasoning: Step 1

20. AIM Process Input message Type Component Boundary Output message Type Sensor Component

21. Sensor Component (cont.) Properties: Repeatedly (Output);After (Output) Never (Output) UntilAfter (OP_Ack);After (Done) Eventually (Done_Ack);Never (Done_Ack) UntilAfter (Done);After (Done_Ack) Never (Done_Ack) UntilAfter(Done); Assumptions:After (Output) Eventually (OP_Ack);Never (OP_Ack) UntilAfter (Output);After (OP_Ack) Never (OP_Ack) UntilAfter (Output);After (Done) Never (Done) UntilAfter (Done_Ack);Repeatedly (C_Intr);After (C_Intr) Never (C_Intr + A_Intr + S_Schd) UntilAfter (C_Ret);After (ADC.Pending) Eventually (A_Intr);After (A_Intr) Never (C_Intr + A_Intr + S_Schd) UntilAfter (A_Ret);After (STQ.Empty = FALSE) Eventually (S_Schd);After (S_Schd) Never (C_Intr + A_Intr + S_Schd) UntilAfter (S_Ret);

22. Output Env Output_Ack Done Done_Ack … Assumptions Verification of Sensor Component Sensor Component

23. Network Component

24. Network Component (cont.) Properties: IfRepeatedly (Data) Repeatedly (RFM.Pending); IfRepeatedly (Data) Repeatedly (Not RFM.Pending); After (Data) Eventually (Data_Ack); Never (Data_Ack) UntilAfter (Data); After (Data_Ack) Never (Data_Ack) UntilAfter (Data); After (Sent) Never (Sent) UntilAfter (Sent_Ack); Assumptions: After (Data) Never (Data) UntilAfter (Data_Ack); After (Sent) Eventually (Sent_Ack); Never (Sent_Ack) UntilAfter (Sent); After (Sent_Ack) Never (Sent_Ack) UntilAfter} (Sent); After (NTQ.Empty = FALSE) Eventually (N_Schd); After (N_Schd) Never (N_Schd +R_Intr) UntilAfter (N_Ret); After (RFM.Pending) Eventually (R_Intr); After (R_Intr) Never (N_Schd +R_Intr) UntilAfter (R_Ret);

25. (3) Refinement (2) Verification Verification of Composed Components (1) Abstraction

26. Abstract through removing details Abstraction Refine through adding details Refined Abstraction What is it? How to create it? How to refine it? Abstraction-Refinement Paradigm … Component

27. Sensor-to-Network Component

28. Sensor-to-Network Component Properties: Repeatedly (RFM.Pending); Repeatedly (Not RFM.Pending); Assumptions: Repeatedly (C_Intr); After (C_Intr) Never (C_Intr+A_Intr+S_Schd+N_Schd+R_Intr) UntilAfter (C_Ret); After (ADC.Pending) Eventually (A_Intr); After (A_Intr) Never (C_Intr+A_Intr+S_Schd+N_Schd+R_Intr) UntilAfter (A_Ret); After (STQ.Empty = FALSE) Eventually (S_Schd); After (S_Schd) Never (C_Intr+A_Intr+S_Schd+N_Schd+R_Intr) UntilAfter (S_Ret); After (NTQ.Empty = FALSE) Eventually (N_Schd); After (N_Schd) Never (C_Intr+A_Intr+S_Schd+N_Schd+R_Intr) UntilAfter (N_Ret); After (RFM.Pending) Eventually (R_Intr); After (R_Intr) Never (C_Intr+A_Intr+S_Schd+N_Schd+R_Intr) UntilAfter (R_Ret);

29. Verified Properties Verified Properties SP (Sensor) NP (Network) AIM Processes Assumptions Abstraction Env (Environment)

30. Abstraction (cont.) • A sub-component property is included if it is • In thecone-of-influence; • Not involved in invalid circular dependencies; • Enabled: Its environment assumptions hold on • Other components in the composition; • Environment of the composition. Compositional Reasoning: Step 2

31. Verification and Complexity • Check the property of SN on the abstraction. Compositional Reasoning: Step 3 and Step 1

32. Abstraction Refinement • An abstraction can refined by • (Introducing, verifying, and) enabling additional sub-component properties; • A property can be enabled by • enabling its assumptions on other components. • Currently requires user interactions.

33. Refinement Example • To check Property P1on Sensor-to-Network SN transmits any sensor reading exactly once. • Property P2 has been verified on Network. Network transmits any input exactly once. Assumption: A new input arrives only after Network acks the last input with a Sent message. • P2 is not enabled in the composition of SN.

34. Refinement Example (cont.) • To enable P2, introduce and checkProperty P3 on Sensor: Sensor outputs any sensor reading exactly once; After an output, Sensor will not output again until a done message is received. • A bug was found in Sensor and fixed. P3 was verified on the revised Sensor. • Inclusion of P2 and P3 into the abstraction leads to verification of P1.

35. Property and Assumption Formulation • Properties • Currently manually guided; • Derived from component specifications; • Added incrementally in component reuses. • Assumptions • Manual formulation; • Automatic generation • Often lead to complex assumptions. • Automatic generation heuristics in progress.

36. Agenda • Motivations • Our Approach • Component Model for Verification • Case Study: TinyOS • Verification of Components • Related Work • Conclusions and Future Work

37. Related Work • Compositional Reachability Analysis (CRA) [Graf and Steffen, Yeh and Young, Cheung and Kramer] • Compose and minimize the LTS of a software system from LTSs of its components. • Modular Feature Verification [Fisler and Krishnamurthi] • Verification of layered composition of features.

38. Conclusions and Future Work • An important step towards composition of verified systems from verified components. • Results are promising: • Detection of composition errors; • Significant reduction on verification complexity. • Future work • Automatic property and assumption generation; • Extended case studies.