© 2011 Carnegie Mellon University B OXES : Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki Software Engineering Institute Carnegie Mellon University.

Slides:



Advertisements
Similar presentations
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Advertisements

Carnegie Mellon University Software Engineering Institute CERT® Knowledgebase Copyright © 1997 Carnegie Mellon University VU#14202 UNIX rlogin with stack.
© 2013 Carnegie Mellon University UFO: From Underapproximations to Overapproximations and Back! Arie Gurfinkel (SEI/CMU) with Aws Albarghouthi and Marsha.
© 2006 Carnegie Mellon University Combining Predicate and Numeric Abstraction for Software Model Checking Software Engineering Institute Carnegie Mellon.
An Introduction to the Model Verifier verds Wenhui Zhang September 15 th, 2010.
Abstraction and Modular Reasoning for the Verification of Software Corina Pasareanu NASA Ames Research Center.
1 1 Regression Verification for Multi-Threaded Programs Sagar Chaki, SEI-Pittsburgh Arie Gurfinkel, SEI-Pittsburgh Ofer Strichman, Technion-Haifa Originally.
Inferring Disjunctive Postconditions Corneliu Popeea and Wei-Ngan Chin School of Computing National University of Singapore - ASIAN
SOFTWARE TESTING. INTRODUCTION  Software Testing is the process of executing a program or system with the intent of finding errors.  It involves any.
SEP1 - 1 Introduction to Software Engineering Processes SWENET SEP1 Module Developed with support from the National Science Foundation.
© 2011 Carnegie Mellon University System of Systems V&V John B. Goodenough October 19, 2011.
© 2010 Carnegie Mellon University B OXES : A Symbolic Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki Software Engineering Institute Carnegie Mellon.
© 2013 Carnegie Mellon University Vinta: Verification with INTerpolation and Abstract interpretation Arie Gurfinkel (SEI/CMU) with Aws Albarghouthi and.
© 2013 Carnegie Mellon University Academy for Software Engineering Education and Training, 2013 Session Architect: Tony Cowling Session Chair: Nancy Mead.
© 2010 Carnegie Mellon University ® CMMI is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University. V&V Principles Verification.
© 2012 Carnegie Mellon University UFO: Verification with Interpolants and Abstract Interpretation Arie Gurfinkel and Sagar Chaki Software Engineering Institute.
© 2010 Carnegie Mellon University Acquisition Implications of SOA Adoption Software Engineering Institute Carnegie Mellon University Pittsburgh, PA
Chapter 8 Representing Information Digitally.
© 2012 Carnegie Mellon University From Underapproximations to Overapproximations and Back! Arie Gurfinkel Software Engineering Institute Carnegie Mellon.
© 2015 Carnegie Mellon University Property Directed Polyhedral Abstraction Nikolaj Bjørner and Arie Gurfinkel VMCAI 2015.
ISBN Chapter 3 Describing Syntax and Semantics.
© 2013 Carnegie Mellon University Static Analysis of Real-Time Embedded Systems with REK Arie Gurfinkel 1 joint work with Sagar Chaki 1, Ofer Strichman.
© 2011 Carnegie Mellon University Binary Decision Diagrams Part Bug Catching: Automated Program Verification and Testing Sagar Chaki September.
© 2011 Carnegie Mellon University Binary Decision Diagrams Part Bug Catching: Automated Program Verification and Testing Sagar Chaki September.
Software Engineering: Where are we? And where do we go from here? V Software Engineering Lecture 23 Clark Barrett New York University 4/17/2006.
© 2011 Carnegie Mellon University Should-Cost: A Use for Parametric Estimates Additional uses for estimation tools Presenters:Bob Ferguson (SEMA) Date:November.
Sanjit A. Seshia and Randal E. Bryant Computer Science Department
© 2011 Carnegie Mellon University QUELCE: Quantifying Uncertainty in Early Lifecycle Cost Estimation Presenters:Dave Zubrow PhD Bob Ferguson (SEMA) Date:November.
Semantics with Applications Mooly Sagiv Schrirber html:// Textbooks:Winskel The.
Describing Syntax and Semantics
1 Formal Engineering of Reliable Software LASER 2004 school Tutorial, Lecture1 Natasha Sharygina Carnegie Mellon University.
Software Issues Derived from Dr. Fawcett’s Slides Phil Pratt-Szeliga Fall 2009.
Formal verification Marco A. Peña Universitat Politècnica de Catalunya.
Scalable and Flexible Static Analysis of Flight-Critical Software Guillaume P. Brat Arnaud J. Venet Carnegie.
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
© 2013 Carnegie Mellon University Vinta: Verification with INTerpolation and Abstract iterpretation Arie Gurfinkel Software Engineering Institute Carnegie.
Ipek Ozkaya, COCOMO Forum © 2012 Carnegie Mellon University Affordability and the Value of Architecting Ipek Ozkaya Research, Technology.
What is Software Architecture?
LÊ QU Ố C HUY ID: QLU OUTLINE  What is data mining ?  Major issues in data mining 2.
© 2010 Carnegie Mellon University Team Software Process.
Chapter 6 System Engineering - Computer-based system - System engineering process - “Business process” engineering - Product engineering (Source: Pressman,
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
Conditions and Terms of Use
© 2013 Carnegie Mellon University Vinta: Verification with INTerpolation and Abstract iterpretation Arie Gurfinkel (SEI/CMU) with Aws Albarghouthi and.
Building Tools by Model Transformations in Eclipse Oskars Vilitis, Audris Kalnins, Edgars Celms, Elina Kalnina, Agris Sostaks, Janis Barzdins Institute.
Ævol : A Tool for Planning Architecture Evolution David Garlan & Bradley Schmerl Carnegie Mellon University.
Software Engineering Principles Principles form the basis of methods, techniques, methodologies and tools Principles form the basis of methods, techniques,
ISBN Chapter 3 Describing Semantics -Attribute Grammars -Dynamic Semantics.
Introduction to Mathematical techniques Formal Methods Limits of Formal Methods.
© 2008 Carnegie Mellon University Combining Predicate and Numeric Abstraction for Software Model Checking Software Engineering Institute Carnegie Mellon.
Systems Analysis and Design in a Changing World, Fourth Edition
FDT Foil no 1 On Methodology from Domain to System Descriptions by Rolv Bræk NTNU Workshop on Philosophy and Applicablitiy of Formal Languages Geneve 15.
Page 1 5/2/2007  Kestrel Technology LLC A Tutorial on Abstract Interpretation as the Theoretical Foundation of CodeHawk  Arnaud Venet Kestrel Technology.
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
Author Software Engineering Institute
Ukrprog Formal requirement language and its applications A.Letichevsky Glushkov Institute of Cybernetics.
SOFTWARE TESTING. Introduction Software Testing is the process of executing a program or system with the intent of finding errors. It involves any activity.
Formal Methods in Software Engineering1 Today’s Agenda  Mailing list  Syllabus  Introduction.
Introduction to Software Analysis CS Why Take This Course? Learn methods to improve software quality – reliability, security, performance, etc.
T imed Languages for Embedded Software Ethan Jackson Advisor: Dr. Janos Szitpanovits Institute for Software Integrated Systems Vanderbilt University.
SOFTWARE TESTING LECTURE 9. OBSERVATIONS ABOUT TESTING “ Testing is the process of executing a program with the intention of finding errors. ” – Myers.
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
Secure Software Workforce Development Panel Session
Software Testing.
Michael Spiegel, Esq Timothy Shimeall, Ph.D.
Metrics-Focused Analysis of Network Flow Data
Model-Driven Analysis Frameworks for Embedded Systems
Introduction to Software Testing
QUELCE: Quantifying Uncertainty in Early Lifecycle Cost Estimation
Verifying Periodic Programs with Priority Inheritance Locks
Presentation transcript:

© 2011 Carnegie Mellon University B OXES : Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki Software Engineering Institute Carnegie Mellon University January 28, 2011

2 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University NO WARRANTY THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN “AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. Use of any trademarks in this presentation is not intended in any way to infringe on the rights of the trademark holder. This Presentation may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other use. Requests for permission should be directed to the Software Engineering Institute at This work was created in the performance of Federal Government Contract Number FA C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The Government of the United States has a royalty-free government-purpose license to use, duplicate, or disclose the work, in whole or in part and in any manner, and to have or permit others to do so, for government purposes pursuant to the copyright license under the clause at

3 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Software Engineering Institute (SEI) Department of Defense R&D Laboratory (FFRDC) Created in 1984 Under contract to Carnegie Mellon University Offices in Pittsburgh, PA; Washington, DC; and Frankfurt, Germany SEI Mission: advance software engineering and related disciplines to ensure the development and operation of systems with predictable and improved cost, schedule, and quality.

4 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University SEI Technical Programs Networked Systems Survivability (CERT) Secure Software and Systems Cyberthreat and Vulnerability Analysis Enterprise Workforce Development Forensics Software Engineering Process Management (SEPM) Capability Maturity Model Integration (CMMI) Team Software Process (TSP) Software Engineering Measurement and Analysis (SEMA) Acquisition Support (ASP) Research, Technology, and System Solutions (RTSS) Architecture-Centric Engineering Product Line Practice System of Systems Practice System of Systems Software Assurance Ultra-Large-Scale (ULS) System Perspective Independent Research and Development (IR&D)

5 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Research, Technology, and System Solutions (RTSS) Program Mission Discover the mutual influences of structure and behavior for software-reliant systems at all scales to assure key quality attributes for the achievement of business and mission goals. Vision Assured and flexible system capabilities at all scales

6 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Problems Faced by the DoD Ultra-large-scale systems webs of software- reliant systems, people, economies, and cultures Embedded systems software embedded in hardware devices Stand-alone systems software applications Software product lines families of similar systems Systems of systems federations of independent systems DoD’s ability to rapidly develop and field software-reliant capability across a variety of systems is deficient. Part of the reason rests with DoD’s acquisition process; part of the reason is technical. Software systems science and engineering are inadequate to determine how to structure and adapt systems at all scales manage interactions among these types of systems assure software-reliant capabilities that are sufficiently reliable, secure, responsive, and adaptable to change Predict and control behavior Assure and bound behavior Coupling to organizational structure and practices increases

7 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University RTSS: Research Mapping Ultra-large-scale systems Embedded systems Stand-alone systems Software product lines Systems of systems Product Line Practice focus Architecture-Centric Engineering addresses all scales of systems Quality attribute foundations and analysis Architecture-centric practices Architecture principles for ULS systems SoS Practice focus SoS Software Assurance focus Engineering and technology for SoS Integrated practices for SoS Failure patterns and mitigations in SoS Theories, Principles, and Methods Barriers/incentives to assurance technology adoption

8 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Outline Software Engineering Institute (SEI) Introduction Basic Abstract Interpretation Boxes Abstract Domain Conclusion

9 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Software is Everywhere

10 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Software is Full of Bugs! “Software easily rates as the most poorly constructed, unreliable, and least maintainable technological artifacts invented by man” Paul Strassman, former CIO of Xerox “Software easily rates as the most poorly constructed, unreliable, and least maintainable technological artifacts invented by man” Paul Strassman, former CIO of Xerox

11 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Software Bugs are Expensive! Intel Pentium FDIV Bug Estimated cost: $500 Million Y2K bug Estimated cost: >$500 Billion Northeast Blackout of 2003 “a programming error identified as the cause of alarm failure” Estimated cost: $6-$10 Billion “The cost of software bugs to the U.S. economy is estimated at $60 B/year” NIST, 2002 “The cost of software bugs to the U.S. economy is estimated at $60 B/year” NIST, 2002

12 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Some Examples of Software Disasters Between 1985 and 1987, Therac-25 gave patients massive overdoses of radiation, approximately 100 times the intended dose. Three patients died as a direct consequence. On February 25, 1991, during the Gulf War, an American Patriot Missile battery in Dharan, Saudi Arabia, failed to track and intercept an incoming Iraqi Scud missile. The Scud struck an American Army barracks, killing 28 soldiers and injuring around 100 other people. On June 4, 1996 an unmanned Ariane 5 rocket launched by the European Space Agency forty seconds after lift-off. The rocket was on its first voyage, after a decade of development costing $7 billion. The destroyed rocket and its cargo were valued at $500 million. Details at

13 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Recent Examples In July 2010, The Food and Drug Administration ordered Baxter International to recall all of its Colleague infusion pumps in use and provide a refund or no-cost replacement to United States customers. It has been working with Baxter since 1999 to correct numerous device flaws. Some of the issues were caused by simple buffer overflow. In December 2010, the Skype network went down for 3 days. The source of the outage was traced to a software bug in Skype version 5. In January 2011, two German researchers have shown that most “feature” mobile phones can be “killed” by sending a simple SMS message (SMS of Death). The attack exploits many bugs in the implementation of SMS protocol in the phones. It can potentially bring down all mobile communication…

14 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Software Engineering is very complex Complicated algorithms Many interconnected components Legacy systems Huge programming APIs … Software Engineers need better tools to deal with this complexity! Why so many bugs?

15 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University What Software Engineers Need Are … Tools that give better confidence than testing while remaining easy to use And at the same time, are … fully automatic … (reasonably) easy to use … provide (measurable) guarantees … come with guidelines and methodologies to apply effectively … apply to real software systems

16 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Automated Software Analysis Program Automated Analysis Automated Analysis Correct Incorrect Software Model Checking with Predicate Abstraction e.g., Microsoft’s SDV Software Model Checking with Predicate Abstraction e.g., Microsoft’s SDV Abstract Interpretation with Numeric Abstraction e.g., ASTREE, Polyspace Abstract Interpretation with Numeric Abstraction e.g., ASTREE, Polyspace

17 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Numeric Abstract Interpretation Analysis is restricted to a fixed Abstract Domain Abstract Domain ≡ “a (possibly infinite) set of predicates from a fixed theory” + efficient (abstract) operations Abstract DomainAbstract Elements Sign0 Box (or Interval) c 1  x  c 2 Octagon ± x ± y  c Polyhedraa 1 x 1 + a 2 x 2 + a 3 x 3 + a 4  0 Common Numeric Abstract Domains Legend x,yprogram variables c,c i,a i numeric constants

18 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Abstract Interpretation w/ Box Domain (1) x := 0 while (x < 1000) { x := x + 1; } assert (x == 1000); Program x = 0 x = 1 0<= x <=1 1<= x <=2 0<= x <=2 1<= x <=3 0<= x <=1000 0<= x < <= x <= 1000 x = 1000 widening Steps:

19 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Abstract Domain as an Interface interface AbstractDomain(V) : V – set of variables A – abstract elements E – expressions S – statements α : E → A γ : A → E meet : A  A → A isTop : A → bool isBot : A → bool join : A  A → A leq : A  A → bool αPost : S → (A → A) widen : A  A → A All operations are over-approximations, e.g., γ (a) || γ (b)  γ ( join (a, b) ) γ (a) && γ (b)  γ (meet (a,b) ) abstract concretize abstract transformer order

20 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Example: Box Abstract Domain (1, 10) meet (2, 12) = (2,10) (1, 3) join (7, 12) = (1,12) 1  x  10 (1, 10) α α γ γ 1  x  10 (a, b) meet (c, d) = (max(a,c), min(b,d)) (a, b) join (c, d) = (min(a,c),max(b,d)) α Post (x := x + 1) ((a, b)) = (a+1, b+1)(1, 10) + 1 = (2, 11) Definition of Operations Examples over-approximation abstract concretize

21 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Abstract Interpretation w/ Box Domain (2) assume (i=1 || i=2) if (i = 1) x1 := i; else if (i = 2) x2 := -4; if (i = 1) assert (x1 > 0); else if (i = 2) assert (x2 < 0); 1 <= i <= 2 i=1 i=1 && x1=1 i=2 i=2 && x2=-4 1 <= i <= 2 i=1 i=2 Loss of precision due to join False Positive Program Steps:

22 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Disjunctive Refinement of an Abstract Domain Bounded disjunctions extend base domain with disjunctions of size at most k all operations are done by lifting corresponding base domain operations easy to implement by modifying program control flow graph Finite Powerset Domain [Bagnara et al.] extend base domain with all finite disjunctions most operations are done by lifting corresponding base domain opertions finding a good widening is complex (and often tricky) Predicate Abstraction extend finite base domain with all disjunctions domain elements are represented by BDDs no widening required OUR WORK OUR WORK

23 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Outline Software Engineering Institute (SEI) Introduction Basic Abstract Interpretation Boxes Abstract Domain Conclusion

24 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Boxes: Semantic View Boxes are “finite union of box values” (alternatively) Boxes are “Boolean formulas over interval constraints” Boxes are “finite union of box values” (alternatively) Boxes are “Boolean formulas over interval constraints”

25 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Linear Decision Diagrams in a Nutshell * x + 2y < 10 z < Linear Decision Diagram decision node decision node true terminal true terminal false edge false edge (x + 2y < 10) OR (x + 2y  10 AND z < 10) Linear Arithmetic Formula Operations Propositional (AND, OR, NOT) Existential Quantification false terminal false terminal true edge true edge Compact Representation Sharing sub-expressions Local numeric reductions Dynamic node reordering * joint work w/ Ofer Strichman

26 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Boxes: Representation Represented by (Interval) Linear Decision Diagrams (LDD) BDDs + non-terminal nodes are labeled by interval constraints + extra rules retain complexity of BDD operations canonical representation for Boxes Abstract Domain available at LDD Semantics (x ≤ 1 || x ≥ 2) && 1 ≤ y ≤ 3 (x ≤ 1 || x ≥ 2) && 1 ≤ y ≤ 3 Syntax

27 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Abstract Domain Operations Additional operations set difference f ∖ g implemented by f ⋀¬g BoxHull (f) – smallest Box containing f BoxJoin (f, g) – smallest Box containing the union of Box f and Box g OperationComplexity f ⋀ g O(|f||g|) ITE(h, f, g)O(|h||f||g|) ¬ f O(1) OperationComplexity f ⋁ g O(|f||g|) f ⇒ g O(|f||g|) ∃U. f O(|f| 2 |U| ) Basic domain operations are implemented by LDD operations meet join order (semantic) order (semantic) All operations are polynomial in the size of the representation projection

28 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Transfer Functions (  Post) x := x + 1 expensive boxes box polynomial

29 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Widening: The Problem widen ( x  1  2  y  3)  (2  x  3  1  y  2) ( x  1.5  1.5  y  3)  (2  x  3  1  y  2)

30 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Step Function A function on the reals ℝ is a step function if it can be written as a finite linear combination of semi-open intervals f(x) = α 1 f 1 (x) +  + α n f n (x) where f i 2 ℝ and α i (x )=1 if x 2 [ a i, b i ) and 0 otherwise, for i=1,…,n Weisstein, Eric W.Weisstein, Eric W. "Step Function." From MathWorld--A Wolfram Web Resource.MathWorld

31 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Step Functions as an Abstract Domain 1 23 x

32 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Step Functions as an Abstract Domain STEP(D) an abstract domain of step functions over an abstract domain D elements are step functions ℝ→ D order is pointwise: f ⊑ g iff 8 x. f(x) ⊑ D g(x) join is pointwise: f ⊔ g is ¸ x. f(x) ⊔ D g(x) meet is pointwise: f ⊓ g is ¸ x. f(x) ⊓ D g (x) widen is pointwise: f ∇ g is ¸ x. f(x) ∇ D g(x) ???? [0,3] [0,0][1,10] x box

33 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Pointwise Extension of Widen Diverges [0,3] [0,0][1,9] [0,5] [0,0][1,10][1,9] [0,∞] [0,0][1,∞][1,9] [0,∞] [0,0][1,∞][1,9] [1,10] [0,∞] [0,0][1,∞][1,9] [0,∞] [0,0][1,∞][1,9] [1,10] WDN

34 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Widening for Step Functions [0,3] [0,0][1,9] [0,5] [0,0][1,10][1,9] [0,∞] [0,0][1,∞][1,9] [0,∞] [0,0][1,∞] [0,∞] [0,0][1,∞] Step 1 Step 2 Step 3

35 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Back to Boxes Boxes are Step functions! 1-dim Boxes are STEP({ ⊥,⊤ }) ℝ→ { ⊥,⊤ } 2-dim Boxes are STEP (STEP ({ ⊥,⊤ }) ℝ→ℝ→ { ⊥,⊤ } n-dim Boxes are STEP n ({ ⊥,⊤ }) ℝ n → { ⊥,⊤ } Widen for { ⊥,⊤ } is trivial Widen for n-dim Boxes is defined recursively on dimensions We give a polynomial time algorithm that implements this widen operator directly on LDDs. (See paper for details)

36 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Widen: An Example widen x y x y x y

37 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Widening: Example Step 1 Step 2 Step 3 [2,3][1,2] [1.5,3][1,2] [-∞,3][1,2][1.5,3] [-∞,3][1,2][1.5,3] [-∞,3][1,2][1.5,3]

38 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Widen: An Example widen x y x y x y

39 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Boxes versus Finite Powersets BoxesFinite Powerset Base domainBoxAny RepresentationDecision DiagramSet / DNF Domain ordersemanticsyntactic Complexity polynomial in representation Singleton WidenBoxbase domain WidenStep FunctionMultiple Choices Our work Bagnara et al. Parma Polyhedra Library (PPL) Bagnara et al. Parma Polyhedra Library (PPL)

40 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Experiments: Invariant Computation Abstract Domains LDD Boxes – Our Boxes domain using LDDs PPL Boxes – Pointset_Powerset of PPL Analyzer custom analyzer on top of LLVM compiler infrustructure computes loop invariants for all loops over all SSA variables in a function Benchmark from open source software: mplayer, CUDD, make, … Stats: 5,727 functions 9 – 9,052 variables (avg. 238, std. 492) 0 – 241 loops (avg. 7, std. 12)

41 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Results: Time Total time = 118 minTotal time = 201 min 5727 functions, each run with a time limit of 60s

42 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Results: Precision

43 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Conclusion Boxes: A new disjunctive abstract domain of sets of boxes efficient representation based on Linear Decision Diagrams semantic order relation efficient operations and widening more precise and efficient than finite powersets of box A new widening scheme lifting widening from a base domain to the domain of step functions Future Work applications extending the technique to richer base domains, i.e., octagons, TVPI – representation and base operations are easy (already exist in LDD) – widening?

44 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University LDD Based Analysis Infrastructure Linear Decision Diagram (LDD) Engine CUDDLinear Arithmetic Theories BOXES Invariant Generator Invariant Generator Software Model Checker Concurrency + Real Time Scheduling Concurrency + Real Time Scheduling SAS’10 Foundations Current Work FMCAD’09

45 Boxes: Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki © 2011 Carnegie Mellon University Contact Information Presenter Arie Gurfinkel RTSS Telephone: U.S. mail: Software Engineering Institute Customer Relations 4500 Fifth Avenue Pittsburgh, PA USA Web: Customer Relations Telephone: SEI Phone: SEI Fax:

© 2011 Carnegie Mellon University THE END