Exploiting Synchrony and Symmetry in Relational Verification
 9 Citations
 7.2k Downloads
Abstract
Relational safety specifications describe multiple runs of the same program or relate the behaviors of multiple programs. Approaches to automatic relational verification often compose the programs and analyze the result for safety, but a naively composed program can lead to difficult verification problems. We propose to exploit relational specifications for simplifying the generated verification subtasks. First, we maximize opportunities for synchronizing code fragments. Second, we compute symmetries in the specifications to reveal and avoid redundant subtasks. We have implemented these enhancements in a prototype for verifying ksafety properties on Java programs. Our evaluation confirms that our approach leads to a consistent performance speedup on a range of benchmarks.
Keywords
Related Verification Related Veriﬁcation Problems (RVPs) Symmetrybreaking Predicates (SBPs) Hoare Triples Lockstep Execution1 Introduction
The verification of relational program specifications is of wide interest, having many applications. Relational specifications can describe multiple runs of the same program or relate the behaviors of multiple programs. An example of the former is the verification of security properties such as noninterference, where different executions of the same program are compared to check whether there is a leak of sensitive information. The latter is useful for checking equivalence or refinement relationships between programs after applying some transformations or during iterative development of different software versions.
There is a rich history of work on the relational verification of programs. Representative efforts include those that target general analysis using relational program logics and frameworks [4, 5, 8, 27, 31] or specific applications such as security verification [1, 7, 9], compiler validation [16, 32], and differential program analysis [17, 19, 21, 22, 23]. These efforts are supported by tools that range from automatic verifiers to interactive theoremprovers. In particular, many automatic verifiers are based on constructing a composition over the programs under consideration, where the relational property over multiple runs (of the same or different programs) is translated into a functional property over a single run of a composed program. This has the benefit that standard techniques and tools for program verification can then be applied.
However, it is also well known that a naively composed program can lead to difficult verification problems for automatic verifiers. For example, a sequential composition of two loops would require effective techniques for generating loop invariants. In contrast, a parallel composition would provide potential for aligning the loop bodies, where relational invariants may be easier to establish than a functional loop invariant. Examples of techniques that exploit opportunities for such alignment include use of typebased analysis with selfcomposition [29], allowing flexibility in composition to be a mix of sequential and parallel [6], exploiting structurally equivalent programs for compiler validation [32], lockstep execution of loops in reasoning using Cartesian Hoare Logic [27], and merging Horn clause rules for relational verification [13, 24].
In this paper, we present a compositional framework that leverages relational specifications to further simplify the generated verification tasks on the composed program. Our framework is motivated by two main strategies. The first strategy, similar to the efforts mentioned above, is to exploit opportunities for synchrony, i.e., aligning code fragments across which relational invariants are easy to derive, perhaps due to functional similarity or due to similar code structure, etc. Specifically, we choose to synchronize the programs at conditional blocks as well as at loops. Similar to closely related efforts [6, 27], we would like to execute loops in lockstep so that relational invariants can be derived over corresponding iterations over the loop bodies. Specifically, we propose a novel technique that analyzes the relational specifications to infer, under reasonable assumptions, maximal sets of loops that can be executed in lockstep. Synchronizing at conditional blocks in addition to loops enables simplification due to relational specifications and conditional guards that might result in infeasible or redundant subtasks. Pruning of such infeasible subtasks has been performed and noted as important in existing work [27], and synchronizing at conditional blocks allows us to prune eagerly. More importantly, aligning different programs at conditional statements sets up our next strategy.
Our second strategy is the exploitation of symmetry in relational specifications. Due to control flow divergences or nonlockstep executions of loops, even different copies of the same program may proceed along different code fragments. However, some of the resulting verification subtasks may be indistinguishable from each other due to underlying symmetries among related fragments. We analyze the relational specifications, expressed as formulas in firstorder theories (e.g., linear integer arithmetic) with multiindex variables, to discover symmetries and exploit them to prune away redundant subtasks. Prior works on use of symmetry in model checking [11, 14, 15, 20] are typically based on symmetric states satisfying the same set of indexed atomic propositions, and do not consider symmetries among different indices in specifications. To the best of our knowledge, ours is the first work to extract such symmetries in relational specifications, and to use them for pruning redundant subtasks during relational verification. For extracting these symmetries, we have lifted core ideas from symmetrydiscovery and symmetrybreaking in SAT formulas [12] to richer formulas in firstorder theories.
The strategies we propose for exploiting synchrony and symmetry via relational specifications are fairly general in that they can be employed in various verification methods. We provide a generic logicbased description of these strategies at a high level (Sect. 4), and also describe a specific instantiation in a verification algorithm based on forward analysis that computes strongestpostconditions (Sect. 5). We have implemented our approach in a prototype tool called Synonym built on top of the Descartes tool [27]. Our experimental evaluation (Sect. 6) shows the effectiveness of our approach in improving the performance of verification in many examples (and a marginal overhead in smaller examples). In particular, exploiting symmetry is crucial in enabling verification to complete for some properties, without which Descartes exceeds a timeout on all benchmark examples.
2 Motivating Example
A relational verification problem (RVP) is a tuple consisting of programs \(\{P_j\}\), a relational precondition \( pre \), and a relational postcondition \( post \). In the example RVPs below, we consider the three conditionals, which in turn lead to eight possible controlflow decisions (Fig. 1, right) in a composed program. Each RVP reduces to subproblems for proving that \( post \) can be derived from \( pre \) for each of these controlflow decisions. In the rest of the section, we demonstrate the underlying ideas behind our approach to solve these subproblems efficiently.
3 Background and Notation
Given a loopfree program over input variables Open image in new window and output variables Open image in new window (such that Open image in new window and Open image in new window are disjoint), let Open image in new window denote its symbolic encoding.
Proposition 1
Proposition 2
Note that the method of naive composition requires handling of multiple invariants, which is known to be difficult. Furthermore, it might lose some important relational information specified in \( pre (\vec {x}_1, \vec {x}_2)\). One way to avoid this is to exploit the fact that loops could be executed in lockstep.
Proposition 3
In this paper, we do not focus on a specific method for deriving these invariants – a plethora of suitable methods have been proposed in the literature, and any of these could be used.
4 Leveraging Relational Specifications
In this section, we describe the main components of our compositional framework where we leverage relational specifications to simplify the verification subtasks. We first describe our novel algorithm for inferring maximal sets of loops that can be executed in lockstep (Sect. 4.1). Next, we describe our technique for handling conditionals (Sect. 4.2). While this is similar to other prior work, the main purpose here is to set the stage for our novel methods for exploiting symmetry (Sect. 4.3).
4.1 Synchronizing Loops
Given a set of loopy programs, we would like to determine which ones can be executed in lockstep. As mentioned earlier, relational invariants over lockstep loops are often easier to derive than loop invariants over a single copy.
Our algorithm CheckLockstep takes as input a set of loopy programs \(\{P_1, \ldots , P_k\}\) and outputs a set of maximal classes of programs that can be executed in lockstep. The algorithm partitions its input set of programs and recursively calls CheckLockstep on the partitions.
Otherwise, CheckLockstep gets a satisfying assignment and partitions the input programs into a set \( Terminated \) and a set \( Unfinished \). The \( Terminated \) set contains all programs \(P_i\) whose guards \( Guard (\vec {u}_i)\) are false in the model for the formula, and the \( Unfinished \) set contains the remaining programs. The CheckLockstep algorithm is then called recursively on both \( Terminated \) and \( Unfinished \), with its final result being the union of the two sets returned by these recursive calls.
The following theorem assumes that any relational invariant \(\varvec{I}(\vec {u}_1, \ldots , \vec {u}_k)\), generated externally and used by the algorithm, is stronger than any relational invariant \(\varvec{I}(\vec {u}_1, \ldots , \vec {u}_{i1}, \vec {u}_{i + 1}, \ldots , \vec {u}_k)\) that could be synthesized over the same set of k loops with the \(i^{ th }\) loop removed.
Theorem 1
For any call to CheckLockstep, it always partitions its set of input programs such that for all \(P_i \in Terminated \) and \(P_j \in Unfinished \), \(P_i\) and \(P_j\) cannot be executed in lockstep.
Proof
4.2 Synchronizing Conditionals
Let two programs have forms \(\texttt {if~Q}_{i}~\texttt {then~R}_{i}~\texttt {else~S}_{i}\), where \(i \in \{1,2\}\) and \(\texttt {R}_{i}\) and \(\texttt {S}_{i}\) are arbitrary blocks of code and could possibly have loops. Let them be a part of some RVP, which reduces to applying Propositions 1, 2, or 3, depending on the content of each block of code, to four pairs of programs. As we have seen in previous sections, each of the four verification tasks could be expensive. In order to reduce the number of verification tasks where possible, we use the relational preconditions to filter out pairs of programs for which verification conclusions can be derived trivially.
4.3 Discovering and Exploiting Symmetries
4.3.1 Identifying Symmetries in Formulas
Formally, symmetries in formulas are defined as permutations. Note that any permutation \(\pi \) of set \(\{1,\ldots ,k\}\) can be lifted to be a permutation of set \(\{\vec {x}_1,\ldots ,\vec {x}_k\}\).
Definition 1
(Symmetry). Let \(\vec {x}_1,\ldots ,\vec {x}_k\) be vectors of the same size over disjoint sets of variables. A symmetry \(\pi \) of a formula \(F(\vec {x}_1,\ldots ,\vec {x}_k)\) is a permutation of set \({\{\vec {x}_i \mid 1 \le i \le k\}}\) such that \(F(\vec {x}_1,\ldots ,\vec {x}_k) \iff F(\pi (\vec {x}_1),\ldots ,\pi (\vec {x}_k))\).
The task of finding symmetries within a set of formulas can be performed syntactically by first canonicalizing the formulas, converting the formulas into a graph representation of their syntax, and then using a graph automorphism algorithm to find the symmetries of the graph. We demonstrate how this can be done for a formula \(\varphi \) over Linear Integer Arithmetic with the following example.
Let \(\varphi = (x_1 \le x_2 \wedge x_3 \le x_4) \wedge ( x_1< z_2 \vee x_3 < z_4)\). Note that this formula is symmetric under a permutation of the subscripts that simultaneously swaps 1 with 3 and 2 with 4. Let \(\{(x_1,z_1), (x_2,z_2), (x_3,z_3), (x_4,z_4)\}\) be the vectors of variables. We identify a vector by its subscript (e.g., we identify \((x_1,z_1)\) by 1).
4.3.2 Exploiting Symmetries
We now define the notion of symmetric RVPs and application of symmetrybreaking to generate a single representative per equivalence class of RVPs.
Definition 2
 1.
\(\pi \) is a symmetry of formula \( pre (\vec {x}_1, \ldots , \vec {x}_k) \wedge post (\vec {y}_1, \ldots , \vec {y}_k)\)
 2.
for every \(P_i \in Ps\) and \(P_j \in Ps'\), if \(\pi (i) = j\), then \(P_i\) and \(P_j\) have the same number of inputs and outputs and have logically equivalent encodings for the same set of input variables \(\vec {x}_i\) and output variables \(\vec {y}_i\)
As we have seen in Sect. 4.3.1, identification of symmetries could be made purely on the syntactic level of the relational preconditions and postconditions. For each detected symmetry, it remains to check equivalence between the corresponding programs’ encodings, which can be formulated as an SMT problem.
To exploit symmetries, we propose a simple but intuitive approach. First, we identify the set of symmetries using \( pre \wedge post \). Then, we solve the AllSAT query from Eq. 2 and get a reduced set \( R \) of RVPs (i.e., one without all trivial problems). For each \( RVP _i \in R \), we perform the relational verification only if no symmetric \( RVP _j \in R \) has already been verified. Thus, the most expensive part of the routine, checking equivalence of RVPs, is performed on demand and only on a subset of all possible pairs \(\langle RVP _i, RVP _j \rangle \).
Alternatively, in some cases (e.g., for parallelizing the algorithm) it might help to identify all symmetric RVPs prior to solving the AllSAT query from Eq. 2. From this set, we can generate symmetrybreaking predicates (SBPs) [12] and conjoin them to Eq. 2. Constrained with SBPs, this query will have fewer models, and will contain a single representative per equivalence class of RVPs. We describe how to construct SBPs in more detail in the next section.
4.3.3 Generating SymmetryBreaking Predicates (SBPs)
SBPs have previously been applied in pruning the search space explored by SAT solvers. Traditionally, techniques construct SBPs based on symmetries in truth assignments to the literals in the formula, but SBPconstruction can be adapted to be based on symmetries in truth assignments to conditionals, allowing us to break symmetries in our setting.
After constructing the SBP, we conjoin it to the AllSAT query in Eq. 2. Our solver now generates sets of programs that, when combined with the relational precondition and postcondition, form a set of irredundant RVPs.
Example. Let us consider how SBPs can be applied to \( RVP _2\) from Sect. 2 to avoid generating two of the eight RVPs we would otherwise generate.
5 Instantiation of Strategies in Forward Analysis
Given an RVP in the form of a Hoare triple \(\{ Pre \}~P_1  \cdots  P_k~\{ Post \}\), where  denotes parallel composition, the toplevel Verify procedure takes as input the relational specification \( pre = Pre \) and \( post = Post \), the set of input programs \( Current = \{P_1,\ldots ,P_k\}\), and empty sets \( Loops \) and \( Ifs \). It uses a strongestpostcondition computation to compute the next Hoare triple at each step until it can conclude the validity of the original Hoare triple.
Synchronization. Throughout verification, the algorithm maintains three disjoint sets of programs: one for programs that are currently being processed (\( Current \)), one for programs that have been processed up until a loop (\( Loops \)), and one for programs that have been processed up until a conditional statement (\( Ifs \)). The algorithm processes statements in each program independently, with ProcessStatement choosing an arbitrary interleaving of statements from the programs in \( Current \). When the algorithm encounters the end of a program in its call to ProcessStatement, it removes this program from the \( Current \) set. At this point, the algorithm returns safe if the current Hoare triple is proven valid. When a program has reached a point of controlflow divergence and is processed by ProcessStatement, it is removed from \( Current \) and added to the appropriate set (\( Loops \) or \( Ifs \)).
Handling Loops. Once all programs are in the \( Loops \) or \( Ifs \) sets (i.e. \( Current = \varnothing \)), the algorithm handles the programs in the \( Loops \) set if it is nonempty. HandleLoops behaves like CheckLockstep but computes postconditions where possible; when a set of loops are able to be executed in lockstep, HandleLoops computes their postconditions before placing the programs into the \( Terminated \) set. After all loops have been placed in the \( Terminated \) set and a new precondition \( pre '\) has been computed, rather than returning \( Terminated \), HandleLoops invokes \(\textsc {Verify}( pre ', Terminated , Ifs ,\varnothing , post )\).
Handling Conditionals. When \( Current = Loops = \varnothing \), Verify handles conditional statements. HandleIfs exploits symmetries by using the AllSAT query with LexLeader SBPs as described in Sect. 4 and calls Verify on each generated verification problem.
6 Implementation and Evaluation
To evaluate the effectiveness of increased lockstep execution of loops and symmetrybreaking, we implemented our algorithm from Sect. 5 on top of the Descartes tool for verifying ksafety properties, i.e., RVPs over k identical Java programs. We implemented two variants: Syn uses only synchrony (i.e., no symmetry is used), while Synonym uses both. All implementations (including Descartes) use the same guessandcheck invariant generator (the same originally used by Descartes, but modified to generate more candidate invariants). In Synonym, we compute symmetries in preconditions and postconditions only when all program copies are the same. For our examples, it sufficed to compute symmetries simply by checking if each possible permutation leads to equivalent formulas^{1}. We compare the performance of our prototype implementations to Descartes^{2}. We use two metrics for comparison: the time taken and the number of Hoare triples processed by the verification procedure. All experiments were conducted on a MacBook Pro, with a 2.7 GHz Intel Core i5 processor and 8 GB RAM.
6.1 Stackoverflow Benchmarks

P1: \(\forall x,y. sgn ( compare (x,y)) =  sgn ( compare (y,x))\)

P2: \(\forall x,y,z. ( compare (x,y)> 0 \wedge compare (y,z)> 0) \implies compare (x,z) > 0\)

P3: \(\forall x,y,z. ( compare (x,y) = 0) \!\implies \! ( sgn ( compare (x,z)) = sgn ( compare (y,z)))\)
Stackoverflow Benchmarks. Total times (in seconds) and Hoare triple counts (HTC) for Stackoverflow benchmarks, where for each property, the results for Syn and Synonym are divided into those for examples where they exhibit a factor of improvement over Descartes that is greater or equal to 1 (top) and those for which they do not (bottom). Improv reports the factor of improvement over Descartes, where the number of examples is given in parentheses.
Prop  Descartes  Syn  Synonym  

Time  HTC  Time  Improv  HTC  Improv  Time  Improv  HTC  Improv  
P1  3.11  4422  1.91  1.39 (27)  2255  1.69 (27)  1.82  1.32 (25)  2401  1.82 (32) 
0.57  0.789 (6)  752  0.809 (6)  0.87  0.816 (8)  48  0.979 (1)  
P2  24.6  13434  7.83  2.62 (20)  3285  3.081 (16)  7.31  2.80 (19)  3224  3.140 (16) 
4.98  0.823 (13)  4638  0.714 (17)  5.1  0.816 (14)  4638  0.714 (17)  
P3  18.85  10938  5.22  2.92 (20)  1565  4.36 (16)  5.22  2.91 (19)  1537  4.74 (16) 
6.18  0.584 (13)  6600  0.623 (17)  6.16  0.594 (14)  6600  0.623 (17) 
6.2 Modified Stackoverflow Benchmarks

P13: \(\forall x,y,z. pick (x,y,z) = pick (y,x,z)\)

P14: \(\forall x,y,z. pick (x,y,z) = pick (y,x,z) \wedge pick (x,y,z) = pick (z,y,x)\)
Note that P13 allows swapping the first two input arguments, while P14 allows any permutation of inputs, a useful hyperproperty.
The results from running property P13 are shown in Table 2. We see here that for these larger examples, Hoare triple counts are more reliably correlated with the time taken to perform verification. Syn outperforms Descartes on 14 of the 16 examples, and Synonym outperforms both Descartes and Syn on all 16 examples.
Verifying P13 for modified Stackoverflow examples. Times (in seconds) and Hoare triple counts (HTC).
Example  Descartes  Syn  Synonym  

Time  HTC  Time  HTC  Time  HTC  
ArrayIntpick3falsesimple  1.71  2573  1  1355  0.64  682 
ArrayIntpick3false  1.55  2591  1.06  1439  0.8  724 
ArrayIntpick3truesimple  1.71  2573  1.03  1355  0.65  682 
ArrayIntpick3true  1.55  2591  1.08  1439  0.81  724 
Chromosomepick3falsesimple  0.9  1115  0.9  883  0.53  446 
Chromosomepick3false  2.51  2891  2.94  3019  1.59  1514 
Chromosomepick3truesimple  0.9  1115  0.9  883  0.53  446 
Chromosomepick3true  2.51  2891  2.96  3019  1.59  1514 
PokerHandpick3falsepart1  5.87  5825  0.42  359  0.46  359 
PokerHandpick3falsepart2  9.74  10589  0.85  323  0.86  323 
PokerHandpick3false  16.91  16475  0.73  159  0.79  159 
PokerHandpick3truepart1  5.83  5825  3.98  3503  2.4  1756 
PokerHandpick3truepart2  9.8  10565  7.36  5933  4.53  2971 
PokerHandpick3true  17.25  16475  12.1  9293  7.34  4651 
Solutionpick3false  76.4  99910  25.05  20645  20.42  10327 
Solutionpick3true  64.5  99910  19.66  20645  15.21  10327 
Total  219.64  283914  82.02  74252  59.15  37605 
Improvement  1  1  2.68  3.8237  3.713  7.5499 
Verifying P14 for modified Stackoverflow examples. Times (in seconds) and Hoare triple counts (HTC).  indicates that no sufficient invariant could be inferred.
Example  Descartes  Syn  Synonym  

Time  HTC  Time  HTC  Time  HTC  
ArrayIntpick3falsesimple  TO  TO  4.12  1938  4.66  1734 
ArrayIntpick3false  TO  TO  4.92  2017  6.03  1500 
ArrayIntpick3truesimple  TO  TO  321.15  140593  170.43  58586 
ArrayIntpick3true  TO  TO  366.98  149125  240.25  62141 
Chromosomepick3falsesimple  TO  TO  47.8  14097  1.67  834 
Chromosomepick3false  TO  TO  264.21  93052  4.91  3043 
Chromosomepick3truesimple  TO  TO  299.51  79613  135.56  33179 
Chromosomepick3true  TO  TO  TO  TO  848.22  225044 
PokerHandpick3falsepart1  TO  TO  0.57  391  0.73  391 
PokerHandpick3falsepart2  TO  TO  0.81  228  0.81  228 
PokerHandpick3false             
PokerHandpick3truepart1  TO  TO  2277.03  819553  1272.58  341486 
PokerHandpick3truepart2  TO  TO         
PokerHandpick3true             
Solutionpick3false  TO  TO  TO  TO  TO  TO 
Solutionpick3false  TO  TO  TO  TO  TO  TO 
Summary of Experimental Results. Our experiments indicate that our performance improvements are consistent: on all Descartes benchmarks (in Table 1, which are all small) our techniques either have low overhead or show some improvement despite the overhead; and on modified (bigger) programs they lead to significant improvements. In particular, we report (Table 2) speedups up to 21.4x (on an example where the property doesn’t hold) and 4.2x (on an example where it does). More importantly, we report (Table 3) that Descartes times out on 14 examples, where of these Synonym times out for 2 and cannot infer an invariant for one example.
7 Related Work
The work most closely related to ours is by Sousa and Dillig [27], which proposed Cartesian Hoare Logic (CHL) for proving ksafety properties and the tool Descartes for automated reasoning in CHL. In addition to the core program logic, CHL includes additional proof rules for loops, referred to as Cartesian Loop Logic (CLL). A generalization of CHL, called Quantitative Cartesian Hoare Logic was subsequently used by Chen et al. [10] to detect sidechannel vulnerabilities in cryptographic implementations.
In terms of comparison, neither CHL nor CLL force alignment at conditional statements or take advantage of symmetries. We believe our algorithm for identifying a maximal set of lockstep loops is also novel and can be used in other methods that do not rely on CHL/CLL. On the other hand, CLL proof rules allow not only fully lockstep loops, but also partially lockstep loops. Although we did not consider it here, our maximal locksteploop detection algorithm can be combined with their partial lockstep execution to further improve the efficiency of verification. For example, applying the Fusion 2 rule from CLL to our example while loops generated from \( RVP _1\) (Sect. 2) would result in three subproblems and require reasoning twice about the second copy’s loop finishing later. When combined with maximal locksteploop detection, we could generate just two subproblems: one where the first and third loops terminate first, and another where the second loop terminates first.
Other automatic efforts for relational verification typically use some kind of product programs [6, 13, 17, 21, 22, 24, 28], with a possible reduction to Horn solving [13, 17, 21, 24]. Similarly to our strategy for synchrony, most of them attempt to leverage similarity (structural or functional) in programs to ease verification. However, we have seen less focus on leveraging relational specifications themselves to simplify verification tasks, although this varies according to the verification method used. Some efforts do not reason over product programs at all, relying on techniques based on decomposition [3] or customized theories with theorem proving [4, 30] instead. To the best of our knowledge, none of these efforts exploit symmetry in programs or in relational specifications.
On the other hand, symmetry has been used very successfully in model checking parametric finite state systems [11, 15, 20] and concurrent programs [14]. Our work differs from these efforts in two main respects. First, the parametric systems considered in these efforts have components that interact with each other or share variables. Second, the correctness specifications are also parametric, usually singleindex or doubleindex properties in a propositional (temporal) logic. In contrast, in our RVPs, the individual programs are independent and do not share any common variables. The only interaction between them is via relational specifications. Furthermore, we discover symmetries in these relational specifications over multiindex variables, expressed as formulas in firstorder theories (e.g., linear integer arithmetic). We then exploit these symmetries to prune redundant RVPs during verification.
There are also some similarities between relational verification and verification of concurrent/parallel programs. In the latter, a typical verifier [18] would use visible operations (i.e., synchronization operations or communication on shared state) as synchronizing points in the composed program. In our work, this selection is made based on the structure of the component programs and the ease of utilizing or deriving relational assertions for the code fragments. Furthermore, one does not need to consider different orderings in interleavings of programs in the RVPs. Since these fragments are independent, it suffices to explore any one ordering. Instead, we exploit symmetries in the relational assertions to prune away redundant RVPs.
Finally, specific applications may impose additional synchrony requirements pertaining to visibility. For example, one may want to check for information leaks from private inputs to public outputs not only at the end of a program but at other specified intermediate points, or information leakage models for sidechannel attacks may check for leaks based on given observer models [1]. Such requirements can be viewed as relational specifications at selected synchronizing points in the composed program. Again, we can leverage these relational specifications to simplify the resulting verification subproblems.
8 Conclusions and Future Work
We have proposed novel techniques for improving relational verification, which has several applications including security verification, program equivalence checking, and regression verification. Our two key ideas are maximizing the amount of code that can be synchronized and identifying symmetries in relational specifications to avoid redundant subtasks. Our prototype implementation on top of the Descartes verification tool leads to consistent improvements on a range of benchmarks. In the future, we would be interested in implementing these ideas on top of a Hornbased relational verifier (e.g., [25]) and extending it to work with recursive data structures. We are also interested in developing an algorithm for finding symmetries in formulas that does not rely on an external graph automorphism tool.
Footnotes
Notes
Acknowledgements
We gratefully acknowledge the help from Marcelo Sousa and Işil Dillig on their Descartes tool, which provides the base for our prototype development and experimental comparison. This work was supported in part by NSF Grant 1525936.
References
 1.Almeida, J.B., Barbosa, M., Barthe, G., Dupressoir, F., Emmi, M.: Verifying constanttime implementations. In: USENIX, pp. 53–70. USENIX Association (2016)Google Scholar
 2.Aloul, F.A., Sakallah, K.A., Markov, I.L.: Efficient symmetry breaking for Boolean satisfiability. IEEE Trans. Comput. 55(5), 549–558 (2006)CrossRefGoogle Scholar
 3.Antonopoulos, T., Gazzillo, P., Hicks, M., Koskinen, E., Terauchi, T., Wei, S.: Decomposition instead of selfcomposition for proving the absence of timing channels. In: PLDI, pp. 362–375 (2017)Google Scholar
 4.Asada, K., Sato, R., Kobayashi, N.: Verifying relational properties of functional programs by firstorder refinement. Sci. Comput. Program. 137, 2–62 (2017)CrossRefGoogle Scholar
 5.Banerjee, A., Naumann, D.A., Nikouei, M.: Relational logic with framing and hypotheses. In: IARCS. LIPIcs, vol. 65, pp. 11:1–11:16. Schloss Dagstuhl  LeibnizZentrum fuer Informatik (2016)Google Scholar
 6.Barthe, G., Crespo, J.M., Kunz, C.: Relational verification using product programs. In: Butler, M., Schulte, W. (eds.) FM 2011. LNCS, vol. 6664, pp. 200–214. Springer, Heidelberg (2011). https://doi.org/10.1007/9783642214370_17CrossRefGoogle Scholar
 7.Barthe, G., D’Argenio, P.R., Rezk, T.: Secure information flow by selfcomposition. In: CSFW, pp. 100–114. IEEE (2004)Google Scholar
 8.Benton, N.: Simple relational correctness proofs for static analyses and program transformations. In: POPL, pp. 14–25 (2004)Google Scholar
 9.Beringer, L., Hofmann, M.: Secure information flow and program logics. In: CSF, pp. 233–248. IEEE Computer Society (2007)Google Scholar
 10.Chen, J., Feng, Y., Dillig, I.: Precise detection of sidechannel vulnerabilities using quantitative Cartesian hoare logic. In: Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, CCS 2017, pp. 875–890 (2017)Google Scholar
 11.Clarke, E.M., Filkorn, T., Jha, S.: Exploiting symmetry in temporal logic model checking. In: Courcoubetis, C. (ed.) CAV 1993. LNCS, vol. 697, pp. 450–462. Springer, Heidelberg (1993). https://doi.org/10.1007/3540569227_37CrossRefGoogle Scholar
 12.Crawford, J.M., Ginsberg, M.L., Luks, E.M., Roy, A.: Symmetrybreaking predicates for search problems. In: KR, pp. 148–159 (1996)Google Scholar
 13.De Angelis, E., Fioravanti, F., Pettorossi, A., Proietti, M.: Relational verification through horn clause transformation. In: Rival, X. (ed.) SAS 2016. LNCS, vol. 9837, pp. 147–169. Springer, Heidelberg (2016). https://doi.org/10.1007/9783662534137_8CrossRefGoogle Scholar
 14.Donaldson, A., Kaiser, A., Kroening, D., Wahl, T.: Symmetryaware predicate abstraction for sharedvariable concurrent programs. In: Gopalakrishnan, G., Qadeer, S. (eds.) CAV 2011. LNCS, vol. 6806, pp. 356–371. Springer, Heidelberg (2011). https://doi.org/10.1007/9783642221101_28CrossRefGoogle Scholar
 15.Emerson, E.A., Sistla, A.P.: Symmetry and model checking. In: Courcoubetis, C. (ed.) CAV 1993. LNCS, vol. 697, pp. 463–478. Springer, Heidelberg (1993). https://doi.org/10.1007/3540569227_38CrossRefGoogle Scholar
 16.Fedyukovich, G., Gurfinkel, A., Sharygina, N.: Property directed equivalence via abstract simulation. In: Chaudhuri, S., Farzan, A. (eds.) CAV 2016. LNCS, vol. 9780, pp. 433–453. Springer, Cham (2016). https://doi.org/10.1007/9783319415406_24CrossRefGoogle Scholar
 17.Felsing, D., Grebing, S., Klebanov, V., Rümmer, P., Ulbrich, M.: Automating regression verification. In: ASE, pp. 349–360. ACM (2014)Google Scholar
 18.Godefroid, P.: VeriSoft: a tool for the automatic analysis of concurrent reactive software. In: Grumberg, O. (ed.) CAV 1997. LNCS, vol. 1254, pp. 476–479. Springer, Heidelberg (1997). https://doi.org/10.1007/3540631666_52CrossRefGoogle Scholar
 19.Godlin, B., Strichman, O.: Regression verification. In: DAC, pp. 466–471. ACM (2009)Google Scholar
 20.Ip, C.N., Dill, D.L.: Verifying systems with replicated components in mur\({\upphi }\). In: Alur, R., Henzinger, T.A. (eds.) CAV 1996. LNCS, vol. 1102, pp. 147–158. Springer, Heidelberg (1996). https://doi.org/10.1007/3540614745_65CrossRefGoogle Scholar
 21.Kiefer, M., Klebanov, V., Ulbrich, M.: Relational program reasoning using compiler IR. In: Blazy, S., Chechik, M. (eds.) VSTTE 2016. LNCS, vol. 9971, pp. 149–165. Springer, Cham (2016). https://doi.org/10.1007/9783319488691_12CrossRefGoogle Scholar
 22.Lahiri, S.K., McMillan, K.L., Sharma, R., Hawblitzel, C.: Differential assertion checking. In: FSE, pp. 345–355. ACM (2013)Google Scholar
 23.Logozzo, F., Lahiri, S.K., Fähndrich, M., Blackshear, S.: Verification modulo versions: towards usable verification. In: PLDI, p. 32. ACM (2014)Google Scholar
 24.Mordvinov, D., Fedyukovich, G.: Synchronizing constrained horn clauses. In: LPAR. EPiC Series in Computing, vol. 46, pp. 338–355. EasyChair (2017)Google Scholar
 25.Mordvinov, D., Fedyukovich, G.: Verifying safety of functional programs with rosette/unbound. CoRR, abs/1704.04558 (2017). https://github.com/dvvrd/rosette
 26.Pick, L., Fedyukovich, G., Gupta, A.: Exploiting synchrony and symmetry in relational verification (extended version of CAV 2018 paper). https://cs.princeton.edu/%7Eaartig/papers/synonymcav18.pdf
 27.Sousa, M., Dillig, I.: Cartesian hoare logic for verifying ksafety properties. In: PLDI, pp. 57–69. ACM (2016)Google Scholar
 28.Strichman, O., Veitsman, M.: Regression verification for unbalanced recursive functions. In: Fitzgerald, J., Heitmeyer, C., Gnesi, S., Philippou, A. (eds.) FM 2016. LNCS, vol. 9995, pp. 645–658. Springer, Cham (2016). https://doi.org/10.1007/9783319489896_39CrossRefGoogle Scholar
 29.Terauchi, T., Aiken, A.: Secure information flow as a safety problem. In: Hankin, C., Siveroni, I. (eds.) SAS 2005. LNCS, vol. 3672, pp. 352–367. Springer, Heidelberg (2005). https://doi.org/10.1007/11547662_24CrossRefGoogle Scholar
 30.Unno, H., Torii, S., Sakamoto, H.: Automating induction for solving horn clauses. In: Majumdar, R., Kunčak, V. (eds.) CAV 2017. LNCS, vol. 10427, pp. 571–591. Springer, Cham (2017). https://doi.org/10.1007/9783319633909_30CrossRefGoogle Scholar
 31.Yang, H.: Relational separation logic. Theoret. Comput. Sci. 375(1–3), 308–334 (2007)MathSciNetCrossRefGoogle Scholar
 32.Zaks, A., Pnueli, A.: CoVaC: compiler validation by program analysis of the crossproduct. In: Cuellar, J., Maibaum, T., Sere, K. (eds.) FM 2008. LNCS, vol. 5014, pp. 35–51. Springer, Heidelberg (2008). https://doi.org/10.1007/9783540682370_5CrossRefGoogle Scholar
Copyright information
<SimplePara><Emphasis Type="Bold">Open Access</Emphasis>This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License(http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.</SimplePara><SimplePara>The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.</SimplePara>