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

8
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.
• p is verified assuming A(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
BackgroundVerification 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
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
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
Verification of Composed Components
(1) Abstraction
26
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_IntrA_IntrS_SchdN_Schd
  R_Intr) UntilAfter (C_Ret)
• After (ADC.Pending) Eventually (A_Intr)
• After (A_Intr) Never (C_IntrA_IntrS_SchdN_Schd
  R_Intr) UntilAfter (A_Ret)
• After (STQ.Empty FALSE) Eventually (S_Schd)
• After (S_Schd) Never (C_IntrA_IntrS_SchdN_Schd
  R_Intr) UntilAfter (S_Ret)
• After (NTQ.Empty FALSE) Eventually (N_Schd)
• After (N_Schd) Never (C_IntrA_IntrS_SchdN_Schd
  R_Intr) UntilAfter (N_Ret)
• After (RFM.Pending) Eventually (R_Intr)
• After (R_Intr) Never (C_IntrA_IntrS_SchdN_Schd
  R_Intr) UntilAfter (R_Ret)

29
Abstraction
Env (Environment)
30
Abstraction (cont.)

• A sub-component property is included if it is
• In the cone-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 P1 on 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 check Property 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.