Verifying Component Substitutability Nishant Sinha Sagar Chaki Edmund

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

Substitutability Check Assembly A P ? Component C C’ Component

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

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

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

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

Predicate Abstraction into LKS p • Labeled Kripke Structures – <Q, , T, P, L> • Composition semantics q – Synchronize on shared actions • Represents abstractions • State-event traces – <p, , q, , !p> !p !q

Predicate Abstraction into LKS L 1 lock=1 void OSSem. Pend (…) { L 1: lock = 1; if (x < y) { L 2: lock = 0; … } if (x >= y) { … L 3: lock = 0; … } else { … } } x<y lock=1 if (x < y) x >= y L 2 lock = 0 x<y if (x >= y) L 3 lock = 0 x >= y

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 C 1 C 2 C 3 Component Assembly C Predicate Abstraction M 1 M 2 M 3 Abstraction M

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

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

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

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

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 a b Yes/No Is. Member trace ) ( Minimally adequate Teacher L* learner Is. Candidate DFA D ) ( Modelchecker a Minimum DFA b ±Counterexample/ Yes Unknown Regular Language

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.

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

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

Compatibility of Upgrades C Lost C’ Identical New • 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’

Implementation • MAGIC framework (now part of Com. Fo. RT) – Compatibility phase with Dynamic AG • Industrial benchmark – Inter-process Communication (IPC) software – 4 main components – Critical. Section, IPCQueue, Read. MQ, Write. MQ • Evaluated on single and simultaneous upgrades – Write. MQ and IPCQueue components • Properties – P 1: Write after obtaining CS lock – P 2: Correct protocol to write to IPCQueue

Experimental Results Upgrade# (Property) Ipc 1 (P 1) Ipc 1 (P 2) Ipc 2 (P 1) Ipc 2 (P 2) Ipc 3 (P 1) Ipc 3 (P 2) Ipc 4 (P 1) #Mem Queries 279 308 358 232 363 258 355 Torig (msec) 2260 1694 3286 805 3624 1649 1102 Tug (msec) 13 14 17 10 17 14 24

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

Conclusion • Automated Substitutability Checking – Containment and Compatibility – Reuses previous verification results – Handles multiple upgrades – Built upon CEGAR framework • Implementation – MAGIC/Com. Fo. RT framework – Promising results on an industrial example

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