RHLE: Modular Deductive Verification of Relational ∀∃ Properties
aa r X i v : . [ c s . P L ] N ov RHLE: Modular Deductive Verification of Relational ∀∃ Properties
Robert Dickerson
Purdue University [email protected]
Qianchuan Ye
Purdue University [email protected]
Benjamin Delaware
Purdue University [email protected]
Abstract
Relational program logics are used to prove that a desiredrelationship holds between the execution of multiple pro-grams. Existing relational program logics have focused onverifying that all runs of a collection of programs do notfall outside a desired set of behaviors. Several important rela-tional properties, including refinement and noninterference,do not fit into this category, as they require the existence ofspecific desirable executions. This paper presents RHLE, alogic for verifying a class of relational properties which weterm ∀∃ properties. ∀∃ properties assert that for all execu-tions of a collection of programs, there exist executions ofanother set of programs exhibiting some intended behavior.Importantly, RHLE can reason modularly about programswhich make library calls, ensuring that ∀∃ properties arepreserved when the programs are linked with any valid im-plementation of the library. To achieve this, we develop anovel form of function specification that requires the ex-istence of certain behaviors in valid implementations. Wehave built a tool based on RHLE which we use to verify a di-verse set of relational properties drawn from the literature,including refinement and generalized noninterference. Keywords: relational program logic, deductive program ver-ification
Many interesting program behaviors can be expressed as relational properties which relate the executions of multi-ple programs. Examples of relational properties include pro-gram equivalence, monotonicity, determinism, refinement,and noninterference. Relational program logics [2, 7, 26, 28 ? ] are a popular approach for the deductive verification ofsuch properties, and form the foundation for effective auto-mated verification tools. One important consideration whendeveloping such logics is the treatment of functions calls.The standard approach is to reason about those calls viasome specification of the behavior of any valid implemen-tation. This enables modular reasoning, ensuring that anyproven properties of a program with function calls will con-tinue to hold once it is linked with valid implementationsof those functions. This situation naturally arises in many Conference’17, July 2017, Washington, DC, USA https://doi.org/10.1145/nnnnnnn.nnnnnnn relational verification tasks. When migrating a client of adeprecated API to use a new API with similar functionality,for example, we may wish to ensure that the migrated pro-gram is semantically equivalent to the original, regardlessof the implementations of the underlying APIs.Consider the following Java method which implementsa simple least-connections load balancer by returning the
Server with the lowest number of active connections:
Server leastCons ( Server [] servers ) {Server [] sorted = sortByNumCons ( servers ); return sorted [0];} This code makes a call to a function sortByNumCons , whichwe assume returns a permutation of the input array sortedby the number of active connections to each
Server . Wemight decide to rewrite this method to be more efficient byidentifying the minimum element in a single pass instead ofsorting the entire array:
Server leastCons ( Server [] servers ) {Server min = null ; for ( Server server : servers ) { if ( server . numCons < min . numCons|| min == null ) {min = server ; } } return min ;} Is this rewrite correct? The answer depends on our defini-tion of correctness and the specification of sortByNumCons .If we define correctness as both programs being extension-ally equal, i.e. on the same inputs they always produce thesame result, then the rewrite is only correct if the specifi-cation of sortByNumCons guarantees the sort is stable (i.e.,the servers with the same number of active connections al-ways appear with their original relative ordering.) Other-wise, leastCons has a larger set of potential behaviors than leastCons . For example, say we represent a Server as a ( 𝑛𝑎𝑚𝑒, 𝑐𝑜𝑛𝑛𝑒𝑐𝑡𝑖𝑜𝑛 𝑐𝑜𝑢𝑛𝑡 ) pair and assume sortByNumCons can be linked with an unstable sort. Then, given input {( 𝐴, ) ; ( 𝐵, ) ; ( 𝐶, )} , leastCons might return 𝐴 or 𝐶 , while leastCons always returns 𝐴 .On the other hand, we may decide that extensional equal-ity is too strong and take refinement as an acceptable crite-rion for correctness. We will say leastCons refines leastCons if, for every possible execution of leastCons , there existsan execution of leastCons with the same output. With this onference’17, July 2017, Washington, DC, USA Robert Dickerson, Qianchuan Ye, and Benjamin Delaware definition of correctness, an unstable sortByNumCons wouldbe satisfactory as, in the above example, { 𝐴 } ⊆ { 𝐴, 𝐶 } .Existing relational program logics are capable of verify-ing a wide variety of relational safety properties like tran-sitivity, monotonicity, and idempotence [26]. Such proper-ties require every pair of possible final states to satisfy somerelation. As we just saw, however, properties like programrefinement and semantic equivalence (refinement in bothdirections) do not meet this criterion, as they require the existence of certain executions satsifying some relation. Inparticular, both properties require that for all possible exe-cutions of one program, there exists an execution of anotherprogram with the same final state. We term relational prop-erties with this shape — for all executions of some set ofprograms, there exist executions of some other set of pro-grams such that the final states are in some relation — ∀∃ properties .As we have seen, ∀∃ properties are capable of expressingequivalence and refinement for program transformations andare thus applicable to API migrations, program rewrites andrefactorings, and code merges. However, other kinds of re-lational properties fall into this class as well. Consider thefollowing program which accepts a secret as input and com-putes some publicly visible value: int compute ( int secret ) { int i = someInt (); return secret ^ i;} Here, compute makes a call to a function someInt , stores theresult in i , and returns the result of a bitwise XOR between secret and i . The desired ∀∃ property here is noninterfer-ence [17]: we want to ensure compute does not leak any in-formation about its secret input through its return value.Noninterference can be verified by making two copies of compute called compute ∀ and compute ∃ and checking that,for all pairs of secrets 𝑠 and 𝑠 and for all executions of compute ∀ ( 𝑠 ) , there exists an execution of compute ∃ ( 𝑠 ) thatreturns the same result.Crucially, whether or not compute leaks information de-pends on which values an implementation of someInt is ableto return. If the someInt implementation only ever returnszero, for example, then compute will always give away the se-cret. If someInt is required to be able to return every integer,however, then the secret cannot be deduced from compute ’soutput. To verify noninterference of this client of someInt ,we need a liveness guarantee on someInt on which returnvalues are possible.A key observation in both of these examples is that anyfreedom a function’s specification offers to implementorsmanifests as a sort of nondeterministic behavior when rea-soning about the caller. In the sortByNumCons example, thespecification allowed implementations to choose whether ornot to use a stable sorting algorithm, and so we viewed theresult of sortByNumCons as an aribtrary choice of stable or unstable sorts. In the noninterference example, we treatedthe choice of someInt as nondeterministic, and needed toguarantee that the range of possible choices is sufficientlylarge to ensure nothing is leaked.To illustrate some of the challenges involved in the pres-ence of such nondeterministic choices, consider the follow-ing simplified example where we distill nondeterminism toa zeroOrOne function. This function is understood to returneither 0 or 1. Say we want to show that prog ∀ below is a re-finement of prog ∃ for any valid implementation of zeroOrOne : def prog ∃ ():n = zeroOrOne () if n == 0: return else : return -1 def prog ∀ ():x = zeroOrOne () while x == 0:x = zeroOrOne () return x At first glace, this may seem to be a valid refinement, as prog ∃ can possibly return {− , } while prog ∀ can only re-turn { } ⊆ {− , } . However, the specification “returns ei-ther 1 or 0” is effectively an upper bound on the allowedbehaviors of zeroOrOne : it only requires an implementationto not return a value outside this range. Under this interpre-tation, all of the following implementations of zeroOrOne arevalid ( ⊔ denotes nondeterministic binary choice): Implementation prog ∃ outputs prog ∀ outputsreturn { } ∅ return {− } { } return ⊔ {− , } { } while true ∅ ∅ Now we can see the refinement is not necessarily valid, anddepends on the implementation of zeroOrOne that is ulti-mately used. The key problem is that we need some lower bound (or underapproximation) on zeroOrOne ’s behavior toensure that desirable executions are preserved when a validimplementation is linked in.Note that, in order to establish the existence of a desirableexecution, we must also sometimes take into considerationthe execution paths other programs have taken. For exam-ple, consider the following two programs whose conditionalbranches have been swapped: def prog ∃ ():n = zeroOrOne () if n == 0: return else : return -1 def prog ∀ ():n = zeroOrOne () if n == 0: return -1 else : return In this case, prog ∀ and prog ∃ are semantically equivalent,but the output of zeroOrOne that leads to the correct “thereexists” executions depends on the zeroOrOne result in the“for all” execution. This prevents tricks like “determinizing” This is an instance of the general observation that linking, itself a limitedform of refinement, does not preserve liveness properties [10].2
HLE Conference’17, July 2017, Washington, DC, USA 𝑛 ∈ N Constants 𝑥, 𝑦 ∈ V
Program Variables 𝑓 , 𝑔 ∈ N
Function Names 𝜎 ∈ V → N Program States 𝑠 :: = skip | 𝑠 ; 𝑠 Statements | if 𝑏 then 𝑠 else 𝑠 | while 𝑏 do 𝑠 end | 𝑥 : = 𝑎 | 𝑥 : = havoc | 𝑥 : = 𝑓 ( 𝑎 ) 𝑎 :: = 𝑛 | 𝑥 | 𝑎 + 𝑎 | 𝑎 − 𝑎 | 𝑎 ∗ 𝑎 Arithmetic Expressions 𝑏 :: = true | false Boolean Expressions | 𝑎 = 𝑎 | 𝑎 < 𝑎 | ¬ 𝑏 | 𝑏 ∧ 𝑏 FD :: = def 𝑓 ( 𝑥 ) { 𝑠 ; return 𝑎 } Function Definitions
Figure 1.
Syntax of
FunIMP . zeroOrOne during verification by assuming it always returnsa single arbitrary value in its output range.In this paper, we observe that providing specifications ofupper and lower bounds of program behaviors enables mod-ular and compositional verification of relational ∀∃ proper-ties for programs with function calls, including refinement,program equivalence, and noninterference. Our key insightis to specify lower bounds on function calls as a set of re-quired behaviors, any of which we can choose to exerciseduring verification. We reduce the verification of these be-haviors to identifying appropriate choice variables (a variantof ghost variables used in the specification of these lowerbounds), which allows us to leverage existing relational ver-ification techniques to automatically verify these properties.Using this methodoloy, we have developed a program veri-fier that is capable of automatically verifying a wide range of ∀∃ properties, including refinement, noninterference (withand without delimited release), and semantic parameter us-age.The rest of this paper proceeds as follows: Section 2 be-gins by formalizing a core imperative language with func-tion calls. Section 3 presents a pair of semantics which usefunction specifications to approximate the behavior of pro-grams. In Section 4, we use these semantics to develop RHLE ,a program logic for reasoning about general ∀∃ properties.Section 5 presents an algorithm for automatically verifying RHLE properties. Section 6 presents an evaluation of our ap-proach. We conclude with an examination of related workin Section 7. The accompanying supplementary material in-cludes the implementation of our tool, the complete set ofbenchmarks presented from Section 6, and a Coq formaliza-tion of
RHLE and the proofs presented in Sections 2-4.
We begin with the definition of
FunIMP , a core imperativelanguage with function calls ( 𝑥 : = 𝑓 ( 𝑎 ) ) and unboundednondeterministic variable assignment ( 𝑥 : = havoc ) [15]. Thesyntax of FunIMP is presented in Figure 1. The calculus isparameterized over disjoint sets of identifiers for programvariables V and function names N . Functions have a fixedarity and return a single value. Program states in
FunIMP are mappings from variables to integers. Concrete functiondefinitions consist of a sequence of statements followed byan expression that computes the result of the function. Forbrevity, we denote sequences of arguments 𝑥 , . . . , 𝑥 𝑛 as 𝑥 .The semantics of FunIMP programs are defined via a stan-dard big-step evaluation relation from initial to final pro-gram states. The evaluation rules are parameterized over an implementation context , a mapping 𝐼 ∈ N → FD from func-tion names to their definitions. This context is used to eval-uate function calls: 𝐼 ( 𝑓 ) = def 𝑓 ( 𝑥 ) { 𝑠 ; return 𝑒 } 𝐼 ⊢ 𝜎, 𝑎 ⇓ 𝑣𝐼 ⊢ [ 𝑥 ↦→ 𝑣 ] , 𝑠 ⇓ 𝜎 ′ 𝐼 ⊢ 𝜎 ′ , 𝑒 ⇓ 𝑟𝐼 ⊢ 𝜎, 𝑦 : = 𝑓 ( 𝑎 ) ⇓ [ 𝑦 ↦→ 𝑟 ] 𝜎 ECall
We use ⇓ for the evaluation relation of expressions and com-mands; the desired meaning should be clear from context.The other evaluation rules for FunIMP are standard and canbe found in Appendix A. Note that havoc is the only sourceof nondeterminism when evaluating a
FunIMP program.
FunIMP
Behaviors
Our ultimate goal is to modularly reason about relational ∀∃ properties of client programs when we do not have a con-crete implementation context needed to evaluate functioncalls. To do so, we rely on a set of specifications that bridgethe gap between client programs and possible function im-plementations. The guarantees made to callers by the speci-fications allow us to establish ∀∃ properties that hold whena client program is linked with any valid implementationcontext.Because ∀∃ properties have a “for all, there exists” shape,we have two different kinds of program behavior to consider,each requiring a different category of specification. For uni-versally quantified program executions, we want functionspecifications that provide guarantees about every possibleexecution of a valid implementation. These are specifica-tions of safety properties , and we will refer to them as uni-versal specifications. For existentially quantified executions,we want assurances about the existence of certain execu-tions. These are specifications of liveness properties , and wewill call them existential specifications. ORHLE, the verification tool presented in Section 5, relaxes this latter re-striction, allowing functions to return multiple values3 onference’17, July 2017, Washington, DC, USA Robert Dickerson, Qianchuan Ye, and Benjamin Delaware
The remainder of this section formalizes universal and ex-istential function specification before describing how theyare used to approximate the ∀∃ behaviors of client programs. Function specifications are parameterized over an assertionlanguage A on program states and some mechanism forjudging when a state satisfies an assertion. We write 𝜎 | = 𝑃 to denote that the state 𝜎 satisfies assertion 𝑃 . The univer-sal specifications used to reason about programs on the “forall” side of ∀∃ properties are commonly used for modularreasoning about safety properties. We define the followingsyntax for writing universal specifications: 𝐹𝐴 :: = ax ∀ 𝑓 ( 𝑥 ) { 𝑃 }{ 𝑄 } where 𝑃 ∈ A is a precondition with free variables in 𝑥 and 𝑄 ∈ A is a postcondition with free variables in 𝑥 ∪ { 𝜌 } . Thepostcondition uses the distinguished variable 𝜌 to refer tothe value returned by a function. Universal specificationspromise client programs that a valid implementation canonly evaluate to states satisfying the postcondition from astarting state which satisfies the precondition. Figure 2 listssome example universal specifications.We say a function definition def 𝑓 ( 𝑥 ){ 𝑠 ; return 𝑟 } is ∀ -compatible with an universal specification ax ∀ 𝑓 ( 𝑥 ){ 𝑃 }{ 𝑄 } when evaluating the body 𝑓 in a state satisfying 𝑃 alwaysreturns a value satisfying 𝑄 : ∀ 𝜎, 𝜎 ′ . 𝜎 | = 𝑃 ∧ 𝐼 ⊢ 𝜎, 𝑠 ⇓ 𝜎 ′ ∧ 𝜎 ′ , 𝑟 ⇓ 𝑣 = ⇒[ 𝜌 ↦→ 𝑣 ] 𝜎 | = 𝑄 We say that an implementation context 𝐼 is ∀ -compatiblewith a context of universal specifications 𝑆 ∀ ∈ N → 𝐹𝐴 when every definition in 𝐼 is ∀ -compatible with the specifi-cation given in 𝑆 ∀ . Example 3.1.
The implementations RandB and RandB of RandB listed in Figure 3 are ∀ -compatible with the univer-sal specification given in Figure 2, as every possible returnvalue of these functions fall within the bounds of the univer-sal spec. Note that even though implementation RandB canonly return one value, that value is always within bounds, soit is ∀ -compatible. However, implementation RandB is not ∀ -compatible with the universal specification in Figure 2 be-cause it can return values greater than its argument.To characterize the set of possible behaviors of a programunder any ∀ -compatible implementation context, we definea new overapproximate semantics for FunIMP , ⇓ ∀ . The eval-uation rules of this semantics are based on ⇓ , but they use auniversal specification context, 𝑆 ∀ , instead of an implemen-tation context, and replace ECall with the following two evaluation rules: 𝑆 ∀ ( 𝑓 ) = ax ∀ 𝑓 ( 𝑥 ) { 𝑃 } { 𝑄 } 𝑆 ∀ ⊢ 𝜎, 𝑎 ⇓ ∀ 𝑣 [ 𝑥 ↦→ 𝑣 ] | = 𝑃 [ 𝜌 ↦→ 𝑟 , 𝑥 ↦→ 𝑣 ] | = 𝑄𝑆 ∀ ⊢ 𝜎, 𝑦 : = 𝑓 ( 𝑎 ) ⇓ ∀ [ 𝑦 ↦→ 𝑟 ] 𝜎 ECall ∀ 𝑆 ∀ ( 𝑓 ) = ax ∀ 𝑓 ( 𝑥 ) { 𝑃 } { 𝑄 } 𝑆 ∀ ⊢ 𝜎, 𝑎 ⇓ ∀ 𝑣 [ 𝑥 ↦→ 𝑣 ] 6| = 𝑃𝑆 ∀ ⊢ 𝜎, 𝑦 : = 𝑓 ( 𝑎 ) ⇓ ∀ [ 𝑦 ↦→ 𝑟 ] 𝜎 ECall ∀ If a function is called with arguments satisfying its precon-dition, it returns a value satisfying its postcondition; oth-erwise it can return any value. The latter case allows theoverapproximate semantics to capture evaluations where afunction is called with arguments that don’t meet its pre-condition. Appendix A includes a complete listing of the ⇓ ∀ relation. Example 3.2.
Given the universal specification context: 𝑆 ∀ ≡ { RandB ↦→ ax ∀ RandB ( 𝑥 ){ < 𝑥 }{ ≤ 𝜌 < 𝑥 } } the following are valid evaluations under ⇓ ∀ : 𝑆 ∀ ⊢ 𝜎, 𝑦 : = RandB ( ) ⇓ ∀ [ 𝑦 ↦→ ] 𝜎𝑆 ∀ ⊢ 𝜎, 𝑦 : = RandB ( ) ⇓ ∀ [ 𝑦 ↦→ ] 𝜎𝑆 ∀ ⊢ 𝜎, while 𝑦 ≠ do 𝑦 : = RandB ( ) end ⇓ ∀ [ 𝑦 ↦→ ] 𝜎𝑆 ∀ ⊢ 𝜎, 𝑦 : = RandB ( ) ⇓ ∀ [ 𝑦 ↦→ ] 𝜎 while these are not: 𝑆 ∀ ⊢ 𝜎, 𝑦 : = RandB ( ) ⇓ ∀ [ 𝑦 ↦→ ] 𝜎𝑆 ∀ ⊢ 𝜎, while 𝑦 ≠ do 𝑦 : = RandB ( ) end ⇓ ∀ [ 𝑦 ↦→ ] 𝜎 As these examples suggest, any final state of a programevaluated under an implementation context 𝐼 which is ∀ -compatible with 𝑆 ∀ can also be produced using ⇓ ∀ and 𝑆 ∀ .Appealing to this intuition, we call the evaluations of a Fu-nIMP program 𝑝 using ⇓ ∀ the overapproximate executions of 𝑝 under 𝑆 ∀ . Theorem 3.3.
When run under an implementation context 𝐼 that is ∀ -compatible with specification context 𝑆 ∀ with aninitial state 𝜎 , a program 𝑝 will either diverge or evaluate to astate 𝜎 ′ which is also the result of one of its overapproximateexecutions under 𝑆 ∀ . Universal specifications approximate function calls on the“for all” side of ∀∃ properties by constraining what a com-patible implementation can do. Existential specifications ap-proximate the “there exists” executions by describing requiredbehaviors that a valid implementation must do. In order toflexibly capture these behaviors, existential pre- and post-conditions are indexed by a set of choice variables 𝑐 ⊆ V .Each particular instantiation of these variables defines a par-ticular behavior that an implementation must exhibit. The HLE Conference’17, July 2017, Washington, DC, USA
Informal Description Universal Existential
Multiply by Two ax ∀ TimesTwo( 𝑥 ) { ⊤ } { 𝜌 = 𝑥 ∗ } ax ∃ TimesTwo( 𝑥 ) [] { ⊤ } { 𝜌 = 𝑥 ∗ }Binary NondeterministicChoice ( 𝑎 ⊔ 𝑎 ) ax ∀ Choose( 𝑥 , 𝑦 ) { ⊤ } { 𝜌 = 𝑥 ∨ 𝜌 = 𝑦 } ax ∃ Choose( 𝑥 , 𝑦 ) [ 𝑐 ] { 𝑐 = 𝑥 ∨ 𝑐 = 𝑦 } { 𝜌 = 𝑐 }Bounded Random NumberGeneration ax ∀ RandB( 𝑥 ) { < 𝑥 } { ≤ 𝜌 < 𝑥 } ax ∃ RandB( 𝑥 ) [ 𝑐 ] { < 𝑥 ∧ ≤ 𝑐 < 𝑥 } { 𝜌 = 𝑐 } Figure 2.
Example universal and existential function specifications.RandB RandB RandB def RandB(x) {skip; return def RandB(x) {r := havoc;while (x < r) dor := r − xend; return r } def RandB(x) {r := havoc; return r} Figure 3.
Example implementations of
RandB . Only
RandB satisfies the full specification of RandB given inFigure 2.syntax for writing existential specifications is:
𝐹 𝐸 :: = ax ∃ 𝑓 ( 𝑥 ) [ 𝑐 ] { 𝑃 }{ 𝑄 } Intuitively, for any instantiation 𝑣 of choice variables 𝑐 , anexistential specification requires an implementation to pro-duce at least one value satisfying the specialized postcon-dition 𝑄 [ 𝑣 / 𝑐 ] when called with arguments that satisfy thecorresponding precondition 𝑃 [ 𝑣 / 𝑐 ] . Some examples of exis-tential specifications are given in Figure 2. The specificationfor nondeterministic binary choice, for example, stipulatesthat it must be possible for ⊔ to return either of its argu-ments.This intuition is embodied in our notion of compatibil-ity for existential specifications: we say a function defini-tion def 𝑓 ( 𝑥 ){ 𝑠 ; return 𝑟 } is ∃ -compatible with an existen-tial specification ax ∃ 𝑓 ( 𝑥 ) [ 𝑐 ]{ 𝑃 }{ 𝑄 } when evaluating thedefinition of 𝑓 in a state satisfying 𝑃 terminates in at leastone state meeting 𝑄 : ∀ 𝜎 𝑣. 𝜎 | = 𝑃 [ 𝑣 / 𝑐 ] = ⇒∃ 𝜎 ′ . 𝐼 ⊢ 𝜎, 𝑠 ⇓ 𝜎 ′ ∧ 𝜎 ′ , 𝑟 ⇓ 𝑣 ∧ [ 𝜌 ↦→ 𝑣 ] 𝜎 | = 𝑄 [ 𝑣 / 𝑐 ] Both RandB and RandB in Figure 3 are ∃ -compatiblewith the existential specification of RandB in Figure 2. Theseimplementations can always produce a final state that meetsthe precondition, for any instantiation of the specification’schoice variable. The fact that RandB can return values out-side the specification does not affect its ∃ -compatibility, asit can also produce all mandated behaviors. ImplementationRandB , on the other hand, is not ∃ -compatible with its spec-ification, as there exist selections of choice values that are 𝑆 ∃ ⊢ 𝜎, skip ⇓ ∃ { 𝜎 } ESkip ∃ 𝜎, 𝑎 ⇓ 𝑣𝑆 ∃ ⊢ 𝜎, 𝑥 := 𝑎 ⇓ ∃ {[ 𝑥 ↦→ 𝑣 ] 𝜎 } EAssn ∃ 𝑆 ∃ ⊢ 𝜎, 𝑥 : = havoc ⇓ ∃ { 𝜎 ′ | ∃ 𝑣. [ 𝑥 ↦→ 𝑣 ] 𝜎 } EHavoc ∃ 𝑆 ∃ ⊢ 𝜎, 𝑐 ⇓ ∃ Σ ∀ 𝜎 ′ ∈ Σ . ∃ Σ ′ . 𝑆 ∃ ⊢ 𝜎 ′ , 𝑐 ⇓ ∃ Σ ′ Ø 𝜎 ′ ∈ Σ { Σ ′ | 𝑆 ∃ ⊢ 𝜎 ′ , 𝑐 ⇓ ∃ Σ ′ } 𝑆 ∃ ⊢ 𝜎, 𝑐 ; 𝑐 ⇓ ∃ Σ ′ ESeq ∃ 𝜎, 𝑏 ⇓ true 𝑆 ∃ ⊢ 𝜎, 𝑐 ⇓ ∃ Σ ∀ 𝜎 ′ ∈ Σ . ∃ Σ ′ . 𝑆 ∃ ⊢ 𝜎 ′ , 𝑐 ⇓ ∃ Σ ′ Ø 𝜎 ′ ∈ Σ { Σ ′ | 𝑆 ∃ ⊢ 𝜎 ′ , while 𝑏 do 𝑐 end ⇓ ∃ Σ ′ } 𝑆 ∃ ⊢ 𝜎, while 𝑏 do 𝑐 end ⇓ ∃ Σ ′ EWhileT ∃ 𝜎, 𝑏 ⇓ false 𝑆 ∃ ⊢ 𝜎, while 𝑏 do 𝑐 end ⇓ ∃ { 𝜎 } EWhileF ∃ 𝜎, 𝑏 ⇓ true 𝑆 ∃ ⊢ 𝜎, 𝑐 ⇓ ∃ Σ 𝑆 ∃ ⊢ 𝜎, if 𝑏 then 𝑐 else 𝑐 ⇓ ∃ Σ ECondT ∃ 𝜎, 𝑏 ⇓ ⊥ 𝑆 ∃ ⊢ 𝜎, 𝑐 ⇓ ∃ Σ 𝑆 ∃ ⊢ 𝜎, if 𝑏 then 𝑐 else 𝑐 ⇓ ∃ Σ ECondF ∃ 𝑆 ∃ ( 𝑓 ) = ax ∃ 𝑓 ( 𝑥 ) [ 𝑐 ] { 𝑃 } { 𝑄 } 𝑆 ∃ ⊢ 𝜎, 𝑎 ⇓ 𝑣 [ 𝑥 ↦→ 𝑣 ] | = 𝑃 [ 𝑘 / 𝑐 ] 𝑆 ∃ ⊢ 𝜎, 𝑦 : = 𝑓 ( 𝑎 ) ⇓ ∃ { 𝜎 ′ | ∃ 𝑟 . 𝜎 ′ = [ 𝑦 ↦→ 𝑟 ] 𝜎 ∧ [ 𝜌 ↦→ 𝑟, 𝑥 ↦→ 𝑣 ] | = 𝑄 [ 𝑘 / 𝑐 ]} ECall ∃ Figure 4.
The evaluation relation for existential executions.not realizable for all arguments. For example, [ 𝑥 ↦→ ] satis-fies the precondition when [ 𝑐 ↦→ ] , but RandB can neverreturn 3. As another example, no deterministic function is ∃ -compatible with the specification of binary nondetermisticchoice in Figure 3 for similar reasons.Equipped with a context of existential specifications 𝑆 ∃ ∈N → 𝐹 𝐸 , we characterize the set of behaviors a program onference’17, July 2017, Washington, DC, USA Robert Dickerson, Qianchuan Ye, and Benjamin Delaware must exhibit under every ∃ -compatible implementation con-text via an underapproximate semantics for FunIMP pro-grams. The judgements of this semantics are denoted as 𝑆 ∃ ⊢ 𝜎, 𝑝 ⇓ ∃ Σ , which reads as: under specification context 𝑆 ∃ and initial state 𝜎 , the program 𝑝 can produce a final statein a set of states Σ .The evaluation rules of this semantics are given in Figure 4.Most of the rules in Figure 4 adapt the FunIMP evaluationrules to account for the fact that commands now produce sets of states from an initial state. The productivity rule forsequences,
ESeq ∃ , for example, states that 𝑐 produces a fi-nal state corresponding to every state in the set produced by 𝑐 . The rule for function calls, ECall ∃ , is the most interest-ing; it chooses one of the existential behaviors guaranteedby the existential specification of a function and produces a set of final states for every return value consistent with thatchoice. Example 3.4.
Consider a relaxed version of
RandB called
RandBucket . Instead of stipulating that every number lessthan its bound is a possible return value,
RandBucket onlyrequires that at least one “small” and one “large” value withinits bound is possible. We give
RandBucket the following ex-istential specification: ax ∃ RandBucket ( 𝑥 ) [ 𝑐 ] {( 𝑐 = ∨ 𝑐 = ) ∧ < 𝑥 }{( 𝑐 = = ⇒ ≤ 𝜌 < 𝑥 ) ∧ ( 𝑐 = = ⇒ 𝑥 ≤ 𝜌 < 𝑥 )} Taking 𝑆 ∃ to be an existential context with this specificationfor RandBucket , the following reductions are in ⇓ ∃ : 𝑆 ∃ ⊢ 𝜎, 𝑦 : = RandBucket ( ) ⇓ ∃ {[ 𝑦 ↦→ 𝑛 ] | ≤ 𝑛 < } 𝑆 ∃ ⊢ 𝜎, 𝑦 : = RandBucket ( ) ⇓ ∃ {[ 𝑦 ↦→ 𝑛 ] | ≤ 𝑛 < } 𝑆 ∃ ⊢ 𝜎, 𝑥 : = RandBucket ( ) ; 𝑦 : = RandBucket ( )⇓ ∃ {[ 𝑥 ↦→ 𝑚, 𝑦 ↦→ 𝑛 ] | ≤ 𝑚 < ∧ ≤ 𝑛 < } This last example can also produce the following sets: {[ 𝑥 ↦→ 𝑚, 𝑦 ↦→ 𝑛 ] | ≤ 𝑚 < ∧ ≤ 𝑛 < }{[ 𝑥 ↦→ 𝑚, 𝑦 ↦→ 𝑛 ] | ≤ 𝑚 < ∧ ≤ 𝑛 < }{[ 𝑥 ↦→ 𝑚, 𝑦 ↦→ 𝑛 ] | ≤ 𝑚 < ∧ ≤ 𝑛 < } Each of these sets corresponds to a particular selection ofchoice variable for the calls to
RandBucket . The followingevaluations, however, are not valid: 𝑆 ∃ ⊢ 𝜎, 𝑦 : = RandBucket ( ) ⇓ ∃ {[ 𝑦 ↦→ ]} 𝑆 ∃ ⊢ 𝜎, 𝑦 : = RandBucket ( ) ⇓ ∃ {[ 𝑦 ↦→ 𝑛 ] | ≤ 𝑛 < } 𝑆 ∃ ⊢ 𝜎, while 𝑦 ≠ do 𝑦 : = RandB ( ) end ⇓ ∃ {[ 𝑦 ↦→ 𝑛 | ≤ 𝑛 < ]} In the first example, {[ 𝑦 ↦→ ]} is too restricted, as the spec-ification of RandBucket does not make such a strong guar-antee. The second example similarly assumes the existenceof return values that are not guaranteed. The third examplemay seem at first to be valid, since the evaluation rules allow us to select which
RandBucket execution we want. How-ever, the choice variable in this specification only controlswhich bucket we get, while the actual return value withinthat bucket is up to the implementation. As there is no re-quirement that a return value of 10 is possible, this programmight fail to terminate for some ∃ -compatible RandBucket implementation. Allowing the client to pick the choice valuebut the implementation to pick the concrete behavior allowedby that choice is critical to our verification approach.Every set of final states for a program 𝑝 produced by thesesemantics under 𝑆 ∃ includes a possible final state of 𝑝 whenevaluated under any ∃ -compatible implementation context.For this reason, we term the evaluations of 𝑝 using ⇓ ∃ the underapproximate executions of 𝑝 under 𝑆 ∃ . Theorem 3.5.
If there is an underapproximate evaluation ofprogram 𝑝 to a set of states Σ from an initial state 𝜎 under 𝑆 ∃ ,then 𝑝 must terminate in at least one final state 𝜎 ′ ∈ Σ from 𝜎 under every implementation context 𝐼 that is ∃ -compatiblewith 𝑆 ∃ . ∀∃ behaviors Taken together, these two semantics allow us to relate the ∀∃ behaviors of multiple client programs under every ∀ - and ∃ -compatible implementation context. This admits a mod-ular reasoning principle, where if a set of clients of someAPI can be shown to exhibit some behaviors using the over-approximate and underapproximate semantics, linking theclient with any compatible environment will continue to ex-hibit those behaviors. The key challenge to ensuring these ∀∃ behaviors is identifying, for every overapproxmiate exe-cution, a selection of choice variables that cause the under-approximate executions to evaluate to a collection of finalstates satisfying a desired ∀∃ property. RHLE
We now present
RHLE , a relational program logic for prov-ing that a collection of
FunIMP programs exhibit some de-sired set of behaviors under a combination of universal andexistential execution semantics. Properties established in
RHLE are guaranteed to hold when the program is linked with anycompatible implementation context.
RHLE specifications use relational assertions (denoted Φ , Ψ ∈A ) to relate the execution of multiple programs. As normalassertions are predicates on a single state, a relational as-sertion is a predicate on 𝑘 states. Following existing con-vention [7, 26], every variable in a relational assertion is in-dexed by natural number identifying which state it belongsto. As an example, the relational assertion 𝑥 ≤ 𝑥 is a bi-nary predicate over two states. This assertion is satisfied byany pair of states where the value of 𝑥 in the first state isless than the value of 𝑥 in the second. HLE Conference’17, July 2017, Washington, DC, USA
Example 4.1.
The following relational assertions are valid: [ 𝑥 ↦→ ] , [ 𝑥 ↦→ ] | = 𝑥 ≤ 𝑥 [ 𝑥 ↦→ , 𝑦 ↦→ ] , [ 𝑥 ↦→ ,𝑦 ↦→ ] | = 𝑦 < 𝑥 [ 𝑥 ↦→ 𝑎, 𝑦 ↦→ 𝑏 ] , [ 𝑥 ↦→ 𝑏, 𝑦 ↦→ 𝑐 ] , [ 𝑥 ↦→ 𝑎, 𝑦 ↦→ 𝑐 ] | = 𝑥 = 𝑥 ∧ 𝑦 = 𝑥 ∧ 𝑦 = 𝑦 RHLE triples assert that for all universal executions ofsome programs 𝑝 ∀ , there exist existential executions of pro-grams 𝑝 ∃ satisfying some relational pre- and post-condition Φ and Ψ : 𝑆 ∀ , 𝑆 ∃ | = h Φ i 𝑝 ∀ ∼ ∃ 𝑝 ∃ h Ψ i Formally, the semantics of this assertion is: 𝑆 ∀ , 𝑆 ∃ | = h Φ i 𝑝 ∀ ∼ ∃ 𝑝 ∃ h Ψ i ≡∀ 𝜎 ∀ 𝜎 ∃ 𝜎 ′∀ . 𝜎 ∀ , 𝜎 ∃ | = Φ ∧ 𝑆 ∀ ⊢ 𝜎 ∀ , 𝑝 ∀ ⇓ ∀ 𝜎 ′∀ = ⇒∃ Σ . 𝑆 ∃ ⊢ 𝜎 ∃ , 𝑝 ∃ ⇓ ∃ Σ ∧ ∀ 𝜎 ′∃ ∈ Σ . 𝜎 ′∀ , 𝜎 ′∃ | = Ψ Figure 5 gives some example
RHLE assertions. We use ⊛ to delineate different programs in the universal and existen-tial contexts so that, e.g., a sequence of 𝑛 programs 𝑝 is alsodenoted as 𝑝 ⊛ . . . ⊛ 𝑝 𝑛 . The first listed property, generalizednoninterference [20], adapts the standard information flowproperty for nondeterministic programs, requiring that forevery set of low-value inputs there must exist at least oneexecution terminating in the same low-valued outputs re-gardless of high-value inputs. In the second row, program 𝑝 refines a program 𝑝 if 𝑝 can terminate in the every finalstate 𝑝 can. The final three rows illustrate that, by placingcopies of a program on one side of ∼ ∃ and skip on the other, RHLE triples can capture pure 𝑘 -safety or 𝑘 -liveness hyper-properties. The third row gives a kind of semantic param-eter usage requirement, where a parameter is consideredused when changing it can result in a different output. Thesecond-to-last row asserts that a function 𝑓 is injective, a -safety hyperproperty, while the last row asserts that 𝑓 be-haves nondeterministically on all inputs, a 2-liveness prop-erty.Building a proofs in RHLE is akin to playing a game overthe possible execution paths of the programs being verified.For every execution path a universally quantified programin 𝑝 ∀ can take, we need a strategy for choosing executionpaths in each 𝑝 ∃ program that ensure they terminate in astate satisfying the relational post-condition. The choiceswe are afforded in the proofs about existential executionpaths are the embedded choice variables, so this strategyspells out how to instantiate choice variables in a way thatshepherds those existential executions into desirable finalstates. A key feature of RHLE is that the selection of choicevariables may depend on the context of other program exe-cutions; e.g., different choice strategies may be employed de-pending on whether a conditional in another program tooka then or else branch. Example 4.2.
Consider the function
RandB specified as inFigure 2 and the following
RHLE assertion: 𝑆 ∀ , 𝑆 ∃ ⊢ h⊤i 𝑥 := RandB ( ) ; if ( 𝑥 < ) then 𝑦 := else 𝑦 := ∼ ∃ 𝑦 := RandB ( ) h 𝑦 = 𝑦 i The verification “game” proceeds as follows. First, the uni-versal execution chooses a return value for
RandB ( ) withinthe bounds of its universal specification ( ≤ 𝑥 < ), andthen sets 𝑦 accordingly. Next, the verifier gets to pick avalue for the choice variable 𝑐 in the existential specifica-tion of RandB ( ) . The verifier’s goal is to pick 𝑐 in a waythat always brings the existential execution into a winningstate ( 𝑦 = 𝑦 ). When choosing 𝑐 , the verifier knows that ≤ 𝑥 < , but not the concrete value of 𝑥 in this range,and so needs a strategy that covers all possible cases. Here,the winning strategy is to pick 𝑐 = when 𝑥 < and 𝑐 = when 𝑥 ≥ .This general strategy is embedded in the the core logicof RHLE given in Figure 6. Proofs are built by stepping oversingle statements in either a universally quantified execu-tion via the
Step ∀ rule or an existentially quantified execu-tion using the Step ∃ rule. Once all program statements havebeen considered, final proof obligations can be dischargedusing a combination of SkipIntro and
Finish . Both
Step rules rely on non-relational logics for reasoning about theuniversal ( 𝑆 ∀ ⊢ { 𝑃 } 𝑝 { 𝑄 } ) and existential ( 𝑆 ∃ ⊢ [ 𝑃 ] 𝑝 [ 𝑄 ] ∃ )execution of single statements; the next sections present thedetails of these logics. Both Step rules use a projection op-eration, 𝜎 | 𝑖 Ψ , which maps a relational assertion to a non-relational one. Given a collection of 𝑛 states, Ψ | 𝑖 𝜎 is satis-fied by any state 𝜎 ′ which satisfies Ψ when inserted at the 𝑖 th position: 𝜎 ′ | = Ψ | 𝑖 𝜎 ≡ 𝜎 , . . . , 𝜎 𝑖 − , 𝜎 ′ , 𝜎 𝑖 + , . . . , 𝜎 𝑛 | = Ψ In effect, this operation ensures the states of the other pro-grams remain unchanged when reasoning about the 𝑖 th pro-gram. The program logic for universal executions has a standardpartial correctness semantics: 𝑆 ∀ ⊢ { 𝑃 } 𝑝 { 𝑄 } ≡∀ 𝜎, 𝜎 ′ . 𝜎 | = 𝑃 ∧ 𝑆 ∀ ⊢ 𝜎, 𝑝 ⇓ ∀ 𝜎 ′ = ⇒ 𝜎 ′ | = 𝑄 The rules of this logic are largely textbook, except for therule for function calls, which uses a context of universalfunction specifications: 𝑆 ∀ ( 𝑓 ) = ax ∀ 𝑓 ( 𝑥 ){ 𝑃 }{ 𝑄 } 𝑆 ∀ ⊢ ( 𝑃 [ 𝑎 / 𝑥 ] ∧∀ 𝑣.𝑄 [ 𝑣 / 𝜌 ; 𝑎 / 𝑥 ] = ⇒ 𝑅 [ 𝑣 / 𝑦 ] ) 𝑦 := 𝑓 ( 𝑎 ) { 𝑅 } ∀ Spec onference’17, July 2017, Washington, DC, USA Robert Dickerson, Qianchuan Ye, and Benjamin Delaware Relational Property
RHLE
Assertion
Generalized Noninterference 𝑆 ∀ , 𝑆 ∃ | = h 𝐿𝑜𝑤 = 𝐿𝑜𝑤 i 𝑝 ∼ ∃ 𝑝 h 𝐿𝑜𝑤 = 𝐿𝑜𝑤 i Refinement 𝑆 ∀ , 𝑆 ∃ | = h 𝑖𝑛𝑝𝑢𝑡 = 𝑖𝑛𝑝𝑢𝑡 i 𝑝 ∼ ∃ 𝑝 h 𝑟𝑒𝑡𝑢𝑟𝑛 = 𝑟𝑒𝑡𝑢𝑟𝑛 i Parameter Usage 𝑆 ∀ , 𝑆 ∃ | = (cid:28) 𝑟 𝑖 ≠ 𝑠 𝑖 ∧ Ó ≤ 𝑗 < 𝑛,𝑗 ≠ 𝑖 𝑟 𝑗 = 𝑠 𝑗 (cid:29) skip ∼ ∃ 𝑟𝑒𝑡 : = 𝑓 ( 𝑟 ) ⊛ 𝑟𝑒𝑡 : = 𝑓 ( 𝑠 ) h 𝑟𝑒𝑡 ≠ 𝑟𝑒𝑡 i Injectivity 𝑆 ∀ , 𝑆 ∃ | = h 𝑥 ≠ 𝑥 i 𝑦 := 𝑓 ( 𝑥 ) ⊛ 𝑦 := 𝑓 ( 𝑥 ) ∼ ∃ skip h 𝑦 ≠ 𝑦 i Nondeterministic Execution 𝑆 ∀ , 𝑆 ∃ | = h 𝑥 = 𝑥 i skip ∼ ∃ 𝑦 := 𝑓 ( 𝑥 ) ⊛ 𝑦 := 𝑓 ( 𝑥 ) h 𝑦 ≠ 𝑦 i Figure 5.
Example
RHLE assertions. 𝑆 ∀ , 𝑆 ∃ ⊢ h Φ i skip ∼ ∃ skip h Φ i Finish 𝑆 ∀ , 𝑆 ∃ ⊢ h Φ i 𝑝 ∀ ; skip ∼ ∃ 𝑝 ∃ ; skip h Ψ i 𝑆 ∀ , 𝑆 ∃ ⊢ h Φ i 𝑝 ∀ ∼ ∃ 𝑝 ∃ h Ψ i SkipIntro ∀ 𝜎 𝜎 ∃ . 𝑆 ∀ ⊢ { Φ | 𝑖 𝜎, 𝜎 ∃ } 𝑠 𝑖 { Φ ′ | 𝑖 𝜎, 𝜎 ∃ } 𝑆 ∀ , 𝑆 ∃ ⊢ h Φ ′ i 𝑝 ⊛ . . . ⊛ 𝑠 ′ 𝑖 ⊛ . . . ⊛ 𝑠 𝑛 ∼ ∃ 𝑝 ∃ h Ψ i 𝑆 ∀ , 𝑆 ∃ ⊢ h Φ i 𝑝 ⊛ . . . ⊛ 𝑠 𝑖 ; 𝑠 ′ 𝑖 ⊛ . . . ⊛ 𝑝 𝑛 ∼ ∃ 𝑐 ∃ h Ψ i Step ∀∀ 𝜎 ∀ 𝜎. 𝑆 ∃ ⊢ [ Φ | 𝑖 𝜎 ∀ , 𝜎 ] 𝑠 𝑖 (cid:2) Φ ′ | 𝑖 𝜎 ∀ , 𝜎 (cid:3) ∃ 𝑆 ∀ , 𝑆 ∃ ⊢ h Φ ′ i 𝑝 ∀ ∼ ∃ 𝑝 ⊛ . . . ⊛ 𝑐 ′ 𝑖 ⊛ . . . ⊛ 𝑝 𝑛 h Ψ i 𝑆 ∀ , 𝑆 ∃ ⊢ h Φ i 𝑝 ∀ ∼ ∃ 𝑝 ⊛ . . . ⊛ 𝑠 𝑖 ; 𝑠 ′ 𝑖 ⊛ . . . ⊛ 𝑝 𝑛 h Ψ i Step ∃ Figure 6.
RHLE proof rules.Appendix B gives a full listing of the rules of this logic.
The assertions of our program logic for existential execu-tions say that, for any state meeting the precondition, there exists an execution of the program ending in a set of statesmeeting the post-condition: 𝑆 ∃ ⊢ [ 𝑃 ] 𝑝 [ 𝑄 ] ∃ ≡∀ 𝜎. 𝜎 | = 𝑃 = ⇒ ∃ Σ . 𝑆 ∃ ⊢ 𝜎, 𝑝 ⇓ ∃ Σ ∧ ∀ 𝜎 ′ ∈ Σ . 𝜎 ′ | = 𝑄 Figure 7 presents the proof rules of the existential logic. Theserules are largely standard total
Hoare logic rules, augmentedwith a rule for calls to existentially specified functions. As atotal logic, the ∃ While rule needs to guarantee that at leastone terminating path through a loop exists. To do so, it iden-tifies a variant 𝑎 drawn from some set 𝐴 , a measure relation 𝑀 ⊆ State × 𝐴 , and a well-founded relation 𝑅 ⊆ 𝐴 × 𝐴 which are used to augment the pre- and post-conditions ofthe loop body in order to ensure at least one execution of theloop body makes progress to a final state. In practice, ourverifier uses natural numbers for 𝐴 , equality for 𝑀 , and thestandard less than relation for 𝑅 , but ∃ While uses this moregeneral formulation to account for the fact that existentialfunction calls are effectively unbounded nondeterministicchoices [16]. | = 𝑃 = ⇒ 𝑃 ′ | = 𝑄 ′ = ⇒ 𝑄 𝑆 ∃ ⊢ (cid:2) 𝑃 ′ (cid:3) 𝑠 (cid:2) 𝑄 ′ (cid:3) ∃ 𝑆 ∃ ⊢ [ 𝑃 ] 𝑠 [ 𝑄 ] ∃ ∃ Conseq 𝑆 ∃ ⊢ [ 𝑃 ] skip [ 𝑃 ] ∃ ∃ Skip 𝑆 ∃ ⊢ [ 𝑄 [ 𝑎 / 𝑥 ]] 𝑥 := 𝑎 [ 𝑄 ] ∃ ∃ Assgn 𝑆 ∃ ⊢ [∃ 𝑣. 𝑄 [ 𝑣 / 𝑥 ]] 𝑥 := havoc [ 𝑄 ] ∃ ∃ Havoc 𝑆 ∃ ⊢ [ 𝑃 ] 𝑠 (cid:2) 𝑃 ′ (cid:3) ∃ 𝑆 ∃ ⊢ (cid:2) 𝑃 ′ (cid:3) 𝑠 [ 𝑄 ] ∃ 𝑆 ∃ ⊢ [ 𝑃 ] 𝑠 ; 𝑠 [ 𝑄 ] ∃ ∃ Seq 𝑆 ∃ ⊢ [ 𝑃 ∧ 𝑏 ] 𝑠 [ 𝑄 ] ∃ 𝑆 ∃ ⊢ [ 𝑃 ∧ ¬ 𝑏 ] 𝑠 [ 𝑄 ] ∃ 𝑆 ∃ ⊢ [ 𝑃 ] if 𝑏 then 𝑠 else 𝑠 [ 𝑄 ] ∃ ∃ Cond 𝑅 is well-founded 𝑆 ∃ ⊢ [ 𝑃 ∧ 𝑏 ∧ 𝑀 𝑎 ] 𝑠 (cid:2) 𝑃 ∧ ∃ 𝑎 ′ . 𝑀 𝑎 ′ ∧ 𝑎 ′ 𝑅 𝑎 (cid:3) ∃ 𝑆 ∃ ⊢ [ 𝑃 ∧ ∃ 𝑎. 𝑀 𝑎 ] while 𝑏 do 𝑠 end [ 𝑃 ∧ ¬ 𝑏 ] ∃ ∃ While 𝐸 ( 𝑓 ) = ax ∃ 𝑓 ( 𝑥 ) [ 𝑐 ] { 𝑃 } { 𝑄 } 𝑆 ∃ ⊢ ∃ 𝑘. ( [ 𝑥 ↦→ 𝑎 ] | = 𝑃 [ 𝑘 / 𝑐 ]∧ ∃ 𝑣. [ 𝜌 ↦→ 𝑣, 𝑥 ↦→ 𝑎 ] | = 𝑄 [ 𝑘 / 𝑐 ]∧ ∀ 𝑣. [ 𝜌 ↦→ 𝑣, 𝑥 ↦→ 𝑎 ] | = 𝑄 [ 𝑘 / 𝑐 ] = ⇒ 𝑅 [ 𝑣 / 𝑦 ]) 𝑦 := 𝑓 ( 𝑎 ) [ 𝑅 ] ∃ ∃ Spec
Figure 7.
Existential Hoare logic rules.The ∃ Spec handles calls to existentially specified func-tions. The precondition is quantified over instantiations 𝑘 of the specification’s choice variables. The first of the threeconjuncts under this quantifier ensures that the statementis executed in a state satisfying the function’s precondition.The next conjunct ensures that the function’s post-conditionis inhabited. The final conjunct requires that every possi-ble return value satisfying the function’s post-condition alsosatisfies the triple’s post-condition. Example 4.3.
We can use the ∃ While and ∃ Spec to provethe existential assertion 𝑆 ∃ ⊢ [ 𝑘 = ] while 𝑘 < do 𝑘 := 𝑘 + ⊔ end [⊤] ∃ . This loop could loop forever by choosing toadd to 𝑘 at every iteration. Nevertheless, by using 𝑀 𝑎 𝜎 ≡ 𝑎 = − 𝑘 and 𝑅 𝑎 𝑎 ′ ≡ 𝑎 ′ < 𝑎 , and instantiating the choice HLE Conference’17, July 2017, Washington, DC, USA variable with 𝑘 + at each iteration, we can prove a termi-nating path through the program exists. Equipped with these program logics, we can now prove that
RHLE is sound:
Theorem 4.4 (RHLE is Sound) . Suppose 𝑆 ∀ , 𝑆 ∃ ⊢ h Φ i 𝑝 ∀ ∼ ∃ 𝑝 ∃ h Ψ i . Then, for any function context 𝐼 compatible with 𝑆 ∀ and 𝑆 ∃ , any set of initial states 𝜎 ∀ and 𝜎 ∃ satisfying Φ , andevery collection of final states 𝜎 ′∀ of 𝑝 ∀ , there must exist a col-lection of final states produced by 𝑝 ∃ that, together with 𝜎 ′∀ satisfies the relational post-condition Ψ . The central game in verifying ∀∃ properties using RHLE is finding choice variable instantiations that bring existen-tially quantified programs into acceptable final states. Thissection presents an algorithm for verifying
RHLE assertionsvia weakest precondition analysis. An implementation ofthis strategy is evaluated in Section 6.The high-level approach for generating verification con-ditions for
RHLE assertions is to reason backward from therelational postcondition by applying
Step ∀ and Step ∃ untilall program statements have been considered. The weakestprecondition semantics for existential function applicationscontain existential quantifications over choice variables, andit is up to the verification procedure (e.g. an SMT solver) todetermine whether or not there are suitable instantiationsof choice variables.The verification algorithm is parameterized over the fol-lowing procedures: Verify : a decision procedure for the assertion logic. Variant : an oracle that provides loop variants. Invariant : an oracle that provides loop invariants.We also assume a procedure called ChooseStep ( 𝑝 ∀ , 𝑝 ∃ ) ,which selects the next program statement to reason aboutwhen constructing the verification condition. Given sequences 𝑝 ∀ of universal programs and 𝑝 ∃ of existential programs, ChooseStep returns a program statement 𝑠 appearing at theend of the 𝑖 th program in 𝑝 ∀ ∪ 𝑝 ∃ , and a tag 𝜂 indicatingwhether the chosen statement was from 𝑝 ∀ or 𝑝 ∃ . To pre-serve the “for all, there exists” RHLE semantics,
ChooseStep should exhaust all statements in 𝑝 ∃ programs before step-ping over any statements in 𝑝 ∀ , to ensure that existentialquantifications are placed under universal quantifications.The procedure for generating verification conditions hastwo components. The first, StatementVC , is shown in Algorithm 1.
StatementVC generates verification conditions for non-relationalHoare triples and effectively implements a weakest precon-dition predicate transformer semantics. It handles both uni-versal and existential non-relational Hoare logic, using the 𝜂 Algorithm 1:
StatementVC
Inputs : 𝑠𝑡𝑚𝑡 , a
FunIMP program statement 𝜂 , 𝑠𝑡𝑚𝑡 ’s execution context ( ∀ or ∃ ) Ψ , a relational postcondition 𝑆 ∀ , a universal specification context 𝑆 ∃ , an existential specification context Output : verification conditions for 𝑠𝑡𝑚𝑡 to meet Ψ in the given execution context beginmatch 𝑠𝑡𝑚𝑡 :case skip doreturn Ψ case y := a doreturn Ψ [ 𝑎 / 𝑦 ] case 𝑦 := havoc , 𝜂 = ∀ doreturn ∀ 𝑣. Ψ [ 𝑣 / 𝑦 ] case 𝑦 := havoc , 𝜂 = ∃ doreturn ∃ 𝑣. Ψ [ 𝑣 / 𝑦 ] case 𝑦 := 𝑓 ( 𝑎 ) , 𝜂 = ∀ do ( 𝑃, 𝑄 ) ← 𝑆 ∀ ( 𝑓 ) return 𝑃 [ 𝑎 / 𝑥 ] ∧ ∀ 𝑟 . ( 𝑄 [ 𝑟 / 𝜌, 𝑎 / 𝑥 ] = ⇒ Ψ [ 𝑟 / 𝑦 ]) case 𝑦 := 𝑓 ( 𝑎 ) , 𝜂 = ∃ do ( 𝑐, 𝑃, 𝑄 ) ← 𝑆 ∃ ( 𝑓 ) return ∃ 𝑣. 𝑃 [ 𝑣 / 𝑐, 𝑎 / 𝑥 ] ∧ (∃ 𝑟 .𝑄 [ 𝑣 / 𝑐, 𝑟 / 𝜌, 𝑎 / 𝑥 ]) ∧(∀ 𝑟 .𝑄 [ 𝑣 / 𝑐, 𝑟 / 𝜌, 𝑎 / 𝑥 ] = ⇒ Ψ [ 𝑟 / 𝑦 ]) case 𝑠 ; 𝑠 do Ψ ′ ← StatementVC( 𝑠 , 𝜂, Ψ , 𝑆 ∀ , 𝑆 ∃ ) return StatementVC( 𝑠 , 𝜂, Ψ ′ , 𝑆 ∀ , 𝑆 ∃ ) case if b then 𝑠 𝑡 else 𝑠 𝑓 do Ψ 𝑡 ← StatementVC( 𝑠 𝑡 , 𝜂, Ψ , 𝑆 ∀ , 𝑆 ∃ ) Ψ 𝑓 ← StatementVC( 𝑠 𝑓 , 𝜂, Ψ , 𝑆 ∀ , 𝑆 ∃ ) return ( 𝑏 = ⇒ Ψ 𝑡 ) ∧ (¬ 𝑏 = ⇒ Ψ 𝑓 ) case while b do 𝑠 𝑏 end do 𝑣 ← Vars( 𝑠 𝑏 ) 𝑣 ′ ← Fresh( 𝑣 ) 𝐼 ← Invariant( while b do 𝑠 𝑏 end ) if 𝜂 = ∀ then Ψ 𝑏 ← StatementVC( 𝑠 𝑏 , 𝜂, 𝐼, 𝑆 ∀ , 𝑆 ∃ ) else if 𝜂 = ∃ then 𝑉 ← Variant( while b do 𝑠 𝑏 end ) varDec ← ≤ 𝑉 < 𝑉 [ 𝑣 ′ / 𝑣 ] Ψ ′ ← 𝐼 ∧ varDec Ψ 𝑏 ← StatementVC( 𝑠 𝑏 , 𝜂, Ψ ′ , 𝑆 ∀ , 𝑆 ∃ ) Ψ 𝑙𝑜𝑜𝑝 ← ∀ 𝑣 ′ . ( 𝑏 ∧ 𝐼 = ⇒ Ψ 𝑏 ) [ 𝑣 ′ / 𝑣 ] Ψ 𝑒𝑛𝑑 ← ∀ 𝑣 ′ . (¬ 𝑏 ∧ 𝐼 = ⇒ Ψ ) [ 𝑣 ′ / 𝑣 ] return 𝐼 ∧ Ψ 𝑙𝑜𝑜𝑝 ∧ Ψ 𝑒𝑛𝑑 onference’17, July 2017, Washington, DC, USA Robert Dickerson, Qianchuan Ye, and Benjamin Delaware Algorithm 2:
RhleVC
Inputs : Φ , a relational precondition 𝑝 ∀ , universal programs 𝑝 ∃ , existential programs Ψ , a relational postcondition, 𝑆 ∀ , a universal specification context 𝑆 ∃ , an existential specification context Output : verifiability of h Φ i 𝑝 ∀ ∼ ∃ 𝑝 ∃ h Ψ i beginwhile 𝑝 ∀ ∪ 𝑝 ∃ ≠ ∅ do ( 𝑠, 𝜂, 𝑖 ) ← ChooseStep( 𝑝 ∀ , 𝑝 ∃ , Φ , Ψ ) 𝑝 𝜂, 𝑖 ← 𝑝 𝜂, 𝑖 − 𝑠 Ψ ← StatementVC ( 𝑠, 𝜂, Ψ , 𝑆 ∀ , 𝑆 ∃ ) return Verify( Φ = ⇒ Ψ ) parameter to indicate whether universal or existential logicshould be used.The second component, RhleVC , is shown in Algorithm 2.
RhleVC generates verification conditions for
RHLE triples. Itoperates by applying the
Step rules based on the directionof
ChooseStep and relying on
StatementVC to generate thenext set of verification conditions.
RhleVC terminates whenall statements have been considered, at which point the ac-cumulated verification conditions are discharged by a solverfor the underlying assertion logic.See Appendix D for a full example verification.
To evaluate both
RHLE and the verification procedure fromthe previous section, we address the following questions:(R1) Is
RHLE expressive enough to represent a variety in-teresting properties?(R2) Is our approach effective , that is, can it be used to ver-ify or invalidate relational assertions about a diversecorpus of programs?(R3) Is it possible to realize an efficient implementation ofour verification approaches which return results withina reasonable time frame?To answer these questions, we have developed a suite ofprograms and relational specifications drawn from the lit-erature. We have also compiled an additional set of bench-marks in order to evaluate similar questions about the ex-istential logic from Section 4.2. Both benchmarks contain amix of valid and invalid properties over both single execu-tion existential properties and relational ∀∃ properties.Our benchmarks for the existential logic from Section 4.2fall into two categories: Twenty-one Strategy.
Programs in this category play asimplified game of blackjack. Players start with two cardsvalued between 1 and 10, and can then request any numberof additional cards. The goal is to get a hand value as close to 21 as possible without going over. The property of interestis whether an algorithmic strategy for this game permits the possibility of achieving the maximum hand value of 21 givenany starting hand.
Branching Time Properties.
Our next set of benchmarksare taken from Cook and Koskinen [12], which consideredverification of properties of single programs expressed inCTL. The programs in this category are adaptations of thosebenchmarks that assert the existence of desirable final statesfor a possibly-terminating program.Our second set of benchmarks cover program refinementin addition to the following ∀∃ properties: Noninterference.
Generalized noninterference is a pos-sibilistic information security property which ensures thatnondeterministic programs do not leak knowledge abouthigh-security state via low-security outputs. In other words,an attacker should not be to deduce anything about privatestate based solely on public state. Our formalization of thisproperty is based on McLean [20] and requires that, for anyexecution of a program 𝑝 whose state is divided into highsecurity 𝑝 𝐻 and low security 𝑝 𝐿 partitions, any other start-ing state with the same initial low partition can potentiallyyield the same final low partition. Delimited Release.
It is sometimes desirable to relax anoninterference property to allow for limited informationabout secure state to be released. For example, given a con-fidential list of employee salaries, it may be fine to publicizethe average salary as long as no other salary information isleaked. This is an example of a delimited release , which weformalize as a noninterference property with the additionalprecondition that starting states agree on the values of thereleased information. In this case, the precondition wouldassert the average salary in all executions is equal.
Parameter Usage.
Our parameter usage benchmarks at-tempt to verify that a variable used in a program is semanti-cally meaningful, in that the parameter’s starting value im-pacts the result of the program in some way. We capture thisas the ∀∃ property that every pair of distinct starting valuesof this parameter can produce at least two executions withdifferent results. To evaluate the verification algorithm from Section 5, wehave implemented an automatic program verifier in Haskellcalled
ORHLE . ORHLE uses Z3 as a backend solver to fillthe role of
Verify and programmer-provided annotationsto fill the role of
Variant and
Invariant . The
ChooseStep implementation chooses final statements from the existen-tial executions until there are none remaining, then beginschoosing final statements from the universal executions. HLE Conference’17, July 2017, Washington, DC, USA
Input to
ORHLE consists of a collection of
FunIMP pro-grams, a declaration of how many copies of each programshould be included in the universal and existential contexts,and a collection of function specifications expressed usingthe SMT-LIB2 format. Function specifications can be givenin both universal and existential modes, with existential spec-ifications containing declarations of choice variables. Eachinput listing may be annotated as valid or invalid to cate-gorize the expected verification result; this is only for book-keeping purposes and does not affect the actual verificationmechanics. ?? in the appendix has example ORHLE inputlistings. ORHLE outputs a set of verification conditions alongwith a verification success or failure message. When a prop-erty fails to verify,
ORHLE outputs a falsifying model.
Time (s) Valid Verified
Winning Strategy
DoNothing 0.078 ✗ ✗
DrawOnce 0.087 ✗ ✗
DrawUntil21 0.078 ✓ ✓
Branching Time [12]AFEFP-succeed 0.088 ✓ ✓
AFP-fail 0.078 ✗ ✗
AFP-succeed 0.078 ✓ ✓
AGAFP-fail 0.078 ✗ ✗
AGAFP-succeed 0.112 ✓ ✓
AGEFP-succeed 0.078 ✓ ✓
EFAFP-succeed 0.087 ✓ ✓
EFAGP-succeed 0.037 ✓ ✓
Figure 8.
ORHLE verification results over a set of single-execution properties.To show that
ORHLE is both effective and efficient (R2)-(R3), we have used it to verify and/or invalidate examples ofthe benchmark properties described above. Figures 8 and 9present the results of these experiments. Both the single-execution and relational experiments were done using anIntel Core i7-6700K CPU with 8 4GHz cores. For each bench-mark, the
Time (s) column records the verification time, the
Valid column records the expected result, and the
Verified records the result returned by
ORHLE . ORHLE yielded theexpected verification result in all cases. Verification acrossthese benchmark properties was reasonably fast, with mostverification tasks completing in under 30s. Taken together,these results offer evidence that
ORHLE is both effective andefficient.
Underapproximating Nondeterministic Behaviors.
Re-verse Hoare Logic [13] is a program logic for reasoning aboutreachability over single executions of programs which haveaccess to a nondeterministic binary choice ( ⊔ ) operator. Inthis sense, it is similar to the non-relational existential logicdescribed in Section 4. A Reverse Hoare Logic triple h 𝑃 i 𝑐 h 𝑄 i is valid when, for all states 𝜎 ′ satisfying 𝑄 , there exists a Time (s) Valid VerifiedProgram Refinement
Add3Shuffled 0.087 ✗ ✗
Add3Sorted 0.109 ✓ ✓
ConditionalNonRefinement 0.121 ✗ ✗
ConditionalRefinement 0.095 ✓ ✓
LoopNonRefinement 0.091 ✗ ✗
LoopRefinement 44.834 ✓ ✓
SimpleNonRefinement 0.114 ✗ ✗
SimpleRefinement 0.114 ✓ ✓
Noninterference
Denning1 [14] 0.099 ✓ ✓
Denning2 [14] 0.098 ✗ ✗
NonDetLeak 1.571 ✗ ✗
NonDetLeak2 0.089 ✗ ✗
NonDetNonLeak 0.089 ✓ ✓
NonDetNonLeak2 0.098 ✓ ✓
SimpleLeak 0.084 ✗ ✗
SimpleNonLeak 0.090 ✓ ✓
Smith1 [25] 0.080 ✗ ✗
Delimited Release [23, 24]AvgSalariesNoDR 0.080 ✗ ✗
AvgSalaries 0.084 ✓ ✓
ConditionalLeak 0.083 ✗ ✗
ConditionalNoDR 0.084 ✗ ✗
Conditional 0.084 ✓ ✓
MedianNoDR 0.108 ✗ ✗
Median 0.147 ✓ ✓
ParityFun 0.077 ✓ ✓
ParityNoDR 0.077 ✗ ✗
Parity 0.078 ✓ ✓
Parity2 0.082 ✓ ✓
WalletNoDR 0.082 ✗ ✗
Wallet 0.036 ✓ ✓
Parameter Usage
CompletelyUnused 0.084 ✗ ✗
NonDetUnused 0.110 ✗ ✗
NonDetUsed 0.175 ✓ ✓
SemanticallyUnused 0.079 ✗ ✗
ThreeUsed 0.082 ✓ ✓
Figure 9.
ORHLE verification results over a set of relationalproperties.state 𝜎 satisfying 𝑃 such that 𝜎, 𝑐 ⇓ 𝜎 ′ . The authors alsopresent a forward-reasoning predicate transformer seman-tics given in the form of a weakest postcondition calculus.While Reverse Hoare Logic proves the existence a satisfyingstart state for all satisfying end states ( ∀ 𝜎 ′ ∃ 𝜎 ), our existen-tial logic requires there to exist a satisfying end state for allsatisfying start states ( ∀ 𝜎 ∃ 𝜎 ′ .) Incorrectness Logic [21] is arecent adaptation of Reverse Hoare Logic to a more realisticprogramming language.While Reverse Hoare Logic and Incorrectness Logic bothreason about reachability over single executions, propertiesin these logics are pure underapproximations; every statein a given postcondition must be reachable. In contrast, ourreasoning over existential specifications is underapproximate with respect to the choice variables only . While every validchoice value must correspond to a reachable set of final states, onference’17, July 2017, Washington, DC, USA Robert Dickerson, Qianchuan Ye, and Benjamin Delaware each of these sets are still overapproximate. This feature ofour existential specifications enables a natural integrationwith standard Hoare logics. Prophecy Variables.
Prophecy variables were originallyintroduced by Abadi and Lamport[1] as an analogue to his-tory variables which anticipate the value of a future state.Their original motivation was to establish refinement map-pings between state machines; by augmenting some machine 𝑆 with a collection of history and prophecy variables, un-der certain conditions it is possible to establish a mappingbetween the states of the augmented 𝑆 and some othermachine 𝑆 whose observable behaviors 𝑆 refines. Choicevariables in our existential specifications are reminiscent ofthese prophecy variables in that they capture the requiredvalue of some “future” state, although we use choice vari-ables as part of a program logic rather than to reason aboutrefinement mappings between state machines. Jung et al.[18]incorporate prophecy variables into a separation Hoare logicto reason about nondeterminism in concurrent programs.These prophecy variables are again similar to the choicevariables in our existential specifications in that they reifysome undetermined execution state. Our approach differsin that it uses these variables to perform underapproximatereasoning in a relational setting, and is designed for auto-mated, rather than interactive, verification. Dynamic and Modal Logics.
First-order dynamic logic[22]is a reinterpretation of Hoare logic in first-order, multi-modallogic. Dynamic logic programs are constructed by regularexpression operators extended with operators for, e.g., test-ing and assignment. For a program 𝑝 , the modal operators [ 𝑝 ] and h 𝑝 i capture universal and existential quantificationover program executions. The formula [ 𝑝 ] 𝑄 means that af-ter executing 𝑝 , all end states satisfy 𝑄 , and the dual h 𝑝 i 𝑄 means that after executing 𝑝 , there exists some end statesatisfying 𝑄 . Our universal Hoare triple ⊢ { 𝑃 } 𝑝 { 𝑄 } corre-sponds to 𝑃 = ⇒ [ 𝑝 ] 𝑄 , and our existential Hoare triple ⊢ [ 𝑃 ] 𝑝 [ 𝑄 ] ∃ corresponds to 𝑃 = ⇒ h 𝑝 i 𝑄 . In contrast to RHLE , dynamic logic reasons about properties of single pro-gram executions.There exist several other modal logics which support asimilar style of existential reasoning as our existential logic.Temporal logics like LTL and CTL are popular systems forverifying liveness properties, and variants like HyperLTLand HyperCTL can be used to verify liveness hyperprop-erties [8, 9]. A recent paper by Coenen et al. [11] exam-ines verification and synthesis of computational models us-ing HyperLTL formulas with alternating quantifiers, lead-ing to analysis of the kinds of ∀∃ properties considered here.Cook and Koskinen [12] examines existential reasoning inbranching-time temporal logics by way of removing statespace until universal reasoning methods can be used. Whiletemporal logics are capable of reasoning about the kinds ofliveness properties we consider in this paper, they operate over finite state models of software systems instead of rea-soning directly over program syntax as in our approach. Reasoning about Relational Properties.
The conceptof a hyperproperty was originally introduced by Clarksonand Schneider [10], building off of earlier work by Terauchiand Aiken [27]. Clarkson and Schneider define hyperprop-erties as finite properties over a potentially infinite set ofexecution traces, and demonstrate that every trace hyper-property is an intersection of safety and liveness hyperprop-erties. They further identify the class of 𝑘 -safety hyperprop-erties as those in which the a bad state cannot involve morethan 𝑘 traces. Although not explicitly defined in Clarksonand Schneider [10], the analogous concept of 𝑘 -liveness hy-perproperties is implicit in that work. While they discussverification, they do not offer a verification algorithm.Relational program logics are a common approach to ver-ifying relational specifications. Relational Hoare Logic[7](RHL) was one of the first examples of these logics. Origi-nally developed by Benton, RHL provides an axiomatic sys-tem for proving 2-safety properties of imperative programs.Relational Higher-order Logic[2] is a higher-order relationallogic for reasoning about higher-order functional programsexpressed in a simply-typed 𝜆 -calculus. Probabilistic RHL [6]is a logic for reasoning about probabilistic programs in orderto prove security properties of cryptographic schemes. Therelational logic closest to RHLE is Cartesian Hoare Logic [26](CHL) developed by Sousa and Dillig. This logic which pro-vides an axiomatic system for reasoning about 𝑘 -safety hy-perproperties along with an automatic verification algorithm. RHLE can be thought of as an extension of CHL for reason-ing about the more general class of ∀∃ properties.Product programs are another approach to relational ver-ification, where the relational verification task is reduced toverifying that a product program satisfies a non-relationalproperty[3]. The advantage to this approach is it can lever-age existing non-relational verification tools and techniqueswhen verifying the product program, but the large state spaceof product programs can make verification difficult in prac-tice. Product programs have been used to verify 𝑘 -safetyproperties and reason about noninterference and secure in-formation flow[5, 19]. The most closely related work in thisspace is that of Barthe et al. [4], which develops a set of nec-essary conditions for “left-product programs”. These prod-uct programs can be used to verify hyperproperties outsideof 𝑘 -safety, including our ∀∃ properties, although the workdoes not address how to construct left-product programs. In this paper, we defined a class of relational properties, called ∀∃ properties, which can express a variety of interestingrelations between multiple program executions. As theseproperties assert the existence of desirable executions, theycannot be verified using relational program logics that only HLE Conference’17, July 2017, Washington, DC, USA deal with safety properties. We presented a novel functionspecification technique which enables both overapproximateand underapproximate consideration of programs, in orderto reason about the behavior of client programs under underany valid implementation of a library. We introduced a re-lational program logic called
RHLE which leverages thesespecifications to formally verify ∀∃ properties. We devel-oped an automated verification algorithm based on RHLE ,which we implemented in a novel verification tool called
ORHLE . We have demonstrated that
RHLE is able to expressa variety of interesting relational properties, and providedexperimental evidence that
ORHLE is able to correctly de-cide the validity of ∀∃ properties in a reasonable time frameover a suite of representative programs. References [1] M. Abadi and L. Lamport. 1988. The existence of re-finement mappings. In [1988] Proceedings. Third An-nual Symposium on Logic in Computer Science . 165–175. https://doi.org/10.1109/LICS.1988.5115 [2] Alejandro Aguirre, Gilles Barthe, Marco Gaboardi,Deepak Garg, and Pierre-Yves Strub. 2017. A RelationalLogic for Higher-order Programs.
Proc. ACM Program.Lang.
1, ICFP, Article 21 (Aug. 2017), 29 pages.[3] Gilles Barthe, Juan Manuel Crespo, and César Kunz.2011. Relational Verification Using Product Programs.In
FM 2011: Formal Methods , Michael Butler and Wol-fram Schulte (Eds.). Springer Berlin Heidelberg, Berlin,Heidelberg, 200–214.[4] Gilles Barthe, Juan Manuel Crespo, and César Kunz.2013. Beyond 2-safety: Asymmetric product programsfor relational program verification. In
InternationalSymposium on Logical Foundations of Computer Science .Springer, 29–43.[5] Gilles Barthe, Pedro R. D’Argenio, and Tamara Rezk.2011. Secure information flow by self-composition.
Mathematical Structures in Computer Science
21, 6(2011), 1207–1252.[6] Gilles Barthe, Benjamin Grégoire, and SantiagoZanella Béguelin. 2009. Formal Certification of Code-based Cryptographic Proofs.
SIGPLAN Not.
44, 1 (Jan.2009), 90–101.[7] Nick Benton. 2004. Simple Relational CorrectnessProofs for Static Analyses and Program Transforma-tions. In
Proceedings of the 31st ACM SIGPLAN-SIGACTSymposium on Principles of Programming Languages (Venice, Italy) (POPL ’04) . ACM, New York, NY, USA,14–25.[8] E. Clarke, O. Grumberg, and D. Long. 1994. Verifi-cation tools for finite-state concurrent systems. In
ADecade of Concurrency Reflections and Perspectives , J. W.de Bakker, W. P. de Roever, and G. Rozenberg (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 124–175.[9] Michael R Clarkson, Bernd Finkbeiner, Masoud Koleini,Kristopher K Micinski, Markus N Rabe, and CésarSánchez. 2014. Temporal logics for hyperproperties.In
International Conference on Principles of Security andTrust . Springer, 265–284.[10] Michael R. Clarkson and Fred B. Schneider. 2010. Hy-perproperties.
J. Comput. Secur.
18, 6 (Sept. 2010), 1157–1210.[11] Norine Coenen, Bernd Finkbeiner, CésarSánchez, and Leander Tentrup. 2019. Ver-ifying Hyperliveness. (07 2019), 121–139. https://doi.org/10.1007/978-3-030-25540-4_7 [12] Byron Cook and Eric Koskinen. 2013. Reasoning aboutnondeterminism in programs. In
Proceedings of the 34thACM SIGPLAN conference on Programming languagedesign and implementation . 219–230.[13] Edsko de Vries and Vasileios Koutavas. 2011. ReverseHoare Logic. In
Proceedings of the 9th InternationalConference on Software Engineering and Formal Meth-ods (Montevideo, Uruguay) (SEFM’11) . Springer-Verlag,Berlin, Heidelberg, 155–171.[14] Dorothy E. Denning and Peter J. Denning. 1977.Certification of Programs for Secure InformationFlow.
Commun. ACM
20, 7 (July 1977), 504–513. https://doi.org/10.1145/359636.359712 [15] Edsger W. Dijkstra. 1976.
On non-determinacy beingbounded.
Prentice-Hall, Chapter 9.[16] Edsger W. Dijkstra. 1982.
On Weak and Strong Termi-nation . Springer New York, New York, NY, 355–357. https://doi.org/10.1007/978-1-4612-5695-3_64 [17] J. A. Goguen and J. Meseguer. 1982. Secu-rity Policies and Security Models. In . 11–11. https://doi.org/10.1109/SP.1982.10014 [18] Ralf Jung, Rodolphe Lepigre, Gaurav Parthasarathy,Marianna Rapoport, Amin Timany, Derek Dreyer, andBart Jacobs. 2019. The Future is Ours: ProphecyVariables in Separation Logic.
Proc. ACM Program.Lang.
4, POPL, Article 45 (Dec. 2019), 32 pages. https://doi.org/10.1145/3371113 [19] Máté Kovács, Helmut Seidl, and Bernd Finkbeiner. 2013.Relational abstract interpretation for the verificationof 2-hypersafety properties.
Proceedings of the ACMConference on Computer and Communications Security ,211–222.[20] John McLean. 1996. A General Theory of Com-position for a Class of "Possibilistic" Properties.
IEEE Trans. Softw. Eng.
22, 1 (Jan. 1996), 53–67. https://doi.org/10.1109/32.481534 [21] Peter W. O’Hearn. 2019. Incorrectness Logic.
Proc.ACM Program. Lang.
4, POPL, Article 10 (Dec. 2019),32 pages. https://doi.org/10.1145/3371078 onference’17, July 2017, Washington, DC, USA Robert Dickerson, Qianchuan Ye, and Benjamin Delaware [22] Vaughan R Pratt. 1976. Semantical consideration onfloyd-hoare logic. In . IEEE, 109–121.[23] Aseem Rastogi, Piotr Mardziel, Michael Hicks, andMatthew A Hammer. 2013. Knowledge inference foroptimizing secure multi-party computation. In Proceed-ings of the Eighth ACM SIGPLAN workshop on Program-ming languages and analysis for security . 3–14.[24] Andrei Sabelfeld and Andrew C Myers. 2003. A modelfor delimited information release. In
International Sym-posium on Software Security . Springer, 174–191.[25] Geoffrey Smith. 2007. Principles of Secure InformationFlow Analysis. In
Malware Detection , Mihai Christodor-escu, Somesh Jha, Douglas Maughan, Dawn Song, andCliff Wang (Eds.). Springer US, Boston, MA, 291–307.[26] Marcelo Sousa and Isil Dillig. 2016. Cartesian HoareLogic for Verifying K-safety Properties. In
Proceedingsof the 37th ACM SIGPLAN Conference on ProgrammingLanguage Design and Implementation (Santa Barbara,CA, USA) (PLDI ’16) . ACM, New York, NY, USA, 57–69.[27] Tachio Terauchi and Alex Aiken. 2005. Secure Informa-tion Flow as a Safety Problem. In
Static Analysis , ChrisHankin and Igor Siveroni (Eds.). Springer Berlin Hei-delberg, Berlin, Heidelberg, 352–367.[28] Hongseok Yang. 2007. Relational separation logic.
Theoretical Computer Science https://doi.org/10.1016/j.tcs.2006.12.036
Festschrift forJohn C. Reynolds’s 70th birthday.
A Semantics of
FunIMP
The semantics of
FunIMP is given as a big-step reductionrelation from initial to final states. This relation is parame-terized over an implementation context 𝐼 ∈ N → FD , a par-tial mapping from function names to definitions. FunIMP program states, 𝜎 ∈ V → N , are mappings from variablesto their current value. The reduction relation is also parame-terized over an interpretation used to determine the validityof assertions; we write 𝜎 | = 𝑃 to denote that the assertion 𝑃 holds in state 𝜎 . We condense sequences of repeated ex-pressions in similar way to function arguments, writing thesequence 𝐼 ⊢ 𝜎, 𝑎 ⇓ 𝑣 · · · 𝐼 ⊢ 𝜎, 𝑎 𝑛 ⇓ 𝑣 𝑛 as 𝐼 ⊢ 𝜎, 𝑎 ⇓ 𝑣 and [ 𝑥 ↦→ 𝑣 , . . . , 𝑥 𝑛 ↦→ 𝑣 𝑛 ] as [ 𝑥 ↦→ 𝑣 ] , for example.The evaluation rules of FunIMP are presented in Figure 10.
A.1 Overapproximate Executions Semantics
The big-step operational semantics for overapproximate eval-uation is given in Figure 11. These semantics are nearly iden-tical to the evaluation semantics over concrete implementa-tion contexts given in Figure 10, but is instead parameter-ized over a universal specification context 𝑆 ∀ ∈ N → 𝐹𝐴 and replaces the ECall rule with the
ECall ∀ rule. The latterrule allows a call to a universally specified function to step 𝐼 ⊢ 𝜎, skip ⇓ 𝜎 ESkip 𝜎, 𝑎 ⇓ 𝑣𝐼 ⊢ 𝜎, 𝑥 := 𝑎 ⇓ [ 𝑥 ↦→ 𝑣 ] 𝜎 EAssgn 𝐼 ⊢ 𝜎, 𝑥 :: = havoc ⇓ [ 𝑥 ↦→ 𝑣 ] 𝜎 EHavoc 𝐼 ⊢ 𝜎, 𝑐 ⇓ 𝜎 ′ 𝐼 ⊢ 𝜎 ′ ,𝑐 ⇓ 𝜎 ′′ 𝐼 ⊢ 𝜎, 𝑐 ; 𝑐 ⇓ 𝜎 ′′ ESeq 𝜎, 𝑏 ⇓ true 𝐼 ⊢ 𝜎, 𝑐 ⇓ 𝜎 ′ 𝐼 ⊢ 𝜎, if 𝑏 then 𝑐 else 𝑐 ⇓ 𝜎 ′ ECondT 𝜎, 𝑏 ⇓ ⊥ 𝐼 ⊢ 𝜎, 𝑐 ⇓ 𝜎 ′ 𝐼 ⊢ 𝜎, if 𝑏 then 𝑐 else 𝑐 ⇓ 𝜎 ′ ECondF 𝜎, 𝑏 ⇓ true 𝐼 ⊢ 𝜎, 𝑐 ⇓ 𝜎 ′ 𝐼 ⊢ 𝜎 ′ , while 𝑏 do 𝑐 end ⇓ 𝜎 ′′ 𝐼 ⊢ 𝜎, while 𝑏 do 𝑐 end ⇓ 𝜎 ′′ EWhileT 𝜎, 𝑏 ⇓ false 𝐼 ⊢ 𝜎, while 𝑏 do 𝑐 end ⇓ 𝜎 EWhileF 𝐼 ( 𝑓 ) = def 𝑓 ( 𝑥 ) { 𝑠 ; return 𝑒 } 𝐼 ⊢ 𝜎, 𝑎 ⇓ 𝑣 𝐼 ⊢ [ 𝑥 ↦→ 𝑣 ] , 𝑠 ⇓ 𝜎 ′ 𝐼 ⊢ 𝜎 ′ , 𝑒 ⇓ 𝑟𝐼 ⊢ 𝜎, 𝑦 : = 𝑓 ( 𝑎 ) ⇓ [ 𝑦 ↦→ 𝑟 ] 𝜎 ECall
Figure 10.
Big-step evaluation relation of
FunIMP with aconcrete implementation context.to any state with a return value consistent with the func-tion’s specification.
B Universal Hoare Logic
The universal Hoare logic for
FunIMP is given in Figure 12.
C Proofs
Theorem C.1.
When run under an implementation context 𝐼 that is ∀ -compatible with specification context 𝑆 ∀ with aninitial state 𝜎 , a program 𝑝 will either diverge or evaluate to astate 𝜎 ′ which is also the result of one of its overapproximateexecutions under 𝑆 ∀ : 𝐼 | = ∀ 𝑆 ∀ ∧ 𝐼 ⊢ 𝜎, 𝑝 ⇓ 𝜎 ′ = ⇒ 𝑆 ∀ ⊢ 𝜎, 𝑝 ⇓ ∀ 𝜎 ′ Proof.
By induction over the derivation of 𝐼 ⊢ 𝜎, 𝑝 ⇓ 𝜎 ′ .The only interesting case is ECall , where we must considerwhether 𝜎 meets the precondition of 𝑓 in 𝑆 ∀ . If not, the proofis immediate from ECall ∀ . If so, the proof follows fromthe fact that the definition of 𝑓 in 𝐼 is compatible with itsspecification in 𝑆 ∀ and ECall ∀ . (cid:3) Theorem C.2.
If there is an underapproximate evaluation ofprogram 𝑝 to a set of states Σ from an initial state 𝜎 under 𝑆 ∃ ,then 𝑝 must terminate in at least one final state 𝜎 ′ ∈ Σ from 𝜎 under every implementation context 𝐼 that is ∃ -compatible HLE Conference’17, July 2017, Washington, DC, USA 𝑆 ∀ ⊢ 𝜎, skip ⇓ ∀ 𝜎 ESkip ∀ 𝜎, 𝑎 ⇓ ∀ 𝑣𝑆 ∀ ⊢ 𝜎, 𝑥 := 𝑎 ⇓ ∀ [ 𝑥 ↦→ 𝑣 ] 𝜎 EAssgn ∀ 𝑆 ∀ ⊢ 𝜎, 𝑥 : = havoc ⇓ ∀ [ 𝑥 ↦→ 𝑣 ] 𝜎 EHavoc ∀ 𝑆 ∀ ⊢ 𝜎, 𝑐 ⇓ ∀ 𝜎 ′ 𝑆 ∀ ⊢ 𝜎 ′ , 𝑐 ⇓ ∀ 𝜎 ′′ 𝑆 ∀ ⊢ 𝜎, 𝑐 ; 𝑐 ⇓ ∀ 𝜎 ′′ ESeq ∀ 𝜎, 𝑏 ⇓ ∀ true 𝑆 ∀ ⊢ 𝜎, 𝑐 ⇓ ∀ 𝜎 ′ 𝑆 ∀ ⊢ 𝜎, if 𝑏 then 𝑐 else 𝑐 ⇓ ∀ 𝜎 ′ ECondT ∀ 𝜎, 𝑏 ⇓ ∀ ⊥ 𝑆 ∀ ⊢ 𝜎, 𝑐 ⇓ ∀ 𝜎 ′ 𝑆 ∀ ⊢ 𝜎, if 𝑏 then 𝑐 else 𝑐 ⇓ ∀ 𝜎 ′ ECondF ∀ 𝜎, 𝑏 ⇓ ∀ true 𝑆 ∀ ⊢ 𝜎, 𝑐 ⇓ ∀ 𝜎 ′ 𝑆 ∀ ⊢ 𝜎 ′ , while 𝑏 do 𝑐 end ⇓ ∀ 𝜎 ′′ 𝑆 ∀ ⊢ 𝜎, while 𝑏 do 𝑐 end ⇓ ∀ 𝜎 ′′ EWhileT ∀ 𝜎, 𝑏 ⇓ ∀ false 𝑆 ∀ ⊢ 𝜎, while 𝑏 do 𝑐 end ⇓ ∀ 𝜎 EWhileF ∀ 𝑆 ∀ ( 𝑓 ) = ax ∀ 𝑓 ( 𝑥 ) { 𝑃 } { 𝑄 } 𝑆 ∀ ⊢ 𝜎, 𝑎 ⇓ ∀ 𝑣 [ 𝑥 ↦→ 𝑣 ] | = 𝑃 [ 𝜌 ↦→ 𝑟, 𝑥 ↦→ 𝑣 ] | = 𝑄𝑆 ∀ ⊢ 𝜎, 𝑦 : = 𝑓 ( 𝑎 ) ⇓ ∀ [ 𝑦 ↦→ 𝑟 ] 𝜎 ECall ∀ 𝑆 ∀ ( 𝑓 ) = ax ∀ 𝑓 ( 𝑥 ) { 𝑃 } { 𝑄 } 𝑆 ∀ ⊢ 𝜎, 𝑎 ⇓ ∀ 𝑣 [ 𝑥 ↦→ 𝑣 ] 6| = 𝑃𝑆 ∀ ⊢ 𝜎, 𝑦 : = 𝑓 ( 𝑎 ) ⇓ ∀ [ 𝑦 ↦→ 𝑟 ] 𝜎 ECall ∀ Figure 11.
Overapproximate execution semantics of
Fu-nIMP with a universal specification context. with 𝑆 ∃ : 𝑆 ∃ ⊢ 𝜎, 𝑝 ⇓ ∃ Σ ∧ 𝐼 | = ∃ 𝑆 ∃ = ⇒ ∃ 𝜎 ′ .𝐼 ⊢ 𝜎, 𝑝 ⇓ 𝜎 ′ ∧ 𝜎 ′ ∈ Σ Proof.
By induction over the derivation of 𝑆 ∃ ⊢ 𝜎, 𝑝 ⇓ ∃ Σ .Once again, the interesting case is ECall ∃ , which followsimmediate from the fact that 𝐼 is ∃ -compatible with 𝑆 ∃ . (cid:3) Theorem C.3 (RHLE is Sound) . Suppose 𝑆 ∀ , 𝑆 ∃ ⊢ h Φ i 𝑝 ∀ ∼ ∃ 𝑝 ∃ h Ψ i . Then, for any function context 𝐼 compatible with 𝑆 ∀ and 𝑆 ∃ , any set of initial states 𝜎 ∀ and 𝜎 ∃ satisfying Φ , andevery collection of final states 𝜎 ′∀ of 𝑝 ∀ , there must exist a col-lection of final states produced by 𝑝 ∃ that, together with 𝜎 ′∀ satisfies the relational post-condition Ψ : 𝑆 ∀ , 𝑆 ∃ ⊢ h Φ i 𝑝 ∀ ∼ ∃ 𝑝 ∃ h Ψ i∧∀ 𝐼 . 𝐼 | = 𝑆 ∀ ∧ 𝐼 | = 𝑆 ∃ ∧∀ 𝜎 ∀ 𝜎 ∃ . 𝜎 ∀ , 𝜎 ∃ | = Φ ∧∀ 𝜎 ′∀ . 𝐼 ⊢ 𝜎 ∀ , 𝑝 ∀ ⇓ 𝜎 ′∀ = ⇒∃ 𝜎 ′∃ . 𝐼 ⊢ 𝜎 ∃ , 𝑝 ∃ ⇓ 𝜎 ′∃ ∧ 𝜎 ′∀ , 𝜎 ′∃ | = Ψ Proof.
We first prove a stronger property by induction onthe triple 𝑆 ∀ , 𝑆 ∃ ⊢ h Φ i 𝑝 ∀ ∼ ∃ 𝑝 ∃ h Ψ i : namely, that there exist | = 𝑃 = ⇒ 𝑃 ′ | = 𝑄 ′ = ⇒ 𝑄 𝑆 ∀ ⊢ (cid:8) 𝑃 ′ (cid:9) 𝑐 { 𝑄 ′ } 𝑆 ∀ ⊢ { 𝑃 } 𝑐 { 𝑄 } ∀ Conseq 𝑆 ∀ ⊢ { 𝑃 } skip { 𝑃 } ∀ Skip 𝑆 ∀ ⊢ { 𝑃 [ 𝑎 / 𝑥 ]} 𝑥 := 𝑎 { 𝑃 } ∀ Assgn 𝑆 ∀ ⊢ {∀ 𝑣.𝑃 [ 𝑣 / 𝑥 ]} 𝑥 :: = havoc { 𝑃 } ∀ Havoc 𝑆 ∀ ⊢ { 𝑃 } 𝑐 { 𝑃 ′ } 𝑆 ∀ ⊢ (cid:8) 𝑃 ′ (cid:9) 𝑐 { 𝑄 } 𝑆 ∀ ⊢ { 𝑃 } 𝑐 ; 𝑐 { 𝑄 } ∀ Seq 𝑆 ∀ ⊢ { 𝑃 ∧ 𝑏 } 𝑐 { 𝑄 } 𝑆 ∀ ⊢ { 𝑃 ∧ ¬ 𝑏 } 𝑐 { 𝑄 } 𝑆 ∀ ⊢ { 𝑃 } if 𝑏 then 𝑐 else 𝑐 { 𝑄 } ∀ Cond 𝑆 ∀ ⊢ { 𝑃 ∧ 𝑏 } 𝑐 { 𝑃 } 𝑆 ∀ ⊢ { 𝑃 } while 𝑏 do 𝑐 end { 𝑃 ∧ ¬ 𝑏 } ∀ While 𝑆 ( 𝑓 ) = ax 𝑓 ( 𝑥 ){ 𝑃 }{ 𝑄 } 𝑆 ∀ ⊢ (cid:26) 𝑃 [ 𝑎 / 𝑥 ] ∧ ∀ 𝑣.𝑄 [ 𝑣 / 𝜌 ; 𝑎 / 𝑥 ] = ⇒ 𝑄 [ 𝑣 / 𝑦 ] (cid:27) 𝑦 := 𝑓 ( 𝑎 ) { 𝑄 } ∀ Spec
Figure 12.
Proof rules for a universal Hoare logic for
Fu-nIMP .appropriate existential executions of 𝑝 ∃ for every collectionof final states of 𝑝 ∀ produced by an overapproximate execu-tion, for any set of initial states satisfying the precondition Φ : ∀ 𝜎 ∀ 𝜎 ∃ . 𝜎 ∀ 𝜎 ∃ | = Φ ∧ ∀ 𝜎 ′∀ . 𝑆 ∀ ⊢ 𝜎 ∀ , 𝑝 ∀ ⇓ ∀ 𝜎 ′∀ = ⇒ 𝑆 ∃ ⊢ 𝜎 ∃ , 𝑝 ∃ ⇓ ∃ { 𝜎 ′∃ | 𝜎 ′∀ , 𝜎 ′∃ | = Ψ } (1)By Theorem C.1, the fact that 𝐼 is ∀ -compatible with 𝑆 ∀ , andour assumption that 𝐼 ⊢ 𝜎 ∀ , 𝑝 ∀ ⇓ 𝜎 ′∀ , it follows that: 𝑆 ∀ ⊢ 𝜎 ∀ , 𝑝 ∀ ⇓ ∀ 𝜎 ′∀ (2)Armed with (1) and (2) and the assumption that 𝐼 is ∃ -compatiblewith 𝑆 ∃ , by Theorem C.2 we can conclude the desired result,i.e. ∃ 𝜎 ′∃ . 𝐼 ⊢ 𝜎 ∃ , 𝑝 ∃ ⇓ 𝜎 ′∃ ∧ 𝜎 ′∀ , 𝜎 ′∃ | = Ψ . (cid:3) D Example Verification
To illustrate the operation of the verification algorithm inSection 5, consider the following relational property whichencodes a simple program refinement: h⊤i 𝑥 := RandB ( ) ∼ ∃ 𝑥 := RandB ( ) h 𝑥 = 𝑥 i Assume
RandB has the following specifications: 𝑆 ∀ ( RandB ) = ax ∀ RandB ( 𝑛 ){⊤}{ ≤ 𝜌 < 𝑛 } 𝑆 ∃ ( RandB ) = ax ∃ RandB ( 𝑛 ){ 𝑐 }{ ≤ 𝑐 < 𝑛 }{ 𝜌 = 𝑐 } onference’17, July 2017, Washington, DC, USA Robert Dickerson, Qianchuan Ye, and Benjamin Delaware Verification begins by calling
RhleVC with these specifica-tion environments and: Φ : ⊤ Ψ : 𝑥 = 𝑥 𝑝 ∀ : [ 𝑥 := RandB ( )] 𝑝 ∃ : [ 𝑥 := RandB ( )] Since there are programs remaining, the verifier calls
Choos-eStep which yields: ( 𝑥 := RandB ( ) , ∃ , ) The selected program statement 𝑥 := RandB ( ) is then givento StatementVC , which matches as a function call with 𝜂 = ∃ . According to the existential spec, ( 𝑐, 𝑃, 𝑄 ) here is ( 𝑐, ≤ 𝑐 < 𝑛, 𝜌 = 𝑐 ) , and so StatementVC returns: ∃ 𝑣. ≤ 𝑣 < ∧ (∃ 𝑟 . 𝑟 = 𝑣 ) ∧ (∀ 𝑟 . 𝑟 = 𝑣 = ⇒ 𝑥 = 𝑣 ) Here, 𝑣 is the value of the choice variable 𝑐 we must ensureexists. Note that by leaving variables from other executionsfree in the postcondition Ψ given to StatementVC , substi-tution over variables in the execution currently being con-sidered modifies the relational postcondition in the desiredway. Eliding the trivial inhabitation clause for brevity, thenext recursive invocation of
RhleVC is made with: Φ : ⊤ Ψ : ∃ 𝑣. ≤ 𝑣 < ∧ (∀ 𝑟 . 𝑟 = 𝑣 = ⇒ 𝑥 = 𝑣 ) 𝑃 ∀ : [ 𝑥 := RandB ( )] 𝑃 ∃ : nil At this point,
ChooseStep will pick the only remaining pro-gram statement, 𝑥 := RandB ( ) . StatementVC again matchesthis as a function call, but this time with 𝜂 = ∀ . In the univer-sal context, RandB ’s specification is (⊤ , ≤ 𝜌 < 𝑛 ) , whichyields a StatementVC return value of ⊤ ∧ (∀ 𝑟 . ≤ 𝑟 < = ⇒ Ψ [ 𝑟 / 𝑥 ]) for the value of Ψ listed above. RhleVC then recurs oncemore with: Φ : ⊤ Ψ : ∀ 𝑟 . 𝑟 < = ⇒(∃ 𝑣. ≤ 𝑣 < ∧ (∀ 𝑟 . 𝑟 = 𝑣 = ⇒ 𝑟 = 𝑣 )) 𝑃 ∀ : nil 𝑃 ∃ : nil Since 𝑃 ∀ = 𝑃 ∃ = nil , RhleVC terminates by handing Φ = ⇒ Ψ off to the underlying assertion logic’s decision procedure.In this case, 𝑣 can always be instantiated with 𝑟 , and so theproperty verifies. E Example ORHLE Input
The following listing verifies a noninterference property, namelythat the program never leaks any information about the vari-able high . Note that the underapproximation of flipCoinis required. If linked to a flipCoin implementation that al-ways returns 0, for example, attackers could always knowwhether or not the initial value of low was less than high byobserving low . expected : valid; forall : run[1]; exists : run[2]; pre : (= run!1!low run!2!low); post : (= run!1!low run!2!low); aspecs :flipCoin() { pre : true; post : (or (= ret ! 0) (= ret ! 1));} especs :flipCoin() {templateVars: n; pre : (or (= n 0) (= n 1)); post : (= ret ! n);} prog run(high, low): if (low < high) then low := 0; else low := 1; end flip := call flipCoin(); if (flip == 0) then low := 1 − low; elseskip ; endendp HLE Conference’17, July 2017, Washington, DC, USA
Conversely,
ORHLE identifies a violation of noninterfer-ence in the listing below. The program might leak the valueof high , depending on the outcome of flipCoin . expected : invalid; forall : run[1]; exists : run[2]; pre : (= run!1!low run!2!low); post : (= run!1!low run!2!low); aspecs :flipCoin() { pre : true; post : (or (= ret ! 0) (= ret ! 1));} especs :flipCoin() {templateVars: n; pre : (or (= n 0) (= n 1)); post : (= ret ! n);} prog run(high, low):flip := call flipCoin(); if (flip == 0) then low := high + low; elseskip ; endendpendendp