Verified Systems by Composition from Verified Components Fei

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

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

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

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. 4

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

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. 6

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: in bottom-up component composition. 7

Why validate circular dependencies between component properties? C 1 C 2 Eventually (A) Eventually (B) X ? X A = FALSE B = FALSE Eventually (A) and Eventually (B) 8

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

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. 10

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. – p is verified assuming A(p) hold. • The environment of C – is the set of components that C interacts with; – varies in different compositions. 11

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. 12

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. 13

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

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

Tiny. OS [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. 16

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

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

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 19

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

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

Verification of Sensor Component Output_Ack Done_Ack Env … Assumptions 22

Network Component 23

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

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

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

Sensor-to-Network Component 27

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) Until. After (C_Ret); After (ADC. Pending) Eventually (A_Intr); After (A_Intr) Never (C_Intr+A_Intr+S_Schd+N_Schd+R_Intr) Until. After (A_Ret); After (STQ. Empty = FALSE) Eventually (S_Schd); After (S_Schd) Never (C_Intr+A_Intr+S_Schd+N_Schd+R_Intr) Until. After (S_Ret); After (NTQ. Empty = FALSE) Eventually (N_Schd); After (N_Schd) Never (C_Intr+A_Intr+S_Schd+N_Schd+R_Intr) Until. After (N_Ret); After (RFM. Pending) Eventually (R_Intr); After (R_Intr) Never (C_Intr+A_Intr+S_Schd+N_Schd+R_Intr) Until. After (R_Ret); 28

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

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

Verification and Complexity • Check the property of SN on the abstraction. Compositional Reasoning: Step 3 and Step 1 1 2 Component Time Sensor-to-Network 89 m 15. 45 s Sensor 10 m 41. 01 s Memory 208. 48 M 33. 673 M 3 Network 18. 0 S 6. 8239 M 4 Abstraction 0. 1 s 0. 1638 M 31

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. 32

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

Refinement Example (cont. ) • To enable P 2, introduce and check Property P 3 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. P 3 was verified on the revised Sensor. • Inclusion of P 2 and P 3 into the abstraction leads to verification of P 1. 34

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. 35

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

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. 37

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. 38