Presentation is loading. Please wait.

Presentation is loading. Please wait.

Verifying Component Substitutability Nishant Sinha Sagar Chaki Edmund Clarke Natasha Sharygina Carnegie Mellon University.

Similar presentations


Presentation on theme: "Verifying Component Substitutability Nishant Sinha Sagar Chaki Edmund Clarke Natasha Sharygina Carnegie Mellon University."— Presentation transcript:

1 Verifying Component Substitutability Nishant Sinha Sagar Chaki Edmund Clarke Natasha Sharygina Carnegie Mellon University

2 Substitutability Check Assembly A Component C Component C’ P ?

3 Motivation Component-based Software –Software modules shipped by separate developers –Undergo several updates/bug-fixes during their lifecycle Component assembly verification –Necessary on upgrade of any component –High costs of complete global verification –Instead check for substitutability of new component

4 Substitutability Check Local check –Only for upgraded components –Reuses previous verification results Two phases: –Containment check All interface behaviors of the previous component contained in new one –Compatibility check Safety with respect to other components in assembly: all global specifications still hold

5 Containment, Compatibility Component C Containment Check Compatibility Check Identical Behaviors New Behaviors Lost Behaviors Upgraded Component C’

6 Substitutability Check Formulation –Obtain a finite interface behavioral model of all components by abstraction: labeled kripke structures –Containment: Use under- and over- approximations –Compatibility: Use dynamic assume-guarantee reasoning

7 Predicate Abstraction into LKS Labeled Kripke Structures – Composition semantics –Synchronize on shared actions Represents abstractions State-event traces – p !q q    !p

8 Predicate Abstraction into LKS L1 lock = 0 if (x < y) lock=1 x < y if (x >= y) lock = 0 x < y if (x < y) x >= y lock=1 void OSSemPend(…) { L1: lock = 1; if (x < y) { L2: lock = 0; … } if (x >= y) { … L3: lock = 0; … } else { … } L2  if (x >= y) x >= y   L3 

9 Component Assembly A set of communicating concurrent C programs –No recursion, procedures inlined Each component abstracted into a Component LKS –Communication between components is abstracted into interface actions C1C1 C2C2 C3C3 M1M1 M2M2 M3M3 Component Assembly C Abstraction M Predicate Abstraction

10 Containment Check Goal: Check C µ C’ –All behaviors retained after upgrade –Cannot check directly: need approximations Idea: Use both under- and over- approximations Solution –Compute M: C µ M –Compute M’: M’ µ C’ –Check for M µ M’ C Containment Check Identical NewLost C’

11 Containment (contd.) CC’ M M’ over-approxunder-approx µ ? True C µ C’ False, CE CE 2 C ? False, Refine M CE 2 C’ ? True, Refine M’ C * C’, CE provided False True M C C’ M’

12 Containment (contd.) Computing over-approximation –Conventional predicate abstraction Computing under-approximation –Modified predicate abstraction –Compute Must transitions instead of May

13 Compatibility Check C Identical NewLost C’ Assume-guarantee to verify assembly properties –Related: Cobleigh et. al. at NASA Ames Reuse previous verification results Use learning algorithm for regular languages, L* Automatically generate assumption A M 1 || A ² P M 2 ² A M 1 || M 2 ² P AG-NonCircular

14 L* learner Learning Regular languages: L* Proposed by D. Angluin, improved by Rivest et al. –Learning regular sets from queries and counterexamples, Information and Computation, 75(2), 1987. Polynomial in the number of states and length of counterexample Minimally adequate Teacher IsMember( trace  ) IsCandidate( DFA D ) a b a b Unknown Regular Language ±Counterexample/ Yes Modelchecker Yes/No Minimum DFA

15 Learning for Verification Model checker as a Teacher –Possesses information about concrete components –Model checks and returns true/counterexample Learner builds a model sufficient to verify properties Relies on both learner and teacher being efficient Finding wide applications –Adaptive Model Checking: Groce et al. –Automated Assume-Guarantee Reasoning: Cobleigh et al. –Synthesize Interface Specifications for Java Programs: Alur et al. –Regular Model Checking: Vardhan et al., Habermehl et al.

16 Compatibility Check R 1 : M 1 || A ² P R 2 : M 2 ² A true L* Assumption Generation A CE CE Analysis Actual CE M 1 || M 2 2 P -CE for A +CE for A Teacher M 1 || M 2 ² P true

17 Handling Multiple Components AG-NC is recursive –(Cobleigh et al.) R 1 : M 1 || A ² P R 2 : M 2 ² A M 1 || M 2 ² P M 1 k A 1 ² P M 2 k A 2 ² A 1 M 3 ² A 2 M 2 k M 3 ² A 1 M 1 k M 2 k M 3 ² P Each A i computed by a separate L* instantiation

18 Compatibility of Upgrades Dynamic AG: Reuse previous verification results Can we reuse previous assumptions directly? –NO: upgrades may change the unknown U to be learned Requires Dynamic L* –Unknown language U changes to U’ –Goal: Continue learning from previous model A –Central Idea: Re-validate A to A’ which agrees with U’ C Identical NewLost C’

19 Dynamic L* L* maintains a table data-structure to store samples Definition: Valid Tables –All table entries agree with U Theorem –L* terminates with any valid observation table When U changes to U’, –Suppose the last candidate w.r.t. U is A –Re-validate OT of A w.r.t. U’ –Obtain A’ from OT –Continue learning from A’

20 Implementation MAGIC framework (now part of ComFoRT) –Compatibility phase with Dynamic AG Industrial benchmark –Inter-process Communication (IPC) software –4 main components – CriticalSection, IPCQueue, ReadMQ, WriteMQ Evaluated on single and simultaneous upgrades – WriteMQ and IPCQueue components Properties –P 1 : Write after obtaining CS lock –P 2 : Correct protocol to write to IPCQueue

21 Experimental Results Upgrade# (Property) #Mem QueriesT orig (msec)T ug (msec) Ipc 1 (P 1 ) 279226013 Ipc 1 (P 2 ) 308169414 Ipc 2 (P 1 ) 358328617 Ipc 2 (P 2 ) 23280510 Ipc 3 (P 1 ) 363362417 Ipc 3 (P 2 ) 258164914 Ipc 4 (P 1 ) 355110224

22 MAGIC Schema Verification Yes System OK Abstraction Model Counterexample Valid? System Abstraction Guidance Yes No Counterexample Abstraction Refinement Improved Abstraction Guidance No Spurious Counterexample Assume-Guarantee Reasoning

23 Conclusion Automated Substitutability Checking –Containment and Compatibility –Reuses previous verification results –Handles multiple upgrades –Built upon CEGAR framework Implementation –MAGIC/ComFoRT framework –Promising results on an industrial example

24 Ongoing Work Assume-Guarantee for Liveness Other AG Rules, e.g., Circular Containment Check –Compare any two similar programs


Download ppt "Verifying Component Substitutability Nishant Sinha Sagar Chaki Edmund Clarke Natasha Sharygina Carnegie Mellon University."

Similar presentations


Ads by Google