arXiv:2003.12819v3 [cs.PL] 9 Feb 2021 ihpeietp noain ilas yecekadrnt run and type-check also will annotations type precise with r endb h oio opeev yesft truntime. at safety type preserve the to label of monitor flow interpretation the principled by a refined AGT, are In [9]. systems type securi (unnecessary) providing of burden programmers’ the en h e fpsil aesfrdnmclylbldpro labeled betwee dynamically tension for the labels of possible cause of root set the the identify refine to aim We [13]). euiypoet 1] hndaigwt ual referenc mutable with dealing when [10], property security rda yigsc sthe as such typing gradual o ye 6;hwvr thst ieu h yai rda g gradual dynamic the up give to has it however, [6]; types flow sasnl ae trnie[] 5.Rcn okb ooe al et Toro by work Recent [5]. [4], runtime at label single a as yeerr rrniefiue.Ruhy h rda guara gradual the Roughly, failures. runtime or errors type o nomto o yesses sscrt noain h an annotations security type as specifying systems, not type for flow information punished for not are programmers that oescr.Ltr LG 4 n JS[]icue h dynam the included [5] LJGS and [4] ML-GS Later, secure. more ae osrit nLG.Tednmclbli instantiate is label Progra dynamic program. The the LJGS. of in parts constraints typed label dynamically the on checks rgaswt yaial-ye rgas tahigh-level a At programs. as dynamically-typed with i programs complex dynamically-type use and to untyped unwilling in be written may is and infrastructure with statically unfamiliar purely are However, mers [1]. compile-time at attackers ytmefre yesft nsaial ye at n th and parts typed statically on safety type enforces system nta,teporme ol nettp at,wihaec are Di which instance, casts, type For insert types”. would “gradual programmer adopti treat the Earlier Instead, to types. approaches flow hoc information ad gradual of semantics ? ewe at ye as typed parts between adaetpda,e.g., as, typed are (and acae l eeoe h btatn rda yig(AGT typing gradual abstracting the developed al. et Garcia nti ae,w eeaietecneto ewe gradual between connection the re-examine we paper, this In ttesm ie neet ntefra onain fgrad of foundations formal the in interests time, same the At nomto o yessescmietpsadscrt lab security and types combine systems type flow Information rda yigi n rmsn ehiu oadesteec these address to technique promising one is typing Gradual rda yighsbe ple oifrainflwtps[3] types flow information to applied been has typing Gradual ? is-re rda nomto lwTpswith Types Flow Information Gradual First-order oacmoaeutpdprin fteporm h yesy type The program. the of portions untyped accommodate to , ie oee,te eur rcs yeanttos maki annotations, type precise require they However, time. ro ehiu eeoe o lwLadrdc noninterf reduce and FlowML guarantees for tha developed gradual types technique the flow proof between information a gradual tension with the language of imperative cause root the s informat precise to informat less applied gradual that errors. property on been guarantee—the work has gradual Prior and dynamic types. security approaches, gradual both Grad from languages. of dynamically-typed best or the untyped in written is nomto o yessesefretescrt property security the enforce systems type flow Information hspprr-xmnstecneto ewe rda info gradual between connection the re-examines paper This ? stesto l osbelbl.Erywr ngaulinfor gradual on work Early labels. possible all of set the is ? n ttclytpdprst nuetp preservation. type ensure to parts typed statically and int rda guarantee gradual ? ,wihi eemnda utm.Ifrainflwmonitors flow Information runtime. at determined is which ), bihkBchwt cen caladLmnJia Limin and McCall McKenna Bichhawat, Abhishek { bchw cenk liminjia mckennak, abichhaw, angeMlo University Mellon Carnegie rda Guarantees Gradual 8 eeitoue,wihsy htloeigplce sho policies loosening that says which introduced, were [8] .I I. tpdlnugsfc infiataoto hlegs Mos challenges. adoption significant face languages -typed NTRODUCTION agae ihu rcs euiytp annotations. type security precise without languages d gte ifiutt s npatc smc ftelgc infra legacy the of much as practice in use to difficult them ng utm eatc fgaultp ytm oio h inte the monitor systems type gradual of semantics runtime e teesrsta rgaswihtp-hc n u ocompl to run and type-check which programs that ensures ntee a yigsalsl nertssai n yai typing dynamic and static integrates seamlessly typing ual crt yeanttosi rga hudntcuemr r more cause not should program a in annotations type ecurity sasnl euiylbla u iei ohM-SadLJGS. and ML-GS both in time run at label security single a as d Abstract o o yigucvrdtnin ewe noninterference between tensions uncovered typing flow ion rvdsbt oitreec n rda urnes We guarantees. gradual and noninterference both provides t es. v enara lc o dpin ihu h rda guara gradual the Without adoption. for block road a been ave yanttosi increased. is annotations ty opeinwt espeietps i.e., types, precise less with completion o yai yei hti ersnstesto l osbetyp possible all of set the represents it that is type dynamic ekda utm,adaeue o“rdal”mk h progr the make “gradually” to used are and runtime, at hecked n fgaultpn oifrainflwtpshv develope have types flow information to typing gradual of ons rm trnie oti n,w ou nasml imperative simple a on focus we end, this To runtime. at grams nyadFaaa i o nld yai euiylbl[3 label security dynamic a include not did Flanagan and sney rda yessesitoueadnmctp,otnwritt often type, dynamic a introduce systems type gradual , fnnnefrneb eetn nuhrzddt osa c at flows data unauthorized detecting by noninterference of rnepof opeevto proofs. preservation to proofs erence yta nepeain h eatc ftednmcinform dynamic the of semantics the interpretation, that By n oitreec.W eeo utm eatc o sim a for semantics runtime develop We noninterference. and 1 oain ftepormi ae uhagaatei importa is guarantee a Such safe. is program the if notations nomto o ye n nomto o oios(..[1 (c.f. monitors flow information and types flow information mr tl edt rt noain n at nM-Sand ML-GS in casts and annotations write to need still mmers rmwr hc rvdsafra nepeaino gradu of interpretation formal a provides which framework ) o o oto,weeifrainflwmntr r derived are monitors flow information where control, flow ion h yai rda urne n euiyi ytm that systems in security and guarantee gradual dynamic the n aatei ao of favor in uarantee mto o ye n nomto o oiost identify to monitors flow information and types flow rmation [] hr eti xrsin aeadnmcscrt lab security dynamic a have expressions certain where –[7], ., alne 2;i ist emesyitgaestatically- integrate seamlessly to aims it [2]; hallenges frainflwtp ytm.Mroe,mc ftelegacy the of much Moreover, systems. type flow nformation l oesr htwl-ye rgasd o ekscesto secrets leak not do programs well-typed that ensure to els GSL a ye rwsgicnl.Fra rprisrltdto related properties Formal significantly. grew types ual cscrt label security ic itbrh USA Pittsburgh, , tmalw n rga ob ye under typed be to program any allows stem } @andrew.cmu.edu Ref ainflwtpn l ntnit h yai label dynamic the instantiate all typing flow mation ist pl h G rmwr oinformation to framework AGT the apply to aims , noninterference ? n utm oio htperformed that monitor runtime a and r hndrvdfo h runtime the from derived then are h e nomto flow information key the , ? hspoet ensures property This . l o as more cause not uld providing , structure leverage ompile- ? n the and untime program- t h type The . ractions ple sthat es typed etion ation ntee, ams 1]– en nt el al ]. d language with first-order stores, which has been widely used to design information flow control systems [1], [13]–[17]. While simple, this language includes all the features to illustrate the problem of refining dynamic labels at runtime. We develop runtime semantics for this language with gradual information flow types that enjoy both noninterference and the dynamic gradual guarantee. We draw ideas from abstracting gradual typing, which advocates deriving runtime semantics for gradual types via the preservation proof [9]. We observe that as dynamic labels are updated, the semantics that only gradually refine the possible security labels during program execution resemble a naive flow-sensitive monitor and therefore inherit the problems with implicit leaks of flow- sensitive monitors [11]. To enforce noninterference and remove the implicit leaks caused by insecure writes in branches, the runtime semantics needs to take into consideration the variable and channel writes in the untaken branch [13]. Pure guessing which ignores information about the untaken branch like GSLRef ’s runtime yields rigid semantics that break the gradual guarantee (more in Section III-D). The no-sensitive-upgrade (NSU) check [11] also doesn’t solve the problem. Instead, a “hybrid” approach [13], [17] that leverages static analysis to obtain the write effects of the untaken branch and upgrade relevant references for both branches can be used to remove the implicit leaks and provide the gradual guarantees. We leverage a proof technique developed for FlowML, which reduces noninterference proofs to preservation proofs [18]. The main idea is to extend the language with pairs of expressions and commands, representing two executions with different secrets in one program. Noninterference follows from preservation. This proof technique clearly illustrates the problem with purely dynamic flow-sensitive monitors and naturally suggests the hybrid approach [13], [17]. To summarize, we study the connection between gradual security types and information flow monitors and identify the conservative handling of implicit flows in GSLRef as the reason that it gives up dynamic gradual guarantee in favor of noninterference. Additionally, we show that the dynamic gradual guarantee can be recovered by using a hybrid approach that leverages the static phase to generate a list of variables that are written to in both the branches. Due to space constraints, we omit detailed definitions and proofs, which can be found in the full version of the paper [19].

II. OVERVIEW OF INFORMATION FLOW CONTROL In information flow control systems, variables are annotated with a label from a security lattice, which have a partial-ordering (4) and a well-defined join and meet operation. ℓ1 4 ℓ2 means information can flow from ℓ1 to ℓ2. Consider a two-point security lattice with labels {L,H} with L 4 H where L represents public and H represents secret. A variable x having type intH contains a sensitive integer value. Information flows can be broadly classified as explicit or implicit [10], [20]. Explicit flows arise from variable assignments. For instance, the statement x = y + z causes an explicit flow of values from y and z to x. Implicit flows arise from control structures in the program. For example, in the program l = false; if(h){l = true; }, there is an implicit flow of information from h to the final value of l (it is true iff h is true). Implicit flows are handled by maintaining a pc (program-context) label, which is an upper bound on the labels of all the predicates that have influenced the control flow thus far. In the example, the pc inside the branch is the label of h. Information flow control systems aim to prevent leaks through these flows by either enforcing information flow typing rules and ruling out insecure programs at compile-time or dynamically monitoring programs and aborting the execution of insecure programs. In both systems, assignment to a variable is disallowed if either the pc label or the join of the label of the operands is not less than or equal to the label of the variable being assigned [1], [11]. Thus, in the above examples, if either the label of y or z is greater than the label of x or the label of h is greater than the label of l, the assignment does not type-check or the execution aborts at runtime. This guarantees a variant of noninterference, known as termination-insensitive noninterference [1], which we prove for our gradual type system. We assume that an adversary cannot observe or gain any information if a program’s execution diverges or aborts and can only observe “public” outputs by the program. We consider a flow-insensitive, fixed-label system in this paper and prove termination-insensitive noninterference for it.

III. GRADUAL SECURITY TYPING Static information flow type systems do not scale up to scenarios where the security levels of some of the variables are not known at compile-time, while pure monitoring approaches cannot reject obviously insecure programs at compile-time. Gradual typing extends the reach of type-system based analysis by adding an imprecise (or dynamic) label, ?, for variables whose labels are not known at compile-time. The runtime semantics then ensures that no information is leaked due to the relaxation of the type-system’s handling of ? labels.

A. Imprecise Security Label: Interpretations and Operations The label ? is not an actual element of the security lattice and its meaning is not universally agreed upon. Differences will manifest in the runtime monitoring semantics and proof of noninterference. For illustration, consider a variable x of type int?. Semantically, in the literature ? has meant one of the following. (1) x’s label is dynamic (flow-sensitive) and can change at runtime (e.g., from ? representing L to representing H when x is assigned a secret). (2) the set of possible labels for x is refined at runtime and the set in a future state will be a subset of its the current state. Since we build on a flow-insensitive

2 H ? 1 y := false 1 y := false H ? 2 if (x) then y := true 2 if (x) then y := true Listing 1: Statically typed Listing 2: Dynamically typed

? ? 1 y := false 1 y := true L L 2 z := false 2 z := true ? ? 3 if (x) then y := true 3 if (x) then y := false L L 4 if (y) then z := true 4 if (y) then z := false 5 output(L, z) 5 output(L, z) Listing 3: NSU Listing 4: Implicit flows

type system, we opt for the second meaning of ?. Our runtime monitor will keep track of the set of possible labels for x. Note that a typical flow-sensitive IFC monitor (e.g. [11], [13]) takes an approach aligned with (1). In the initial program state, ? could be interpreted as: (1) x could contain a secret or be observable to an adversary. Therefore, we should treat x conservatively as if it is both secret and public. (2) ? indicates indifference; the data x contains in the initial state is of no security value; otherwise, x should have been given the label H. We choose (2) again, as it is a cleaner interpretation. Note that this is only for the initial state. At runtime, the monitor maintains enough state to concretely know whether x contains a secret or not.

B. Gradually Refined Security Policy via Examples Next, we describe how security labels can be gradually refined at runtime. Consider the program in Listing 1 and its variant with dynamic types in Listing 2. Suppose the lattice contains four elements {⊥,L,H, ⊤} such that ⊥ 4 L 4 H 4 ⊤. Assume that the initial type of x is boolH in both examples while the type of y is boolH in Listing 1 and bool? in Listing 21. The program in Listing 1 does not leak any information. With gradual typing, its variant in Listing 2 is also accepted by the type system. The runtime refines the set of possible labels for y as the program runs. With x : boolH , y cannot be ⊥ or L as that would result in an implicit flow. Thus, the possible labels of y are refined to the set {H, ⊤} when x = true. If, suppose, x : boolL, then y is labeled {L,H, ⊤} after executing line 2. Suppose the program in Listing 2 is extended with another branch as shown in Listing 3 with z : boolL. When x : boolL, the possible labels for y on line 4 are {L,H, ⊤}. This allows the assignment on line 4 to succeed as the assignment is to a variable that has a label contained in the set of possible pc labels. When x has the type boolH , then the possible labels for y on line 4 are {H, ⊤}. The assignment on line 4 is aborted as L is not equal or higher than any of the possible pc labels ({H, ⊤}). In this case, the monitor enforces NSU and prevents the implicit leak.

C. Gradual Guarantees Desirable formal properties for gradual type systems are the gradual guarantees, proposed by [8]. The gradual guarantees relate programs that differ only in the precision of the type annotations. They state that changes that make the annotations of a gradually typed program less precise should not change the static or dynamic behavior of the program. In other words, if a program with more precise type annotations is well-typed in the static type system, and terminates in the runtime semantics, then the same program with less precise terms is also well-typed, and terminates, respectively. For illustration, consider the previous example from Listing 1. Assume that the program is well-typed under a gradual type system with x : boolH and y : boolH as secret variables. When x is true, the branch on line 2 is taken and y is assigned the value true and has the label H. When x is false, y remains false. This program is accepted by the security type system and dynamic information flow monitor, and runs to completion in all possible executions. As per the static gradual guarantee, the program should also be well-typed if, for instance, y had an imprecise ? security level as shown in Listing 2. By the dynamic gradual guarantee, the program in Listing 2 should run to completion at runtime, even with the imprecise label for y in all executions of the program. The gradual guarantees are important in the context of information flow systems to show that the gradual security type system is strictly more permissive than the static security type system and the dynamic IFC monitor, while providing the same guarantees. They mean that programmers need not worry about insufficient annotations causing their safe programs to be rejected by the type system, or worse, at runtime, which may lead to undesirable behavior. Concerning programmers with unnecessary annotations defeats the purpose of gradual typing, which is meant to alleviate the burden of annotation.

1We will write xℓ to indicate that variable x has the type τ ℓ.

3 ? 1 y := true ? 2 if (x) then y := false 3 output(H, y) Listing 5: Secure program violating gradual guarantee

D. Implicit Flows vs. Dynamic Gradual Guarantee The example in Listing 4 illustrates how gradual typing semantics handle implicit flows. Assume that x : boolH is a secret variable while the security types of y : bool? and z : bool? are unknown at compile-time, and the security lattice is ⊥ 4 L 4 H 4 ⊤. Consider two runs of the program with different initial values of x. When x is true, the branch on line 3 is taken and y is assigned the value false. With gradual typing, the labels of y are refined to {H, ⊤}. As y is false, the branch on line 4 is not taken and z remains true with the set of labels {⊥,L,H, ⊤}. As z’s value is visible at L, the output on line 5 succeeds. When x is false, the branch on line 3 is not taken and y remains true with the set of labels {⊥,L,H, ⊤}. As the pc on line 4 contains the set of labels {⊥,L,H, ⊤}, the assignment on line 4 succeeds, and z becomes false while the set of labels remains {⊥,L,H, ⊤}. Again, as z’s value is visible at L, the output on line 5 succeeds. Thus, in the two runs of the program, different values of z are output for different values of x, thereby leaking x to the adversary at level L. Here, the NSU mechanism does not apply, as the assignment to y on line 3 is merely refining, not “upgrading”, the label of y. If y’s label had been L, this program would have been rejected. This program can be rejected by deploying a special monitoring rule that preemptively aborts an assignment statement if there is a possibility that the pc is not lower than or equal to the variable’s label, as deployed by GSLRef [6]. In the above example, the assignment on line 3 will be aborted, because the pc is H, and y’s label could be ⊥ or L, which might leak information. This ensures noninterference, but unfortunately, the extra check does not retain the dynamic gradual guarantee. That is, enlarging the set of possible labels for the dynamic security type of y will cause the monitor to abort, which contradicts the dynamic gradual guarantee. Consider the program in Listing 5 with the same security lattice as before such that the variable x is labeled H and y’s label is not specified at compile-time. As the pc on line 2 is H and the possible set of labels of y on line 2 is {⊥,L,H, ⊤}, the monitor aborts the execution of the program when x is true to satisfy noninterference. However, if y was labeled H or ⊤ at compile-time instead of being ?, the execution would have proceeded and output the value of y to H. In other words, the larger set of possible labels for y on line 2 (because of the unknown label) causes the monitor to abort while the precisely typed version of the program with y : boolH is accepted by the monitor, which violates the dynamic gradual guarantee. To tackle this problem, we leverage the static phase of the gradual type system to determine the set of variables being written to in different branches and loops, and refine their possible security labels to implement a monitoring strategy that preserves the dynamic gradual guarantee. At the branch on line 2 in Listing 5, we know that y may be written to inside the branch, therefore, we narrow the possibility of the labels for y to {H, ⊤} as the first step of executing the if statement, regardless of whether x is true or false. This is very similar to how hybrid monitors stop implicit leaks [13], [17], [21], [22]. We will discuss this further in Section IV-C.

IV. ALANGUAGE WITH GRADUAL SECURITY TYPES

Labels ℓ ::= L | ... | H Raw values u ::= n | true | false Values v ::= ug Types τ ::= bool | int Gradual labels g ::= ? | ℓ Gradual types U ::= τ g Typing Context Γ ::= · | Γ, x : U

g Expressions e ::= x | v | e1 bop e2 | e :: τ Commands c ::= skip | c1; c2 | x := e | output(ℓ,e) | if e then c1 else c2 | while e do c Fig. 1: Syntax for the language WHILEG

G The syntax and typing rules for the language with gradual security types (WHILE ) are standard as shown in Fig. 1 and Fig. 3. The partial-ordering (4) and join operation (g) on security labels (ℓ) extends to consistent ordering (4 c) and consistent-join g1 g2 (gc) to account for ?, as shown in Fig. 2. The consistent subtyping relation is written as τ ≤ c τ .

4 ℓ1 4 ℓ2 g1 4 c g2 g1 g2 ℓ1 4 c ℓ2 ? 4 c g g 4 c? τ ≤ c τ g 6= ⊤ g 6= ⊤

ℓ1 gc ℓ2 = ℓ1 g ℓ2 ? gc g = ? g gc ? = ? ? gc ⊤ = ⊤ ⊤ gc ?= ⊤

Fig. 2: Operations on gradual labels and types

Γ ⊢ e : U ′ ′ Γ ⊢ e : U U ≤ c U BOOL INT VAR CAST Γ ⊢ bg : boolg Γ ⊢ ng : intg Γ ⊢ x : Γ(x) Γ ⊢ e :: U : U

gi ∀i ∈{1, 2}, Γ ⊢ ei : τ g = g1 gc g2 g BOP Γ ⊢ e1 bop e2 : τ

Γ; gpc ⊢ c

′ g g ′ Γ; gpc ⊢ c1 Γ; gpc ⊢ c2 Γ ⊢ x : τ Γ ⊢ e : τ gpc 4 c g g 4 c g SKIP SEQ ASSIGN Γ; gpc ⊢ skip Γ; gpc ⊢ c1; c2 Γ; gpc ⊢ x := e

Γ ⊢ e : τ g Γ ⊢ e : boolg Γ ⊢ e : boolg g 4 c ℓ gpc 4 c ℓ Γ; gpc gc g ⊢ c Γ; gpc gc g ⊢ c1 Γ; gpc gc g ⊢ c2 OUT WHILE IF Γ; gpc ⊢ output(ℓ,e) Γ; gpc ⊢ while e do c Γ; gpc ⊢ if e then c1 else c2

Fig. 3: Typing rules for WHILEG

G Next, we present the syntax and typing rules for our language with gradual information flow types and evidence (WHILEEvd), G G define the translation from WHILE to WHILEEvd, and explain the operational semantics for our monitor.

G A. WHILEEvd G The syntax of WHILEEvd is shown in Fig. 4. Gradual types, U, consist of a type (bool, or int) and a gradual security label, g. This label is either a static security label, denoted ℓ; or an imprecise dynamic label, denoted ?. As is standard, ℓ is drawn from Labs, a set of labels, which is a part of a security lattice L = (Labs, 4). Here 4 is a partial order between labels in Labs. We commonly use the label H to indicate secret, L to indicate public data, and L 4 H. Recall that examples in Section III-A use a set of possible security labels for preventing information leaks. This is evidence attesting to the validity of gradual labels. We use an interval of labels, representing the lowest and the highest possible label, as the refinement only narrows the interval, similar to GSLRef [6]. There are two types of evidence: a label-interval, ι, that justifies the dynamic label ?; and a pair of intervals or the cast evidence, E=(ι1, ι2), that justifies the consistent subtyping relation between two gradual types used in casts. Intuitively, ι represents the range of possible static labels that would allow the program to type-check. For static labels ℓ, the evidence is [ℓ,ℓ]. An interval [ℓl,ℓr] is valid iff ℓl 4 ℓr. The rest of the paper only considers valid intervals. Operations leading to an invalid interval are aborted. G A value in WHILEEvd is a raw value with an interval of possible security labels for the gradual label. Raw values are integer constants n, or boolean values. Expressions include values, variables, casts, and binary operations on expressions. An explicit type cast is written Eg e, where E is the evidence justifying the type cast and g is the label of the resulting type. Commands include skip, sequencing, assignments, branches, loops, and outputs. This language does not have higher-order stores, so the left-hand side of the assignment is always a global variable. The output command outputs a value at a fixed security label ℓ. We include this command mainly to have a clear statement of the system’s observable behavior, so we do not allow output at the imprecise label ?. To prevent implicit leaks, we include a write-set of variables, X, which takes into account variable writes in both conditional branches and the loop body. Label-interval operations: We first define functions and operations on the label-intervals that are used by the typing rules and operational semantics (shown in Fig. 5). The function γ(g) returns the maximum possible label-interval for the gradual label g, assuming ⊥ and ⊤ are the least and the greatest element in the lattice, respectively. Label-intervals form a lattice with the partial ordering defined as ι1 ⊑ ι2. Here, ι1 is said to be more precise than ι2. The label-intervals are refined throughout the execution of the program; i.e., they get more precise. Consider the example in Listing 3. Assume that the security lattice

5 Labels ℓ ::= L | . . . | H Label-intervals ι ::= [ℓlow,ℓhigh] Raw values u ::= n | true | false Values v ::= (ι u)g Types τ ::= bool | int Gradual labels g ::= ? | ℓ Gradual types U ::= τ g Typing Context Γ ::= · | Γ,x : U Cast evidence E ::= (ι1, ι2) g Expressions e ::= x | v | e1 bop e2 | E e Variable Set X ::= {x1,...,xn} Commands c ::= skip | c1; c2 | x := e | output(ℓ,e) X X | if e then c1 else c2 | while e do c G Fig. 4: Syntax for the language WHILEEvd

′ ′ ′ ℓl 4 ℓr ℓ2 4 ℓ1 ℓ1 4 ℓ2 ℓ1 4 ℓ2 ′ ′ ′ ′ γ(?) = [⊥, ⊤] γ(ℓ) = [ℓ,ℓ] valid([ℓl,ℓr]) [ℓ1,ℓ1] ⊑ [ℓ2,ℓ2] [ℓ1,ℓ1] 4 [ℓ2,ℓ2]

ℓ1l 4 ℓ1r f ℓ2r ℓ2l g ℓ1l 4 ℓ2r (ℓ1l 64 ℓ1r f ℓ2r) ∨ (ℓ2l g ℓ1l 64 ℓ2r)

refine([ℓ1l,ℓ1r], [ℓ2l,ℓ2r]) = ([ℓ1l,ℓ1r f ℓ2r], [ℓ2l g ℓ1l,ℓ2r]) refine([ℓ1l,ℓ1r], [ℓ2l,ℓ2r]) = undef

′ ′ ι1 = [ℓ1,ℓ1] ι2 = [ℓ2,ℓ2] ι1 ⊑ γ(g1) ι2 ⊑ γ(g2) g1 4 c g2 ′ ′ g1 g2 ι1 g ι2 = [ℓ1 g ℓ2,ℓ1 g ℓ2] (ι1, ι2) ⊢ τ ≤ c τ ′′ ′ ′′ ′ ′ ι1 = [ℓ1l,ℓ1r] ι2 = [ℓ2l,ℓ2r] ι =(ι ⊲⊳ ι) ι ⊑ γ(g) refine(ι1 ⊲⊳ ι, ι2)=(ι1, ι2) refine(ι1 ⊲⊳ ι, ι2)= undef ′ g ′′ g ′ ι1 ⊲⊳ ι2 = [ℓ1l g ℓ2l,ℓ1r f ℓ2r] ι ⊲⊳ (ι u) =(ι u) ι ⊲⊳ (ι1, ι2)= ι2 ι ⊲⊳ (ι1, ι2)= undef

Fig. 5: Label and label-interval operations contains two elements L and H such that L 4 H. Initially, y has a label ? with the evidence [L,H] indicating that any of the two labels are possible. If x : boolH , then the only possible label for y that allows assignment on line 3 is H. Thus, the evidence for the label on y is refined to [H,H], which makes the program-context’s evidence on line 4 [H,H], disallowing assignments to L-labeled variables. We define ι1 4 ι2 to mean for every security label in ι1, all labels in ι2 are at higher or equal positions in the security lattice; and for every security label in ι2, all labels in ι1 are at lower or equal positions in the security lattice. Even though this relation is not used in our typing rules or operational semantics, it is an invariant that must hold on the results of the binary label-interval operations used by the noninterference proofs. The function refine(ι1, ι2) returns the largest sub-intervals of ι1 ′ ′ ′ ′ ′ ′ undef and ι2 (ι1 and ι2, respectively) such that ι1 4 ι2. If the relation does not hold between ι1 and ι2, the function returns . The join of label-intervals is defined as ι1 g ι2. Note that this is not to be confused with the join operation in the lattice that the intervals form. The join of the label-intervals computes the interval corresponding to all possible joins of security labels in those intervals. ′ g ι1 ⊲⊳ ι2 computes the intersection of the intervals ι1 and ι2. ι ⊲⊳ (ι u) merges the labels for a value. ι ⊲⊳ (ι1, ι2) refines ι2 based on the intersection of ι and ι1. Evidence-based consistent subtyping: Next, we define consistent subtyping relations for both gradual labels and types as g1 g2 supported by label-intervals. The consistent subtyping relation between two gradual types is written as (ι1, ι2) ⊢ τ ≤ c τ (defined in Fig. 5). In this relation, ι1, resp. ι2 represents the set of possible labels for g1, resp. g2, and g1 4 c g2. The evidence (ι1, ι2) is to justify the consistent security label partial ordering relation between the labels of the gradual types. Note that we g1 g2 do not have ι1 4 ι2 in the premise. The reason is that (ι1, ι2) ⊢ τ ≤ c τ is used to type runtime terms; even though ι1 4 ι2 ′ ′ ′ holds initially, as label-intervals are refined from ιi to ιi, we cannot guarantee that ι1 4 ι2 hold. This will break preservation proofs. It is not the gradual type system’s job to ensure all execution paths are secure. Instead, the runtime semantics will refine the intervals and abort the computation if necessary when a term is evaluated. Typing rules: Expressions and commands with evidence are typed using rules shown in Fig. 6. G-CAST casts an expression of type U1 to U2, if the cast evidence E shows that U1 is a consistent subtype of U2. We augment the command typing with an interval for the gradual pc label; ιpc is the range of possible static labels for the gpc. The rules are similar to the ones in the original type-system except for the use of evidence for consistent ordering between the gradual labels. An exception is the use of WtSet(c) that returns the set of variables being updated or assigned to

6 Γ ⊢ e : U

gi g1 ∀i ∈{1, 2}, Γ ⊢ ei : τ Γ ⊢ e : τ g1 g ι ⊑ γ(g) g = g1 gc g2 E ⊢ τ ≤ c τ g g G-CONST G-VAR g G-BOP g g G-CAST Γ ⊢ (ιu) : Γ(u) Γ ⊢ x : Γ(x) Γ ⊢ e1 bop e2 : τ Γ ⊢ E e : τ

Γ; ιpc gpc ⊢ c

g Γ ⊢ e : bool X = WtSet(c) ιc = γ(g) Γ; ιpc g ιc gpc gc g ⊢ c HILE G-SKIP X G-W Γ; ιpc gpc ⊢ skip Γ; ιpc gpc ⊢ while e do c

g g Γ; ιpc gpc ⊢ c1 Γ ⊢ x : τ Γ ⊢ e : τ ℓ Γ; ιpc gpc ⊢ c2 ιpc ⊑ γ(gpc) gpc 4 c g Γ ⊢ e : τ ιpc ⊑ γ(gpc) gpc 4 c ℓ G-SEQ G-ASSIGN G-OUT Γ; ιpc gpc ⊢ c1; c2 Γ; ιpc gpc ⊢ x := e Γ; ιpc gpc ⊢ output(ℓ,e)

g Γ ⊢ e : bool ιc = γ(g) X = WtSet(c1) ∪ WtSet(c2) ∀i = {1, 2}, Γ; ιpc g ιc gpc gc g ⊢ ci F X G-I Γ; ιpc gpc ⊢ if e then c1 else c2

G Fig. 6: Typing rules for WHILEEvd. Γ(u) maps a constant to its type (e.g. n to int, and true to bool) . Γ ⊢ e e′ : U ι = γ(g) ι = γ(g) Γ(x)= τ g T-BOOL T-INT T-VAR Γ ⊢ bg (ιb)g : boolg Γ ⊢ ng (ιn)g : intg Γ ⊢ x x : τ g

′ gi ′ g1 ∀i ∈{1, 2}, Γ ⊢ ei ei : τ Γ ⊢ e e : τ g1 4 c g g = g1 gc g2 (ι1, ι2)= refine(γ(g1),γ(g)) ′ ′ g T-BOP g g ′ g T-CAST Γ ⊢ e1 bop e2 e1 bop e2 : τ Γ ⊢ (e :: τ ) (ι1, ι2) e : τ

′ Γ; gpc ⊢ c c

′ g ′ g ′ g Γ(x)= τ Γ ⊢ e e : τ Γ ⊢ e e : τ g 4 c ℓ ′ ′ g 4 c g (ι1, ι2)= refine(γ(g ),γ(g)) (ι1, ι2)= refine(γ(g),γ(ℓ)) g ′ T-ASSIGN g ′ T-OUT Γ; gpc ⊢ x := e x := (ι1, ι2) e Γ; gpc ⊢ output(ℓ,e) output(ℓ, (ι1, ι2) e )

′ g ′ ′ g ′ Γ ⊢ e e : bool Γ; gpc gc g ⊢ c c Γ ⊢ e e : bool Γ; gpc gc g ⊢ c1 c1 ′ ′ ′ ′ X = WtSet(c ) Γ; gpc gc g ⊢ c2 c2 X = WtSet(c1) ∪ WtSet(c2) T-WHILE T-IF X ′ ′ X ′ ′ ′ Γ; gpc ⊢ while e do c while e do c Γ; gpc ⊢ if e then c1 else c2 if e then c1 else c2

G G Fig. 7: Translation from WHILE to WHILEEvd in the command c. WtSet is straightforwardly inductively defined over the structure of c and is shown below: WtSet(skip)= ∅ WtSet(output(ℓ,e)) = ∅ WtSet(x := e)= {x} WtSet(while e do c)= WtSet(c) WtSet(c1; c2)= WtSet(c1) ∪ WtSet(c2) WtSet(if e then c1 else c2)= WtSet(c1) ∪ WtSet(c2) Further, G-ASSIGN and G-OUT do not consider expression subtyping and instead rely on the casts inserted by translation.

G G B. From WHILE to WHILEEvd G G The programs are written in WHILE , the language without evidence, which is then translated to WHILEEvd. The explicit casts for ASSIGN and OUT are automatically inserted to account for the subtyping of expressions. We show the interesting rules G G for translating WHILE expressions and commands to WHILEEvd with evidence insertion in Fig. 7. T-ASSIGN inserts a cast for the expression e to have the same label as that of x. For example, xL := y? is rewritten to x := (refine([⊥, ⊤], [L,L])L)y. Similarly, T-OUT casts the expression e to the channel level ℓ.

7 δ/e ⇓ v

M-CONST M-VAR δ / (ιu)g ⇓ (ιu)g δ / x ⇓ δ(x)

gi ∀i ∈{1, 2}, δ/ei ⇓ (ιi ui) ι = ι1 g ι2 g = g1 gc g2 u = u1 bop u2 g M-BOP δ/e1 bop e2 ⇓ (ιu)

δ/e ⇓ (ιu)g ι′ = ι ⊲⊳ E δ/e ⇓ (ιu)g ι ⊲⊳ E = undef ′ ′ M-CAST ′ M-CAST-ERR δ / Eg e ⇓ (ι′ u)g δ / Eg e ⇓ abort

Fig. 8: Monitor semantics for expressions

α κ,δ/ c −→ κ′,δ′ / c′

α ′ ′ ′ α ′ ′ ′ κ,δ/ c1 −→ κ ,δ / c1 κ,δ/ c −→ κ ,δ / c M-SEQ M-PC α ′ ′ ′ α ′ ′ ′ κ,δ/ c1; c2 −→ κ ,δ / c1; c2 κ ⊲ ιpc gpc,δ/ {c} −→ κ ⊲ ιpc gpc,δ / {c }

M-POP M-SKIP ιpc gpc ⊲ κ,δ / {skip} −→ κ,δ / skip κ,δ / skip; c −→ κ,δ/ c

′ ′′ ′ δ/e ⇓ v v = refineLB(ιpc, v) v = updL(intvl (δ(x)), v ) ′′ M-ASSIGN ιpc gpc,δ/x := e −→ ιpc gpc,δ[x 7→ v ] / skip

′ ′′ ′ δ/e ⇓ v v = refineLB(ιpc, v) v = updL(intvl (δ(x)), v ) ′′ M-OUT (ℓ,v ) ιpc gpc,δ/ output(ℓ,e) −→ ιpc gpc,δ/ skip

′ ′ ιpc = ιpc g ι gpc = gpc gc g ′ ci = c1 if b = true ci = c2 if b = false δ/e ⇓ v δ = rfL(δ, X, ιpc g intvl (v)) F EFINE g M-IF X M-I -R ιpc gpc,δ/ if (ιb) then c1 else c2 −→ ιpc gpc,δ/ if e then c1 else c2 −→ ′ ′ ′ ιpc gpc ⊲ ιpc gpc,δ/ {ci} ιpc gpc,δ / if v then c1 else c2

X M-WHILE ιpc gpc,δ/ while e do c −→ ιpc gpc,δ/ ifX e then (c; whileX e do c) else skip

Fig. 9: Monitor semantics for commands

The other interesting translation rules are T-IF and T-WHILE, which insert a write-set X that includes the set of all variables that might be written to in both the branches and the loop body. We prove that any well-typed term in WHILEG is translated G to another well-typed term in WHILEEvd. The lemmas and their proofs are described in Appendix A.

C. Operational Semantics Runtime constructs: We define additional runtime constructs for our semantics, shown below. The store, δ, maps variables to values with their gradual labels and intervals. The gradual labels of the variables are suffixed on the values for the purpose of evaluation. κ is a stack of pc labels, each of which is a gradual label, gpc, with the corresponding interval, ιpc. Store δ ::= · | δ, x 7→ v PC Stack κ ::= ∅ | (ιpc gpc) | κ1 ⊲ κ2 Actions α ::= · | (ℓ, v) Commands c ::= ··· |{c} | if e then c1 else c2

The stack is used for evaluating nested if statements. The operation κ1 ⊲ κ2 indicates that κ1 is on top of κ2 in the stack. α is an action, which may be silent or a labeled output. We add two runtime commands. {c} is used in evaluating if statements. The curly braces help the monitor keep track of the scope of a branch. The if statement without the write set is used in an intermediate evaluation state.

8 ′ ′ ′ refine(ιc, ι) = ( , ι ) δ = rfL(δ, X, ι) v = refineLB(ι, v) 6= undef g ′ g ′ ′ refineLB(ιc, (ιu) ) = (ι u) rfL(δ, ·, ι)= δ rfL((δ, x 7→ v), (X, x), ι)= δ , x 7→ v

ℓ1l g ℓ2l 4 ℓ1r g g restrictLB([ℓ1l,ℓ1r], [ℓ2l,ℓ2r]) = [ℓ1l g ℓ2l,ℓ1r] updL(ιo, (ιn un) ) = (restrictLB(ιo, ιn)un)

Fig. 10: Label-interval operations for the monitor

Expression monitoring semantics: Our monitoring semantics for expressions is of the form δ/e ⇓ e′ as shown in Fig. 8. Rules M-CONST and M-VAR are standard. To perform a binary operation on two values, the operation is performed on the raw values, and the join of their associated intervals and gradual labels is assigned to the computed value. M-CAST refines a value’s interval according to the cast evidence. If the refinement is not valid, the execution aborts (M-CAST-ERR). Note that none of these operations modify the gradual label of the variable (the type of store locations remain the same); the operations only refine the intervals of the gradual label. Commands monitoring semantics: Our monitoring semantics for commands is summarized in Fig. 9 and has the form α κ,δ/ c −→ κ′,δ′ / c′. Additional set of rules where the monitor aborts can be found in Fig. 19 in the Appendix. Rules M-PC and M-POP manage commands running in branches or loops. M-POP pops the top-most pc label from the stack, indicating the end of the branch or loop. We use braces around a command, {c} to indicate that c is executing in a branch or loop. Such a command is run taking into account only the specific branch’s pc stack. When the command execution finishes, the braces are removed and the current pc label is popped off the stack. Rule M-ASSIGN updates the label-interval of the value being assigned based on the assignment’s context ιpc to prevent information leaks. The resulting label-interval is further restricted using the existing label-interval of the variable to ensure that we only refine the set of possible labels. The function intvl (v) returns the label-interval of v. Formally: intvl ((ιu)g)= ι

The function refineLB refines the lower bound of a value’s label-interval and raises it based on the interval ιpc. The updL function is defined in Fig. 10 and uses the interval restrictLB operation. We raise the lower bound of the existing interval based on the interval of the newly computed value. Note that restrictLB differs from refine in the upper-bound of the computed interval. If either of these functions return an invalid interval, the execution aborts. The interval need not be checked against the reference’s label-interval because the inserted cast would have ruled out unsafe programs earlier. Consider the following program, where δ = [x 7→ ([L,L] 3)L,y 7→ ([H,H] 5)H ] x := ([⊥, ⊤], [L,L]) ([H,H], [⊥, ⊤]) y This program tries to cast an H value to ?, then back to L, which is accepted by the type system. The expression to be assigned to x is first evaluated to ([⊥, ⊤], [L,L]) ([H,H], [⊥, ⊤]) ([H,H] 5)H, then to ([⊥, ⊤], [L,L]) ([H,H] 5)H , then aborts, because [H,H] ⊲⊳ ([⊥, ⊤], [L,L]) evaluates to refine([H,H], [L,L]) = undef. We explain the assignment rule via examples. Consider a three-point lattice L 4 M 4 H, the following command x := ? ? ? [H,H] 5 , and two stores δ1 = x 7→ [M,H] 1 and δ2 = x 7→ [L,M] 2 . Assume the following current pc-interval ? ιpc = [L,H]. Here, v = [H,H] 5 . The second premise further refines the interval of v to make sure that the pc context is lower than or equal to the interval of the value to be written. This is to prevent low assignments in a high context. For this example, refine([L,H], [H,H]) = ([L,H], [H,H]), so the intervals remain the same. Next, we narrow down the possible label set using the existing value’s interval. This is to adhere to our design choice that we do not change the type of the variables ′′ ? and only narrow down the label choices (Section III-A). For δ1, v = [H,H]5 , so now x stores a secret value with label H. For store δ2, restrictLB([L,M], [H,H]) is not defined and the monitor aborts. When the old value in the store has a label-interval that is lower than the label-interval of the new value to be stored, the monitor aborts; for instance, under the store where x 7→ ([L,L]0)?, the monitor aborts the execution of x := ([H,H]1)?, as restrictLB([L,L], [H,H]) is not defined. This is also consistent with our design choice to only refine the label set, not update it. M-OUT makes similar comparisons as M-ASSIGN to ensure that the output is permitted. Rule M-IF is standard. The pc label is determined by joining the current pc with the gradual label and interval of the branch-predicate’s value. Here, the pc stack grows and the branch is placed in the scoping braces. The rule for while reduces it to if. Rule M-IF-REFINE is the key for preventing implicit leaks. We refine the intervals for variables in both branches according to the write set, X, which contains the set of all variables being updated in either one of the two branches. Fig. 10 includes the auxiliary definitions for refining the intervals of variables in a write set. The function rfL refines the label-interval of values in the store and is defined inductively. Here, it is used to refine the intervals of the variables in the write set to be at least as high as the lower label in the interval of the current pc. When the functions rfL return undef, the execution aborts.

9 Example: Below, we define two initial memories, δt maps x to true and δf maps x to false. Both y and z store true initially with y’s label being ? and z being L such that L ⊑ H. ? δy = y 7→ [L,H]true L δz = z 7→ [L,L]true H δt = x 7→ [H,H]true H δf = x 7→ [H,H]false {y} ? c1 = if x then y := [L,H]false else skip {z} L c2 = if y then z := [L,L]false else skip Below is the execution starting from the state where x is true.

[L,L] L, (δt,δz,δy) / c1; c2 ? −→[L,L] L, (δt,δz,y 7→ [H,H]true ) / ? if x then y := [L,H]false else skip; c2 ? −→[H,H] H ⊲ [L,L] L, (δt,δz,y 7→ [H,H]true ) / ? {y := [L,H]false }; c2 ? −→[H,H] H ⊲ [L,L] L, (δt,δz,y 7→ [H,H]false ) / {skip}; c2 ? −→[H,H] H ⊲ [L,L] L, (δt,δz,y 7→ [H,H]false ) / skip; c2 ? −→[L,L] L, (δt,δz,y 7→ [H,H]false ) / c2 −→abort In the last step, rfL fails, because the operation refine([H,H], [L,L]) produces an invalid label-interval. Now let’s see the execution starting from x 7→ false.

[L,L] L, (δf ,δz,δy) / c1; c2 ? −→[L,L] L, (δf ,δz,y 7→ [H,H]true ) / ? if x then y := [L,H]false else skip; c2 ? −→[H,H] H ⊲ [L,L] L, (δf ,δz,y 7→ [H,H]true ) / {skip}; c2 ? −→[H,H] H ⊲ [L,L] L, (δf ,δz,y 7→ [H,H]true ) / skip; c2 ? −→[L,L] L, (δf ,δz,y 7→ [H,H]true ) / c2 −→abort

Notice that the label-intervals of y are changed the same way as when we start the execution from δt. Ultimately, the program aborts for the same reason.

V. NONINTERFERENCE G To prove noninterference, we extend WHILEEvd with pairs of values, expressions, and commands to simulate two executions which differ on secret values. This allows us to reduce our noninterference proof to a preservation proof [18].

A. Paired Execution Syntax: The augmented syntax with pairs is shown below. g g Values v ::= (ιu) | hι1 u1 | ι2 u2i Cmd. c ::= ··· |hκ1, ι1,c1 | κ2, ι2,c2ig The store δ is extended to contain pairs of values. We also extend commands to be paired but do not allow pairs to be nested; an invariant maintained by our operational semantics. We only use pairs for values and commands whose values and effects are not observable by the adversary (are “high”). Pairs of commands are part of the runtime statement, generated as a result of evaluating a branching statement. Each command represents an independent execution, capable of changing its own pc stack. As a result, we include local pc stacks in the pair with each command. The rationale behind additional pc stacks in command pairs is explained with the semantics. Label-interval operations on pairs: The interval of a paired value is a pair of intervals, defined below. g intvl (hι1 u1 | ι2 u2i )= hι1 | ι2i

10 Expression Semantics: δ /i e ⇓ v

′ δ /i e ⇓ v v = (E,g) ⊲ v g g P-CONST P-VAR g ′ P-CAST δ /i (ιu) ⇓ (ιu) δ /i x ⇓ rdi δ(x) δ /i E e ⇓ v

α ′ ′ ′ Command Semantics: κ,δ /i c −→ κ ,δ /i c

α κi ⊲ ιpc g ιi gpc gc g,δ /i ci −→ ′ ′ ′ ′ ′ κi ⊲ ιpc g ιi gpc gc g,δ /i ci cj = cj κj = κj {i, j} = {1, 2} α P-C-PAIR ιpc gpc,δ/ hκ1, ι1,c1 | κ2, ι2,c2ig −→ ′ ′ ′ ′ ′ ιpc gpc,δ / hκ1, ι1,c1 | κ2, ι2,c2ig

cj = c1 if u1 = true cj = c2 if u1 = false ck = c1 if u2 = true ck = c2 if u2 = false g P-LIFT-IF ιpc gpc,δ/ if hι1 u1 | ι2 u2i then c1 else c2 −→ ιpc gpc,δ/ h∅, ι1,cj |∅, ι2,ckig

P-SKIP-PAIR ιpc gpc,δ/ h∅, ι1, skip |∅, ι2, skipig −→ ιpc gpc,δ/ skip

′ δ /i e ⇓ v v = refineLB(ιpc, v) ′ P-ASSIGN ιpc gpc,δ/i x := e −→ ιpc gpc,δ[x 7→ updi δ(x) v ] /i skip

′ ′′ ′ δ /i e ⇓ v v = refineLB(ιpc, v) v = updL [ℓ,ℓ] v ′′ P-OUT (i,ℓ,v ) ιpc gpc,δ/i output(ℓ,e) −→ ιpc gpc,δ/i skip

Fig. 11: Selected rules of paired executions

The intersection of an interval and a paired value is defined as follows. Other extensions to label-interval operations can be found in Appendix C. g g ι ⊲⊳ hι1 u1 | ι2 u2i = hι ⊲⊳ ι1 u1 | ι ⊲⊳ ι2 u2i Memory read and update operations: As we allow the intervals of values to be refined, the store read(rd) and update (upd) operations for paired values need to make sure that the correct paired value is read or updated. These functions are shown in Fig. 23 in the Appendix. Operational semantics for pairs: The operational semantics are augmented with an index, i. The judgments now are of the ′ ′ ′ ′ form δ /i e ⇓ e and κ,δ /i c −→ κ ,δ /i c . The index i indicates which branch of a pair is executing (when i ∈ {1, 2}) or if it is a top-level execution (when i is omitted). Most of the rules can be directly obtained by adding the i to the monitor semantics shown in Fig. 8 and 9. Rules that deal with pairs, including read and write to the store need to be modified. We explain important rule changes (shown in Fig. 11). Rule P-VAR uses the function rdi v to retrieve the value indexed by i within v. To evaluate a cast over a pair of values, we push the cast inside the pair (P-CAST). Each command in the pair (P-C-PAIR) can make progress independently and the premise of the rule is indexed by the corresponding i. Here κi is the pc stack specific to ci. Consider a command c = hc1 | c2i, where both c1 and c2 have nested if statements. The execution of c will create different κ1 and κ2 when executing c1 and c2. Next, ιi is the pc label-interval demonstrating that c is supposed to execute in a “high” context (unobservable by the adversary). The bottom pc in the stack is joined with ιi. We will come back to this point when explaining the typing rules. Rule P-LIFT-IF lifts the pair that appears as branch conditions to generate a paired command. The resulting commands on each side of the pair are determined by the value in the corresponding side of the branch condition. The branching context ιi is the runtime interval of the branching condition. The initial local pc stack is empty. Note that the individual branches do not contain pairs of commands. The only rule that generates paired command is P- LIFT-IF. To see how the semantics prevent nesting command pairs and how paired execution represents low runs with different H secrets, consider the program in Listing 6. Assume that a and b are variables containing paired values such that a = hua1 | ua2i H and b = hub1 | ub2i , meaning both a and b contain secrets and ua1 and ub1 are values for the first execution and ua2 and ub2 are for the second. We ignore the intervals in this example for simplicity of exposition. On line 1, we use the P-LIFT-IF rule since we branch on a pair of values to create paired commands. In the first execution, if ua1 = true, we take the then branch. When evaluating b inside the branch we take the first part of the pair using the expression evaluation rules and rdi operation

11 1 if a then ? 2 if b then y := [⊥, ⊤]1 3 else skip ? 4 else y := [⊥, ⊤]2 Listing 6: Example program to explain branching on pairs

(Fig. 23) for i = 1, i.e., rd1 b = ⌊b⌋1 = ub1. Thus, the branch on line 2 becomes: if ub1 then ... while the remaining parts remain the same. Similarly in the second execution, based on the value of ua2, either the then branch or the else branch is chosen. If the then branch is chosen, the branch on line 2 becomes if ub2 then ... as we are in the second execution of the branch (i = 2) on line 1 and rd2 b = ⌊b⌋2 = ub2. Generating two different runs of the program is sufficient for reasoning about noninterference, which is what the projection semantics do. Local pc refinements in pairs are forgotten when both sides of the pair finish executing in P-SKIP-PAIR. This is similar to the P-POP rule where pc for the branch or loop is forgotten. Rule P-ASSIGN deals with the complexity of pairs updating the store in one branch with the helper function updi vo vn (defined in Fig. 23). The refinement of labels during store updates is the same as the monitor semantics. When the update comes from a specific branch of execution (i ∈ {1, 2}), the value for the other branch should be preserved. If the value in the store is already a pair, only the ith sub-expression is updated. Reconsider the example in Listing 6. The assignment on line 2 happens in either of the two branches, or both the branches depending on the values of ua1 to ub2. If it happens in only the first projection, the first part of the value-pair in y is updated. Suppose that y = h[H, ⊤]0 | [H, ⊤]42i?, initially, and ? ua1 = ub1 = true. Then, the value of y after the assignment on line 2 becomes y = h[H, ⊤]1 | [H, ⊤]42i . If ua2 = false, then the else branch is taken, and at the end of the assignment on line 4 the value of y is updated to y = h[H, ⊤]1 | [H, ⊤]2i?. The first part of the pair is already updated through the then branch as we evaluate the two runs one after the other when branching on a pair of values. If the store value is not a pair, the value becomes a pair where the ith sub-expression is the updated value, and the other sub-expression is the old value. Considering the same example as above, if initially y = ([H, ⊤]42)?, then at the end of then ? branch with ua1 = true, the updated value of y is y = h[H, ⊤]1 | [H, ⊤]42i . When updates happen at the top-level, the entire value in the store should be updated. The first rule applies when either the old or the new value is a pair and the second rule applies when none of them are pairs. Note that this is the reason why the intervals in a pair may differ. The output rule is mostly the same. The event being output now includes the index to aid the statement and proof of noninterference. The P-IF-REFINE rule (for M-IF-REFINE) uses an augmented version of rfL, which only refines label-intervals for the ith branch.

B. Semantic Soundness and Completeness To connect the semantics of the extended language with pairs to the monitor semantics, we prove soundness and completeness theorems. These theorems depend on projections of the store, expression- and command-configurations. Similar to the value projection seen before, the goal of these projections is to obtain one execution from a paired execution. The projection of a paired value, a paired interval, a normal value and interval are straightforward and defined in Fig. 23. The projection of stores (δ) and traces (T) is inductively defined as shown in Fig. 12. The projection function only keeps the output events produced by the execution of concern and ignores output performed by the other execution. The projection function for expression configurations is ⌊δ/e⌋i = ⌊δ⌋i / e and for command configurations is defined in Fig. 12. The interesting case is the projection of a command pair. We reassemble the pc stack and wrap ci with curly braces to reflect the fact that these pairs only appear in an if branch. The Soundness theorem ensures that if a configuration can transition to another configuration, then its projection can transition to the projection of the resulting configuration, generating the same trace modulo projection. The Completeness theorem ensures that if both projections of a configuration terminate, then the configuration terminates in an equivalent state. We write, ⊢ κ,δ /i c wf, to indicate that the configuration is well-formed (defined in Appendix E). Theorems 8 and 9 are the formal soundness and completeness theorem statements. The proofs can be found in Appendix G and Appendix H.

T ⌊T⌋i ∗ ′ ′ ′ ∗ ′ ′ ′ Theorem 1 (Soundness). If κ,δ/ c −→ κ ,δ / c where ⊢ κ,δ/ c wf, then ∀i ∈{1, 2}, ⌊κ,δ/ c⌋i −→ ⌊κ ,δ / c ⌋i

Ti T ∗ ′ ′ ∗ Theorem 2 (Completeness). If ∀i ∈ {1, 2}, ⌊κ,δ/ c⌋i −→ κi,δi / skip and ⊢ κ,δ / c wf, then ∃κ ,δ s.t. κ,δ / c −→ ′ ′ ′ ′ κ ,δ / skip, ⌊κ ,δ / skip⌋i = κi,δi / skip and Ti = ⌊T⌋i.

12 Store projection:

⌊·⌋i = · ⌊δ, x 7→ v⌋i = ⌊δ⌋i, x 7→ ⌊v⌋i Trace projection: ⌊·⌋i = · ⌊T, (ℓ, v)⌋i = ⌊T⌋i, (ℓ, ⌊v⌋i) ⌊T, (j, ℓ, v)⌋i = ⌊T⌋i, (ℓ, v) if i = j ⌊T, (j, ℓ, v)⌋i = ⌊T⌋i if i 6= j Command-configuration projection: ′ ′ ′ ⌊κ,δ/ c1⌋i = κ ,δ / c1 ′ ′ ′ ⌊ιpc gpc,δ/ skip⌋i = ιpc gpc, ⌊δ⌋i / skip ⌊κ,δ/ c1; c2⌋i = κ ,δ / c1; c2

′ ′ ′ ⌊κ,δ/ c⌋i = κ ,δ / c ′ ′ ′ ⌊ιpc gpc,δ/x := e⌋i = ιpc gpc, ⌊δ⌋i / x := e ⌊κ ⊲ ιpc gpc,δ/ {c}⌋i = κ ⊲ ιpc gpc,δ / {c }

⌊ιpc gpc,δ/ output(ℓ,e)⌋i = ιpc gpc, ⌊δ⌋i / output(ℓ,e)

′ skip if ci = skip and cj 6= skip ∀{i, j}∈{1, 2}, ci =  {ci} else ′ ⌊ιpc gpc,δ/ hκ1, ι1,c1 | κ2, ι2,c2ig⌋i = κi ⊲ (ιpc g ιi) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋i / ci

⌊ιpc gpc,δ/ h∅, ι1, skip |∅, ι2, skipig⌋i = κi ⊲ (ιpc g ιi) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋i / {skip}

⌊ιpc gpc,δ/ if v then c1 else c2⌋i = ιpc gpc, ⌊δ⌋i / if ⌊v⌋i then c1 else c2

X X ⌊ιpc gpc,δ/ if e then c1 else c2⌋i = ιpc gpc, ⌊δ⌋i / if e then c1 else c2

X X ⌊ιpc gpc,δ/ while e do c⌋i = ιpc gpc, ⌊δ⌋i / while e do c

Fig. 12: Projections

C. Preservation Before we explain the typing rules for the extended configuration, we define another label relation. A gradual label is said to be “high” w.r.t an attacker, if the lower label in the interval is not lower than or equal to the level of the attacker.

ι = [ℓl,ℓr] ℓl 64 ℓA ι ⊑ γ(g)

ι ⊢ g ∈ H(ℓA)

All the pair typing rules are parameterized over attacker’s label ℓA, which we omit from the rules for simplicity. The typing rule for value-pairs is shown below. The second premise checks that the interval is representative of the gradual type U. The last premise checks if U’s security label is high, meaning this pair of values is non-observable to the adversary. g ∀i ∈{1, 2}, Γ ⊢ ιi ui : τ ιi ⊑ γ(g) ιi ⊢ (g) ∈ H(ℓA) g R-V-PAIR Γ ⊢ hι1 u1 | ι2 u2i : τ

The judgement for typing commands with pairs is of the form Γ; κ ⊢r c. Fig. 13 summarizes these typing rules. Rule R-POP types the inner command with only the top part of the pc stack. When the pc stack contains only one element, R-END directly uses command typing. For pairs, R-C-PAIR first checks that each ci is well-typing, using the pc context assembled from the local pc context. The second premise makes sure that these commands are typed (executed) in a high context. Here ιi is the witness for g, which demonstrates that ci are high commands. The sequencing statement types the second command using only the last pc on the stack because the execution order is from left to right. We can only encounter branches in the first part of a sequencing statement and not the second part before beginning the execution of the second command in the sequence. The typing rule for if statements without a write set is straightforward. We define store, trace and configuration typing in Fig. 14. The store δ types in the typing environment Γ if all variables in δ are mapped to their respective type and gradual label in Γ. We define top-level configuration typing as ⊢ κ,δ,c. To type

13 Γ; κ ⊢r c

Γ; κ ⊢r c Γ; ιgpc ⊢ c Γ; κ ⊲ ιpc gpc ⊢r c1 Γ; ιpc gpc ⊢ c2 κ 6= ∅ R-POP R-END R-C-SEQ Γ; κ ⊲ ιgpc ⊢r {c} Γ; ιgpc ⊢r c Γ; κ ⊲ ιpc gpc ⊢r c1; c2

∀i ∈ 1, 2, Γ; κi ⊲ (ιpc g ιi) (gpc gc g) ⊢r ci ιi ⊢ g ∈ H(ℓA) R-C-PAIR Γ; ιpc gpc ⊢r hκ1, ι1,c1 | κ2, ι2,c2ig

g Γ ⊢ e : bool ιg = γ(g) ∀i ∈{1, 2}, Γ; ιpc g ιg gpc gc g ⊢ ci R-C-IF Γ; ιpc gpc ⊢r if e then c1 else c2

Fig. 13: Typing rules for commands with pairs Store typing: ⊢ δ :Γ Γ ⊢ v : U T-S-EMP T-S-IND ⊢ · : · ⊢ δ, x 7→ v :Γ, x : U Configuration typing:

⊢ δ : Γ Γ; κ ⊢r c T-CONF ⊢ κ,δ,c Trace typing:

⊢ v : U ⊢ intvl (v) 4 [ℓ,ℓ] ⊢ v : U ℓ 64 ℓA ⊢ intvl (v) 4 [ℓ,ℓ] T-A-OUT T-A-OUTI ⊢ (ℓ, v) ⊢ (i,ℓ,v) ⊢ α ⊢ T T-T-EMP T-T-IND ⊢ · ⊢ α, T

Fig. 14: Store, trace and configuration typing traces and actions, the output value needs to be well-typed, and the label-interval of the value has to be lower than or equal to the channel label. Using these definitions, we prove that our paired execution semantics preserve the configuration typing and generate a well-typed trace (Theorem 10). We write, ⊢ κ,δ /i c sf for i ∈ {·, 1, 2}, to indicate that the configuration is safe. We say a configuration is safe if all of the following hold:

1) if i ∈{1, 2}, then κ ∈ H(ℓA), ∀x ∈ WtSet(c), intvl (δ(x)) ∈ H(ℓA) 2) if c = if h | i then c1 else c2, then ∀x ∈ WtSet(c), intvl (δ(x)) ∈ H(ℓA) 3) if c = hκ1, ι1,c1 | κ2, ι2,c2ig, then ∀i ∈{1, 2}, ιi ⊢ g ∈ H(ℓA), and ∀x ∈ WtSet(c), intvl (δ(x)) ∈ H(ℓA) The lemmas and the proofs are shown in Appendix I. T Theorem 3 (Preservation). If κ,δ/ c −→∗ κ′,δ′ / c′ with ⊢ κ,δ,c and ⊢ κ,δ/ c sf, then ⊢ κ′,δ′,c′ and ⊢ T

D. Noninterference We show that the gradual type system presented above satisfies termination-insensitive noninterference. We start by defining equivalence for values and stores (Fig. 15). Two values are said to be equivalent to an adversary at level ℓA if either they are both visible to the adversary and are the same, or neither are observable by the adversary. We also define equivalence of traces w.r.t an adversary at level ℓA in Fig. 15. The following noninterference theorem (Theorem 4) states that given a program and two stores equivalent for an adversary at level ℓA, if the program terminates in both the runs, then the ℓA-observable actions on both runs are the same.

Theorem 4 (Noninterference). Given an adversary label ℓA, a program c, and two stores δ1, δ2, s.t., ⊢ δ1 ≈ℓA δ2 :Γ, and Ti ∗ ′ T T Γ; [⊥, ⊥] ⊥⊢ c, and ∀i ∈{1, 2}, [⊥, ⊥] ⊥,δi / c −→ κi,δi, skip, then ⊢ 1 ≈ℓA 2.

The lemmas and proofs can be found in Appendix J. We know that only when ℓ 64 ℓA, the individual runs can produce (i,ℓ,v) because the two runs diverge only when branching on pairs. Similarly, (ℓ, hv1 | v2i) can only be produced if ℓ 64 ℓA, because pairs can only be typed if each individual interval in the pair is high and rule P-OUT makes sure ℓ is lower than or equal

14 Store equivalence: g g g 4 c ℓA ι ⊑ γ(g) ⊢ (ιu) : U ∀i ∈{1, 2}, ιi ⊢ g ∈ H(ℓA) ⊢ (ιi ui) : U g g EQV-L g g EQV-H ⊢ (ιu) ≈ℓA (ιu) : U ⊢ (ι1 u1) ≈ℓA (ι2 u2) : U

⊢ δ1 ≈ℓA δ2 :Γ ⊢ v1 ≈ℓA v2 : U EQS-EMP EQS-IND ⊢·≈ℓA · : · ⊢ δ1, x 7→ v1 ≈ℓA δ2, x 7→ v2 :Γ, x : U Trace equivalence: T T T T ⊢ 1 ≈ℓA 2 ℓ1 = ℓ2 4 ℓA v1 = v2 ⊢ 1 ≈ℓA 2 ℓ1 64 ℓA EQT-E T T EQT-L T T EQT-HL ⊢ [] ≈ℓA [] ⊢ (ℓ1, v1) :: 1 ≈ℓA (ℓ2, v2) :: 2 ⊢ (ℓ1, v1) :: 1 ≈ℓA 2

T T ⊢ 1 ≈ℓA 2 ℓ2 64 ℓA T T EQT-HR ⊢ 1 ≈ℓA (ℓ2, v2) :: 2

Fig. 15: Equivalence definitions Labels and intervals: ′ ′ ℓ1 4 ℓ1 ℓ2 4 ℓ2 ′ ′ ℓ ⊑ ? ℓ ⊑ ℓ [ℓ1,ℓ2] ⊑ [ℓ1,ℓ2] Expressions: ′ ′ ′ ι1 ⊑ ι2 g1 ⊑ g2 e1 ⊑ e1 e2 ⊑ e2 E ⊑ E g1 ⊑ g2 e1 ⊑ e2 g1 g2 ′ ′ ′ (ι1 u) ⊑ (ι2 u) x ⊑ x e1 bop e2 ⊑ e1 bop e2 Eg1 e1 ⊑ Eg2 e2 Commands: ′ ′ c1 ⊑ c1 c2 ⊑ c2 e1 ⊑ e2 e1 ⊑ e2 ′ ′ skip ⊑ skip c1; c2 ⊑ c1; c2 x := e1 ⊑ x := e2 output(ℓ,e1) ⊑ output(ℓ,e2)

′ ′ e1 ⊑ e2 c1 ⊑ c1 c2 ⊑ c2 e1 ⊑ e2 c1 ⊑ c2 X X ′ ′ X X if e1 then c1 else c2 ⊑ if e2 then c1 else c2 while e1 do c1 ⊑ while e2 do c2 Store, Types and Typing-context: g ⊑ g′ ∀x ∈ Γ. Γ(x) ⊑ Γ′(x) ′ τ g ⊑ τ g Γ ⊑ Γ′ PC-stack and Configurations: ′ ′ ′ ′ ′ ′ ′ ′ ι ⊑ ι g ⊑ g κ1 ⊑ κ1 κ2 ⊑ κ2 ∀x ∈ δ. δ(x) ⊑ δ (x) κ ⊑ κ δ ⊑ δ c ⊑ c ′ ′ ′ ′ ′ ′ ′ ′ ∅⊑∅ ιg ⊑ ι g κ1 ⊲ κ2 ⊑ κ1 ⊲ κ2 δ ⊑ δ κ,δ/ c ⊑ κ ,δ / c

Fig. 16: Precision relations

T T T to the pair’s interval. We prove a simple lemma that establishes that given a well-typed trace of actions , ⊢⌊ ⌋1 ≈ℓA ⌊ ⌋2. By combining the Preservation, Soundness, and Completeness Theorems, it follows that our gradual type system satisfies termination-insensitive noninterference.

VI. GRADUAL GUARANTEES The gradual guarantees state that if a program with more precise labels type-checks and is accepted by the runtime semantics of the gradual type system, then the same program with less precise labels is also accepted by the gradual type system. To establish these guarantees, we define a precision relation between labels, expressions, and commands. The precision relations are shown in Fig. 16. Our type system with gradual labels satisfies the static gradual guarantee. The dynamic gradual guarantee is also ensured by our calculus, i.e., if a command takes a step under a store and pc stack, then a less precise command can also take a step under a less precise store and pc stack. The proofs are shown in Appendix L and M.

Theorem 5 (Static Guarantee). If Γ1; g1 ⊢ c1, Γ1 ⊑ Γ2, g1 ⊑ g2, and c1 ⊑ c2, then Γ2; g2 ⊢ c2.

15 L L H H G y = true , z = true x = false x = true WHILEEvd ? Program NSU/Permissive NSU Permissive Hybrid y = [L, H]true y = [L, L]trueL if x branch not taken branch taken branch taken y ↑ [H,H] try y ↑ [H,H], abort then y := falseL pc = H, abort y ↑ P y ↑ H if y branch taken abort try z ↑ [H,H], abort then z := falseL z ↑ H output(L, z) output(L, false) abort

Fig. 17: Comparison of monitor behavior. y ↑ ℓ denotes monitor’s attempt to update y’s label (interval).

α1 ′ ′ ′ α2 ′ ′ ′ Theorem 6 (Dynamic Guarantee). If κ1,δ1 / c1 −→ κ1,δ1 / c1 and κ1,δ1 / c1 ⊑ κ2,δ2 / c2, then κ2,δ2 / c2 −→ κ2,δ2 / c2 ′ ′ ′ ′ ′ ′ such that κ1,δ1 / c1 ⊑ κ2,δ2 / c2 and α1 = α2.

VII. DISCUSSION

Monitor comparison: Our monitor is a hybrid monitor. The differences between our monitor and traditional hybrid monitors (c.f., [13], [17], [21]–[23]) are that (1), we update the memory before executing the branch, while other hybrid monitors update the labels at the merge points; (2), our monitor will not upgrade variables with fixed static labels (the monitor will abort) and only refine label intervals for dynamically labeled variables. Fig. 17 highlights the differences between our monitor and other information flow monitors using the example program in Listing 4 and a two point lattice (L 4 H). We show two cases for our monitor, differing in y’s security label (?, or L). Note that hybrid monitors including ours have the same behavior regardless of x’s value. When y has a dynamic label, our monitor is more precise than NSU, as precise as permissive-upgrade [12], and less precise than a traditional hybrid monitor [13]. Ours can be as precise as a traditional hybrid monitor if z’s initial value is ([L,H]true)?. This would allow us to refine z’s label interval, and only abort at the output. When y has a static label, or an effectively static label (i.e., ([L,L]true)L), our monitor is the least precise and will abort at the first branch. This rigidity is due to our decision to not update variables’ label-intervals, except by refinement. Implicit leaks manifested in noninterference proofs: Let’s revisit the example at the end of Section IV-C to see how the implicit leak manifests in the paired execution and why it leads to our current design; where we do not use the write sets in the if statements and simply refine the label-intervals. Because x is H, it’s initialized with a paired value. δ = x 7→ h[H,H]trueH | [H,H]falseH i, y 7→ [L,H]true?, z 7→ [L,L]trueL ? c1 = if x then y := [L,H]false else skip L c2 = if y then z := [L,L]false else skip

[L,L] L,δ /c1; c2 −→ ··· / if h[H,H]trueH | [H,H]falseH i then ? y := [L,H]false else skip; c2 −→ ? ··· / h· · · ,y := [L,H]false ; c2 | · · · , skip; c2i −→ The variable y is updated only in the left branch. To prove soundness and completeness of the paired semantics, the two executions should be independent. Therefore, we try to update y in the store as h[H,H]false | [L,H]truei?. However, this pair is not well-formed because pairs are only well-typed if both intervals are in H. Clearly, the right branch of y does not satisfy this requirement. Therefore, we cannot prove preservation for the assignment case. For preservation to succeed, we would need to refine the right branch to be [H,H]true when assigning to y in the left execution. But then the two executions are no longer independent, which breaks soundness (i.e., the projected execution is not guaranteed to make progress or stay in the same state). With these constraints in place, we need to refine y before the branch, which ultimately leads to our final design.

VIII. RELATED WORK

Static Information Flow Type Systems: Quite a few type-systems have been proposed to statically enforce noninterference by annotating variables with labels. Volpano et al. [1] present the first type-system with information flow labels that satisfies a variant of noninterference, also known as termination-insensitive noninterference. If all variables are annotated with concrete security labels, our type system behaves the same as a flow-insensitive information flow type system. Being a gradual type system, we can additionally accept programs with no security labels and enforce termination-insensitive noninterference at runtime. Our formalization borrows the proof-technique from FlowML, presented by Pottier and Simonet [18], for enforcing noninterference using pairs.

16 Static type systems that resemble gradual typing: JFlow [24] (and later Jif) includes polymorphic labels, for which programmers can specify the upper bound of a polymorphic label. Polymorphic labels are essentially (bounded) universally quantified labels and these labels are instantiated by concrete labels at runtime. There is no label refinement associated with polymorphic labels. Jif also allows run-time labels (also called dynamic labels). These are runtime representation of label objects that users can generate and perform tests on. This is not to be confused with the dynamic label (?) in gradual typing. Runtime labels do not mean unknown security labels, nor are they refined at runtime. Finally, label inference is a widely used compile-time algorithm to reduce programmers’ annotation burdens. A flow-insensitive type system with the most powerful inference algorithm is less permission than our system. Ill-typed programs, rejected by a type system, can be accepted by our type system. Their safety is ensured by our runtime monitors. Purely dynamic monitors: Dynamic approaches use a runtime monitor to track the flow of information through the program. The labels are mostly flow-sensitive in nature. Austin and Flanagan [11] present a purely dynamic information flow monitoring approach that disallows assignments to public values in secret contexts. Our monitor semantics follows a similar approach to prevent information leaks at runtime. Subsequent work presents approaches to make the analysis more permissive and amenable to dynamic languages [12], [25]–[27]. A recent paper shows the equivalence between coarse-grained and fined-grained dynamic monitors [28]. Detailed comparisons between our monitor and dynamic monitors can be found in Fig. 17. Hybrid monitors: To leverage the benefits of static and dynamic approaches for precision and permissiveness, researchers have also proposed hybrid approaches to enforce noninterference [13], [17], [21]–[23], [29]–[31]. We demonstrate that the hybrid monitoring approach is suitable for generating runtime behavior of gradual types that rely on refining label intervals. Gradual typing has the added benefit of allowing programmers to reject ill-typed programs. As shown in Fig. 17, our monitor aborts earlier than a typical hybrid monitor because of the lack of support for label updating. We support termination-insensitive noninterference, while others support progress-sensitive noninterference [22], [31]. Gradual information flow type systems: More closely related to our work are works on gradual security types. Disney and Flanagan [3] study gradual security types for a pure lambda calculus, and Fennell and Thiemann [4] present a gradual type system for a calculus with ML-style references. However, these works are based on adding explicit programmer-provided checks and casts to the code. Fennell and Thiemann [5] extend their prior work to object-oriented programs in a flow-sensitive setting for a Java-like language. They use a hybrid approach to perform effect analysis that upgrades the labels of variables similar to the write set used in our analysis. At runtime, these systems cast the dynamic label to a fixed label, rather than a set of possible labels, and the monitors updates labels of memory locations, which we do not do. On the other hand, our approach has fixed gradual labels and refines only the label-intervals associated with the value to satisfy dynamic gradual guarantee. More recently, Toro et al. [6] presented a type-driven gradual type system for a higher-order language with references based on abstract gradual typing [9]. Their formalization satisfies the static gradual guarantee, but sacrifices the dynamic gradual guarantee for noninterference. They briefly discuss the idea of using hybrid approaches and faceted evaluation for regaining the dynamic gradual guarantee. The language presented in this paper is simpler than their language but has mutable global variables and hence, a similar issue with proving noninterference while satisfying the dynamic gradual guarantee. GLIO [7] presents another interpretation of gradual information flow types that enjoys both noninterference and gradual guarantees. GLIO is the most expressive among the above-mentioned projects; it includes higher-order functions, general references, coarse-grained information flow control, and first-class labels. GLIO’s monitor decides the concrete label for a dynamically labeled reference at allocation time. While avoiding problems stemmed from refining label intervals, the concrete label results in a less permissive approach. Our work explores yet another design space of gradual information flow types and highlights the necessity of a hybrid approach for a system that refines label intervals to ensure both noninterference and the gradual guarantees. Extending our static type system to include higher-order functions and references would require a precise static analysis to determine the write set accurately, as pointed out by prior work [17]. This is common for hybrid approaches. For instance, LJGS [5] uses a sophisticated points-to analysis. Moore and Chong have identified sufficient conditions for safely incorporating memory abstractions and static analyses into a hybrid information-flow monitor [17]. An interesting future direction is to investigate such conditions and abstractions for a higher-order language. Another possible direction for handling languages with first-class functions and references can be using the ideas proposed by Nielson et al. [32] and Foster et al. [33], who use regions and side-effect analysis to determine aliases.

IX. CONCLUSION We presented a gradual information flow type system for a simple imperative language that enforces termination-insensitive noninterference and ensures the gradual guarantee at the same time. We demonstrated that our hybrid monitor can stop implicit flows by refining the labels for references in the write-sets of both branches, regardless of which branch is taken. The non-conventional proof technique of noninterference that we used helps us identify the conditions for ensuring the gradual guarantees.

17 ACKNOWLEDGMENT We would like to thank the anonymous reviewers for their insightful comments and feedback. This work was supported in part by the National Science Foundation via grant CNS1704542 and the CyLab Presidential Fellowship at Carnegie Mellon University.

REFERENCES [1] D. Volpano, C. Irvine, and G. Smith, “A sound type system for secure flow analysis,” Journal of Computer Security, vol. 4, no. 2-3, pp. 167–187, Jan. 1996. [2] J. G. Siek and W. Taha, “Gradual typing for functional languages,” in In Scheme And Functional Programming Workshop, 2006, pp. 81–92. [3] T. Disney and C. Flanagan, “Gradual information flow typing,” in Proceedings of the 2nd International Workshop on Scripts to Programs Evolution, 2011. [4] L. Fennell and P. Thiemann, “Gradual security typing with references,” in Proceedings of the 2013 IEEE 26th Computer Security Foundations Symposium, 2013, pp. 224–239. [5] ——, “LJGS: gradual security types for object-oriented languages,” in 30th European Conference on Object-Oriented Programming, 2016, pp. 9:1–9:26. [6] M. Toro, R. Garcia, and E. Tanter, “Type-driven gradual security with references,” ACM Trans. Program. Lang. Syst., vol. 40, no. 4, pp. 16:1–16:55, Dec. 2018. [7] A. A. de Amorim, M. Fredrikson, and L. Jia, “Reconciling noninterference and gradual typing,” in Proceedings of the 35th ACM/IEEE Symposium on Logic in Computer Science, 2020, pp. 116–129. [8] J. G. Siek, M. M. Vitousek, M. Cimini, and J. T. Boyland, “Refined Criteria for Gradual Typing,” in 1st Summit on Advances in Programming Languages, ser. Leibniz International Proceedings in Informatics, vol. 32, 2015, pp. 274–293. [9] R. Garcia, A. M. Clark, and E. Tanter, “Abstracting gradual typing,” in Proceedings of the 43rd Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, 2016, pp. 429–442. [10] J. A. Goguen and J. Meseguer, “Security policies and security models,” in Proc. IEEE Symposium on Security and Privacy, 1982, pp. 11–20. [11] T. H. Austin and C. Flanagan, “Efficient purely-dynamic information flow analysis,” in Proc. ACM SIGPLAN Fourth Workshop on Programming Languages and Analysis for Security, 2009, pp. 113–124. [12] ——, “Permissive dynamic information flow analysis,” in Proc. 5th ACM SIGPLAN Workshop on Programming Languages and Analysis for Security, 2010, pp. 3:1–3:12. [13] A. Russo and A. Sabelfeld, “Dynamic vs. static flow-sensitive security analysis,” in Proceedings of the 2010 23rd IEEE Computer Security Foundations Symposium, 2010, pp. 186–199. [14] S. Hunt and D. Sands, “On flow-sensitive security types,” in Proceedings of the 33rd ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, 2006, pp. 79–90. [15] D. Volpano and G. Smith, “Eliminating covert flows with minimum typings,” in Proceedings 10th Computer Security Foundations Workshop, June 1997, pp. 156–168. [16] T. Terauchi and A. Aiken, “Secure information flow as a safety problem,” in Proceedings of the 12th International Conference on Static Analysis, 2005, pp. 352–367. [17] S. Moore and S. Chong, “Static analysis for efficient hybrid information-flow control,” in Proceedings of the 2011 IEEE 24th Computer Security Foundations Symposium, 2011, pp. 146–160. [18] F. Pottier and V. Simonet, “Information flow inference for ML,” in Proceedings of the 29th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, 2002, pp. 319–330. [19] A. Bichhawat, M. McCall, and L. Jia, “First-order gradual information flow types and gradual guarantees,” https://arxiv.org/abs/2003.12819, 2021. [20] D. E. Denning and P. J. Denning, “Certification of programs for secure information flow,” Commun. ACM, vol. 20, no. 7, pp. 504–513, Jul. 1977. [21] D. Hedin, L. Bello, and A. Sabelfeld, “Value-sensitive hybrid information flow control for a JavaScript-like language,” in Proceedings of the 2015 IEEE 28th Computer Security Foundations Symposium, 2015, pp. 351–365. [22] A. Bedford, S. Chong, J. Desharnais, E. Kozyri, and N. Tawbi, “A progress-sensitive flow-sensitive inlined information-flow control monitor,” Computers & Security, vol. 71, pp. 114 – 131, 2017. [23] P. Buiras, D. Vytiniotis, and A. Russo, “HLIO: Mixing static and dynamic typing for information-flow control in Haskell,” in Proceedings of the 20th ACM SIGPLAN International Conference on Functional Programming, 2015, pp. 289–301. [24] A. C. Myers, “JFlow: Practical mostly-static information flow control,” in Proceedings of the 26th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, 1999, pp. 228–241. [25] D. Hedin and A. Sabelfeld, “Information-flow security for a core of JavaScript,” in Proceedings of the 2012 IEEE 25th Computer Security Foundations Symposium, 2012, pp. 3–18. [26] A. Bichhawat, V. Rajani, D. Garg, and C. Hammer, “Generalizing permissive-upgrade in dynamic information flow analysis,” in Proceedings of the Ninth Workshop on Programming Languages and Analysis for Security, 2014, pp. 15:15–15:24. [27] J. F. Santos and T. Rezk, “An information flow monitor-inlining compiler for securing a core of JavaScript,” in ICT Systems Security and Privacy Protection, 2014, pp. 278–292. [28] M. Vassena, A. Russo, D. Garg, V. Rajani, and D. Stefan, “From fine- to coarse-grained dynamic information flow control and back,” Proc. ACM Program. Lang., vol. 3, no. POPL, Jan. 2019. [29] D. Chandra and M. Franz, “Fine-grained information flow analysis and enforcement in a Java virtual machine,” in 23rd Annual Computer Security Applications Conference, 2007, pp. 463–475. [30] S. Just, A. Cleary, B. Shirley, and C. Hammer, “Information flow analysis for JavaScript,” in Proceedings of the 1st ACM SIGPLAN International Workshop on Programming Language and Systems Technologies for Internet Clients, 2011, pp. 9–18. [31] A. Askarov, S. Chong, and H. Mantel, “Hybrid monitors for concurrent noninterference,” in 2015 IEEE 28th Computer Security Foundations Symposium, 2015, pp. 137–151. [32] F. Nielson, H. R. Nielson, and C. Hankin, Principles of Program Analysis. Berlin, Heidelberg: Springer-Verlag, 1999. [33] J. S. Foster, T. Terauchi, and A. Aiken, “Flow-sensitive type qualifiers,” in Proceedings of the ACM SIGPLAN 2002 Conference on Programming Language Design and Implementation, 2002, pp. 1–12.

APPENDIX G G A. From WHILE to WHILEEvd Lemma 1. If ι = γ(g), then ι ⊑ γ(g)

18 Proof. Case: g =? ι = [⊥, ⊤] and γ(g) = [⊥, ⊤]. By the definition of 4, ⊥ 4 ⊥ and ⊤ 4 ⊤. Thus by the definition of ⊑, ι ⊑ γ(g) Case: g = ℓ ι = [ℓ,ℓ] and γ(g) = [ℓ,ℓ]. By the definition of 4, ℓ 4 ℓ and ℓ 4 ℓ. Thus by the definition of ⊑, ι ⊑ γ(g)

Lemma 2 (Interval refine). ∀i ∈{1, 2}, refine(ι1, ι2) ⊑ ιi PROOF (SKETCH). By examining the definitions of the operations.

Lemma 3 (Intersect refine). ∀i ∈{1, 2}, ι1 ⊲⊳ ι2 ⊑ ιi PROOF (SKETCH). By examining the definitions of the operations.

Lemma 4 (Join refine). ∀i ∈{1, 2}, ιi ⊑ γ(gi) imply ι1 g ι2 ⊑ γ(g1 gc g2). PROOF (SKETCH). By examining the definitions of the operations.

Lemma 5 (Evidence subtyping). E ⊢ g1 ≤ c g2, ι ⊑ γ(g1) imply ι ⊲⊳ E ⊑ γ(g2). Proof. Let E = (ι1, ι2). By inversion, ι2 ⊑ γ(g2), By Lemma 2, ι ⊲⊳ E ⊑ ι2 By ⊑ is transitive, ι ⊑ γ(g2),

Lemma 6. If Γ ⊢ e : U and Γ ⊢ e e′ : U, then Γ ⊢ e′ : U Proof. By induction on the expression typing derivation. Case: BOOL,INT By Lemma 1, γ(g) ⊑ γ(g). By T-BOOL, T-INT and G-BOOL,G-INT, the conclusion holds Case: VAR By definition of T-VAR and G-VAR Case: BOP gi ∀i ∈{1, 2}, Γ ⊢ ei : τ g = g1 gc g2 g Γ ⊢ e1 bop e2 : τ By IH, ′ gi (1) Γ ⊢ ei : τ By (1), T-BOOL and G-BOOL, the conclusion holds Case: CAST ′ ′ Γ ⊢ e : U U ≤ c U Γ ⊢ e :: U : U Assume U = τ g . By assumption ′ (1) (ι1, ι2)= refine(γ(g ),γ(g)) By IH, ′ (2) Γ ⊢ e′ : τ g By Lemma 2 and ⊑ is transitive ′ g g (3) (ι1, ι2) ⊢ τ ≤ c τ g ′ g By (2) and (3), subtyping and ⊑, Γ ⊢ (ι1, ι2) e : τ

′ ′ Lemma 7. If Γ; gpc ⊢ c and Γ gpc ⊢ c c , then WtSet(c)= WtSet(c ) PROOF (SKETCH). By induction on the command typing derivation. Follows from the definition of WtSet for SKIP,ASSIGN, OUT and additionally uses the IH for SEQ,IF, WHILE

19 ′ ′ Theorem 7. If Γ; gpc ⊢ c and Γ; gpc ⊢ c c , then ∀ιpc ⊑ γ(gpc). Γ; ιpc gpc ⊢ c

Proof. By induction on the typing derivation - Γ; gpc ⊢ c. Case: SKIP By definition of T-SKIP, G-SKIP Case: SEQ Γ; gpc ⊢ c1 Γ; gpc ⊢ c2

Γ; gpc ⊢ c1; c2 By IH and inversion of T-SEQ, ′ ′ (1) Γ; ιpc gpc ⊢ c1 and Γ; ιpc gpc ⊢ c2 such that ιpc ⊑ γ(gpc) By (1), G-SEQ, the conclusion holds Case: ASSIGN By Lemma 6, ′ (1) Γ ⊢ x : τ g and Γ ⊢ e′ : τ g By assumption, (2) ιpc ⊑ γ(gpc) By inversion of ASSIGN, ′ (3) gpc 4 c g and g 4 c g By assumption ′ (4) (ι1, ι2)= refine(γ(g ),γ(g)) By Lemma 2 and ⊑ is transitive g′ g (5) (ι1, ι2) ⊢ τ ≤ c τ By (1) and (5), g ′ g (6) Γ ⊢ (ι1, ι2) e : τ By (1), (6), the conclusion holds Case: OUT This proof is similar to ASSIGN. Case: IF (similar for WHILE) g Γ ⊢ e : bool Γ; gpc gc g ⊢ c1 Γ; gpc gc g ⊢ c2 IF Γ; gpc ⊢ if e then c1 else c2 By Lemma 6, (1) Γ ⊢ e′ : boolg By IH, (2) ∀ιpc ⊑ γ(gpc). Γ; ιpc g ιc gpc gc g ⊢ ci such that ιc = γ(g) and i ∈{1, 2} By inversion of T-IF, ′ ′ (3) X = WtSet(c1) ∪ WtSet(c2) By (1), (2), (3), and Lemma 1, the conclusion holds

B. Operational Semantics Figures 18 and 19 summarize the operational semantics of the monitor. Those rules use auxiliary definitions in Figure 20.

δ/e ⇓ v

M-CONST M-VAR δ / (ιu)g ⇓ (ιu)g δ / x ⇓ δ(x)

gi ∀i ∈{1, 2}, δ/ei ⇓ (ιi ui) ι = ι1 g ι2 g = g1 gc g2 u = u1 bop u2 g M-BOP δ/e1 bop e2 ⇓ (ιu)

δ/e ⇓ (ιu)g ι′ = ι ⊲⊳ E δ/e ⇓ (ιu)g ι ⊲⊳ E = undef ′ ′ M-CAST ′ M-CAST-ERR δ / Eg e ⇓ (ι′ u)g δ / Eg e ⇓ abort

Fig. 18: Monitor semantics for expressions

20 C. Paired Execution Figure 25 shows the paired semantic rules, which use auxiliary definitions in Figures 21, 22, 23, 24.

D. Write-set The function WtSet is defined as: WtSet(x)= {x} WtSet(skip)= ∅ WtSet(output(ℓ,e)) = ∅ WtSet({c})= WtSet(c) WtSet(E e)= WtSet(e) WtSet(c1; c2)= WtSet(c1) ∪ WtSet(c2) WtSet(whileX e do c)= WtSet(c) WtSet(hκ1, ι1,c1 | κ2, ι2,c2ig)= WtSet(c1) ∪ WtSet(c2) WtSet(x := e2)= WtSet(x) X WtSet(if e then c1 else c2)= WtSet(c1) ∪ WtSet(c2)

E. Well-formedness 1) ⊢ v wf, if

a) v = hv1 | v2i, then ∀i ∈{1, 2}.vi = (ιi ui) b) v = (ιu)g 2) ⊢ δ wf, if ∀x ∈ δ, ⊢ δ(x) wf 3) ⊢ δ /i e wf for i ∈ {·, 1, 2} if ⊢ δ wf 4) ⊢ c wf, when the following hold:

a) if c = hκ1, ι1,c1 | κ2, ι2,c2ig, then ⊢ c1 wf, ⊢ c2 wf, and c1 and c2 do not contain pairs b) if c = if e then c1 else c2, then ⊢ c1 wf, ⊢ c2 wf, and c1 and c2 do not contain pairs or braces c) if c = whileX e do c, then ⊢ c wf and c does not contain pairs or braces d) if c = c1; c2 then ⊢ c1 wf, ⊢ c2 wf and c2 does not contain pairs or braces e) if c = {c1}, then ⊢ c1 wf 5) ⊢ κ,δ /i c wf for i ∈ {·, 1, 2}) if all of the following hold a) ⊢ c wf and ⊢ δ wf b) if i ∈{1, 2}, then c does not contain pairs

F. Theorems and Proofs for Well-formedness

Lemma 8 (Restrict refines). restrictLB(ι1, ι2) ⊑ ι1 ′ ′ ′ Proof. By definition of restrictLB, if ι1 = [ℓ1,ℓ1] and ι2 = [ℓ2,ℓ2], then restrictLB(ι1, ι2) = [ℓ1 g ℓ2,ℓ1]. As ℓ1 4 (ℓ1 g ℓ2) ′ ′ and ℓ1 4 ℓ1, the conclusion holds. α ′ ′ ′ Lemma 9. If ∀i ∈{1, 2}, E :: κ,δ /i c −→ κ ,δ /i c and ⊢ κ,δ /i c wf, then (a). c′ does not contain pairs and (b). WtSet(c′) ⊆ WtSet(c) Proof. By induction on the structure of E. c′ : doesn’t contain pairs: Follows from well-formedness definition for most rules. P-SEQ, P-PC use the IH additionally. WtSet(c′) ⊆ WtSet(c): ′ P-SEQ By IH, WtSet(c1) ⊆ WtSet(c1). Thus by definition of WtSet, ′ WtSet(c1; c2) ⊆ WtSet(c1; c2) P-PC By IH, WtSet(c′) ⊆ WtSet(c) P-POP WtSet(skip)= WtSet(skip) P-SKIP WtSet(skip) ⊆ WtSet(skip) ∪ WtSet(c) P-ASSIGN WtSet(skip) ⊆ WtSet(x) P-OUT WtSet(skip)= WtSet(output) P-IF WtSet(c1) ⊆ WtSet(c1) ∪ WtSet(c2) P-IF-REFINE WtSet(c1) ∪ WtSet(c2)=

21 WtSet(c1) ∪ WtSet(c2) P-WHILE WtSet(c) ∪ WtSet(c)∪ WtSet(skip)= WtSet(c)

Lemma 10. If ⊢ v wf, ⊢ v′ wf and ⊢ δ wf, then ′ 1) ∀i ∈ {·, 1, 2}, ι. ⊢ refineLBi(ι, v) wf, ⊢ updi ι v wf and 2) ∀i ∈ {·, 1, 2}, ι, X. ⊢ rfLi(δ, X, ι) wf Proof. By examining the respective definitions and induction for rfL. T ∗ ′ ′ ′ Lemma 11 (Well-formedness preservation). If κ,δ /i c −→ κ ,δ /i c where ⊢ κ,δ /i c wf, ′ ′ ′ then ⊢ κ ,δ /i c wf Proof. By induction of the number of steps in sequence. Base case follows by assumption. Ind: Holds for n steps; To show for n +1 steps, i.e., T n ′ ′ ′ α ′′ ′′ ′′ ′′ ′′ ′′ if κ,δ /i c −→ κ ,δ /i c −→ κ ,δ /i c where ⊢ κ,δ /i c wf, then ⊢ κ ,δ /i c wf By IH ′ ′ ′ (1) ⊢ κ ,δ /i c wf ′ ′ ′ α ′′ ′′ ′′ By (1), T.S. If κ ,δ /i c −→ κ ,δ /i c ′ ′ ′ where ⊢ κ ,δ /i c wf, ′′ ′′ ′′ then ⊢ κ ,δ /i c wf Induction over the derivation. The proof follows from Lemma 9(a) and 10 in most cases. P-SEQ, P-PC use the IH additionally and P-C-PAIR uses Lemma 9(b) additionally.

G. Soundness of Paired-Execution

Lemma 12. ∀x ∈ δ, i ∈{1, 2}, ⌊δ(x)⌋i = ⌊δ⌋i(x) and ⌊rd δ(x)⌋i = rdi δ(x)= rd ⌊δ⌋i(x) Proof. δ(x) can be a pair or normal value Case: δ(x) = (ιu)g g g By store-projection ⌊δ⌋i(x)= ⌊(ιu) ⌋i = (ιu) By definition of rd, rd δ(x) = (ιu)g and g g rdi δ(x) = (ιu) and rd ⌊δ⌋i(x) = (ιu) By projection of values, the conclusion holds. g Case: δ(x)= hι1 u1 | ι2 u2i g By store-projection definition: ⌊δ⌋i(x) = (ιi ui) g By definition of rd, rd δ(x)= hι1 u1 | ι2 u2i and g g rdi δ(x) = (ιi ui) and rd ⌊δ⌋i(x) = (ιi ui) g g By projection of values, ⌊δ(x)⌋i = (ιi ui) and ⌊rd δ(x)⌋i = (ιi ui)

Lemma 13. ∀i ∈{1, 2}, ⌊upd vo vn⌋i = upd ⌊vo⌋i ⌊vn⌋i PROOF (SKETCH). By examining the definitions.

Lemma 14. ∀i ∈{1, 2}, ⌊updL(ι, v)⌋i = updL(ι, ⌊v⌋i). PROOF (SKETCH). By examining the definitions.

Lemma 15. ∀i ∈{1, 2}, ⌊refineLB(Π, v)⌋i = refineLB(⌊Π⌋i, ⌊v⌋i) Proof. Π can be a pair of intervals or single interval and v can be a pair or normal value. ′ ′ g Case: Π= hι1 | ι2i, v = hι1 u1 | ι2; u2i By projection of values, ′ g (1) ⌊v⌋i = (ιi ui) and ⌊Π⌋i = ιi By (1), definition of refineLB, ′′ g (2) refineLB(⌊Π⌋i, ⌊v⌋i) = (ιi ui) where ′ ′′ refine(ιi, ιi) = ( , ιi )

22 By definition of refineLB, ′′′ ′′′ g (3) refineLB(Π, v)= hι1 u1 | ι2 u2i where ′ ′′′ refine(ιi, ιi) = ( , ιi ) By (2), (3) and projection of values, the conclusion holds g Case: Π= hι1 | ι2i, v = (ιu) By projection of values, g (1) ⌊v⌋i = (ιu) and ⌊Π⌋i = ιi By (1), definition of refineLB, ′ g (2) refineLB(⌊Π⌋i, ⌊v⌋i) = (ιi u) where ′ refine(ιi, ι) = ( , ιi) By definition of refineLB, ′ ′ g (3) refineLB(Π, v)= hι1 u | ι2 ui where ′ refine(ιi, ι) = ( , ιi) By (2), (3) and projection of values, the conclusion holds g Case: Π= ι, v = hι1 u1 | ι2; u2i By projection of values, g (1) ⌊v⌋i = (ιi ui) and ⌊Π⌋i = ι By (1), definition of refineLB, ′ g (2) refineLB(⌊Π⌋i, ⌊v⌋i) = (ιi ui) where ′ refine(ι, ιi) = ( , ιi) By definition of refineLB, ′ ′ g (3) refineLB(Π, v)= hι1 u1 | ι2 u2i where ′ refine(ι, ιi) = ( , ιi) By (2), (3) and projection of values, the conclusion holds g Case: Π= ιc, v = (ιu) By projection of values, g (1) ⌊v⌋i = (ιu) and ⌊Π⌋i = ιc By (1), definition of refineLB, ′ g (2) refineLB(⌊Π⌋i, ⌊v⌋i) = (ι u) where ′ refine(ιc, ι) = ( , ι ) By definition of refineLB, (3) refineLB(Π, v) = (ι′ u)g where ′ refine(ιc, ι) = ( , ι ) By (2), (3) and projection of values, the conclusion holds

Lemma 16. ∀{i, j}∈{1, 2}, ⌊refineLBi(Π, v)⌋i = refineLB(⌊Π⌋i, ⌊v⌋i) ∧⌊refineLBi(Π, v)⌋j = ⌊v⌋j Proof. Π can be a pair of intervals or single interval and v can be a pair or normal value. We show for i =1, j =2. g Case: Π= hιc1 | ιc2i, v = hι1 u1 | ι2; u2i By projection of values, g g (1) ⌊Π⌋1 = ιc1, ⌊v⌋1 = (ι1 u1) and ⌊v⌋2 = (ι2 u2) ′ (2) Let refine(ιc1, ι1) = ( , ιi) By (1), definition of refineLBi, ′ g (2) refineLB1(⌊Π⌋1, ⌊v⌋1)= hι1 u1 | ι1 u1i By definition of refineLBi, ′ g (3) refineLB1(Π, v)= hι1 u1 | ι2 u2i By (1), (2), (3) and projection of values,

(4) ⌊refineLB1(Π, v)⌋1 = refineLB1(⌊Π⌋1, ⌊v⌋1) and ⌊refineLB1(Π, v)⌋2 = ⌊v⌋2 g Case: Π= hιc1 | ιc2i, v = (ιu) By projection of values, g g (1) ⌊Π⌋1 = ιc1, ⌊v⌋1 = (ιu) and ⌊v⌋2 = (ιu) ′ (2) Let refine(ιc1, ι) = ( , ι ) By (1), definition of refineLBi, ′ g (2) refineLB1(⌊Π⌋1, ⌊v⌋1)= hι u | ιui By definition of refineLBi,

23 ′ g (3) refineLB1(Π, v)= hι u | ιui By (1), (2), (3) and projection of values,

(4) ⌊refineLB1(Π, v)⌋1 = refineLB1(⌊Π⌋1, ⌊v⌋1) ′ g g = (ι u) and ⌊refineLB1(Π, v)⌋2 = ⌊v⌋2 = (ιu) g Case: Π= ι, v = hι1 u1 | ι2; u2i By projection of values, g g (1) ⌊Π⌋1 = ι, ⌊v⌋1 = (ι1 u1) and ⌊v⌋2 = (ι2 u2) ′ (2) Let refine(ι, ι1) = ( , ι1) By (1), definition of refineLBi, ′ g (2) refineLB1(⌊Π⌋1, ⌊v⌋1)= hι1 u1 | ιu1i By definition of refineLBi, ′ g (3) refineLB1(Π, v)= hι1 u1 | ι2 u2i By (1), (2), (3) and projection of values,

(4) ⌊refineLB1(Π, v)⌋1 = refineLB1(⌊Π⌋1, ⌊v⌋1) ′ g g = (ι1 u1) and ⌊refineLB1(Π, v)⌋2 = ⌊v⌋2 = (ι2 u2) g Case: Π= ιc, v = (ιu) By projection of values, g g (1) ⌊Π⌋1 = ιc, ⌊v⌋1 = (ιu) and ⌊v⌋2 = (ιu) ′ (2) Let refine(ιc, ι) = ( , ι ) By (1), definition of refineLBi, ′ g (2) refineLB1(⌊Π⌋1, ⌊v⌋1)= hι u | ιui By definition of refineLBi, ′ g (3) refineLB1(Π, v)= hι u | ιui By (1), (2), (3) and projection of values,

(4) ⌊refineLB1(Π, v)⌋1 = refineLB1(⌊Π⌋1, ⌊v⌋1) ′ g g = (ι u) and ⌊refineLB1(Π, v)⌋2 = ⌊v⌋2 = (ιu)

Lemma 17. ∀δ, X, x.x ∈ X =⇒ x ∈ δ, we have ∀{i, j}∈{1, 2}, ⌊rfLi(δ, X, Π)⌋i = rfL(⌊δ⌋i,X, ⌊Π⌋i) and ⌊rfLi(δ, X, Π)⌋j = ⌊δ⌋j Proof. By induction on the size of X and applying Lemma 16

Lemma 18. ∀δ, X.X ⊆ δ, we have ∀i ∈{1, 2}, ⌊rfL(δ, X, Π)⌋i = rfL(⌊δ⌋i,X, ⌊Π⌋i) Proof. By induction on the size of X and applying Lemma 15 Lemma 19. If v is not a pair, then 1) ∀ι, ι ⊲⊳ v is not a pair 2) ∀ι, refineLB(ι, v) is not a pair 3) ∀ι, updL(ι, v) is not a pair Proof. By examining the respective definitions.

Lemma 20. If ∀i ∈{1, 2}, E :: δ /i e ⇓ vi and ⊢ δ /i e wf, then ⌊δ⌋i / e ⇓ vi and vi is not a pair Proof. By induction on the structure of E. Case: P-CONST By P-CONST, g g (1) ∀i ∈{1, 2}, ⌊δ⌋i / (ιu) ⇓ (ιu) Case: P-VAR By P-VAR (1) ∀i ∈{1, 2}, ⌊δ⌋i / x ⇓ rd⌊δ⌋i(x) δ(x) is either a pair or normal value: g Subcase I: δ(x)= hv1 | v2i By definition of rd and value projection (I1) rdiδ(x)= vi By (1), definition of store projection and rd (I2) ⌊δ⌋i(x)= vi and rd vi = vi By (I1) and (I2), rdiδ(x)= rd⌊δ⌋i(x)

24 As ⊢ δ /i e wf, δ(x) cannot have nested pairs. Hence, vi is not a pair Subcase II: δ(x)= v = (ιu)g By definition of rd and value projection (II1) rdiδ(x)= v; v is a normal value and not a pair By (1), definition of store projection and rd (II2) ⌊δ⌋i(x)= v and rd v = v By (II1) and (II2), rdiδ(x)= rd⌊δ⌋i(x) Case: P-BOP

δ /i e1 ⇓ v1 δ /i e2 ⇓ v2 v = v1 bop v2

(1) δ /i e1 bop e2 ⇓ v By IH (2) ∀i ∈{1, 2}, ⌊δ⌋i / e1 ⇓ v1 and ⌊δ⌋i / e2 ⇓ v2 and v1 and v2 are not pairs By (2), P-BOP and binary operation on values, the conclusion holds Case: P-CAST

′ δ /i e ⇓ v v = (E,g) ⊲ v g ′ (1) δ /i E e ⇓ v By IH (2) ∀i ∈{1, 2}, ⌊δ⌋i / e ⇓ v and v is not a pair ′ (3) Let v = (ιu)g , then v′ = (ι′ u)g such that ι′ = ι ⊲⊳ E By (2), (3) and P-CAST, the conclusion holds

α ′ ′ ′ ′ ′ ′ Lemma 21. If κ,δ/ c −→ κ ,δ / c , where κ =¯κ ⊲ ιpc gpc, then ∃κ¯ s.t. κ =κ ¯ ⊲ ιpc gpc Proof. By induction on the structure of the derivation.

α ′ ′ ′ ⌊α⌋i ′ ′ ′ ′ Lemma 22. If ∀{i, j}∈{1, 2}, κ,δ /i c −→ κ ,δ /i c , ⊢ κ,δ /i c wf then κ, ⌊δ⌋i / c −→ κ , ⌊δ ⌋i / c , ⌊δ⌋j = ⌊δ ⌋j and ⌊α⌋j = · Proof. By induction on the structure of command-evaluation derivation. Case: P-SEQ α ′ ′ ′ κ,δ /i c1 −→ κ ,δ /i c1 α ′ ′ ′ κ,δ /i c1; c2 −→ κ ,δ /i c1; c2 By IH (1) ∀{i, j}∈{1, 2}, κ, ⌊δ⌋i / c1 ⌊α⌋i ′ ′ ′ −→ κ , ⌊δ ⌋i / c1, ′ ⌊δ⌋j = ⌊δ ⌋j and ⌊α⌋j = ·, By (1) and definition of P-SEQ ⌊α⌋i (2) ∀{i, j}∈{1, 2}, κ, ⌊δ⌋i / c1; c2 −→ ′ ′ ′ κ , ⌊δ ⌋i / c1; c2 ′ and ⌊δ⌋j = ⌊δ ⌋j and ⌊α⌋j = ·, Case: P-PC α ′ ′ ′ κ,δ /i c −→ κ ,δ /i c α ′ ′ ′ κ ⊲ ιpc gpc,δ/i {c} −→ κ ⊲ ιpc gpc,δ /i {c } By IH ⌊α⌋i ′ ′ ′ (1) ∀{i, j}∈{1, 2}, κ, ⌊δ⌋i / c −→ κ , ⌊δ ⌋i / c and ′ ⌊δ⌋j = ⌊δ ⌋j and ⌊α⌋j = ·, By (1) and definition of P-PC, the conclusion holds Case: P-POP, P-SKIP,P-IF, P-WHILE By definition of P-POP, P-SKIP,P-IF, P-WHILE

25 Case: P-ASSIGN By Lemma 20 (1) ∀i ∈{1, 2}, ⌊δ⌋i / e ⇓ v0 such that v0 = v and v is not a pair By definition of P-ASSIGN and Lemma 19, ′ ′ ′ (1a) v = v0 where v0 is obtained by operations on v0 and is not a pair By assumption ′ ′ (2) δ = δ[x 7→ updi δ(x) v ], By (1), and definition of P-ASSIGN, ′′ ′ (2) δ = ⌊δ⌋i[x 7→ upd ⌊δ⌋i(x) v ], ′ ′′ ′ ′′ T.S. ⌊δ ⌋i = δ or ∀x.⌊δ (x)⌋i = δ (x) We show for i =1, j =2, similar for i =2, j =1 Subcase I: Suppose i =1, j =2, v′ = (ιu)g g and δ(x)= hι1 u1 | ι2 u2i By store projection g g (I1) ⌊δ⌋1(x) = (ι1 u1) and ⌊δ⌋2(x) = (ι2 u2) By definition of upd and value projection ′ ′ g (I2) δ (x)= hι u | ι2 u2i ′ ′ g where restrictLB(ι1, ι)= ι and ⌊δ ⌋2(x) = (ι2 u2) By (I1), definition of upd ′′ ′′ g ′′ (I3) δ (x) = (ι u) where restrictLB(ι1, ι) = ( , ι ) ′ ′′ ′ By (I2) and (I3), ⌊δ (x)⌋1 = δ (x), ⌊δ⌋2(x)= ⌊δ ⌋2(x) and ∀y.y 6= x =⇒ ⌊δ(y)⌋i = ⌊δ⌋i(y) ′ g g Subcase II: Suppose i =1, j =2, v = (ιu) and δ(x) = (ι1 u1) By store projection g g (I1) ⌊δ⌋1(x) = (ι1 u1) and ⌊δ⌋2(x) = (ι1 u1) By definition of upd and value projection ′ ′ g ′ ′ g (I2) δ (x)= hι u | ι1 u1i where restrictLB(ι1, ι) = ( , ι ) and ⌊δ ⌋2(x) = (ι1 u1) By (I1), definition of upd ′′ ′′ g ′′ (I3) δ (x) = (ι u) where restrictLB(ι1, ι) = ( , ι ) ′ ′′ ′ By (I2) and (I3), ⌊δ (x)⌋1 = δ (x), ⌊δ⌋2(x)= ⌊δ ⌋2(x) and ∀y.y 6= x =⇒ ⌊δ(y)⌋i = ⌊δ⌋i(y) Case: P-OUT By Lemma 20, (1) ∀i ∈{1, 2}, ⌊δ⌋i / e ⇓ v0 such that v0 = v and v is not a pair By definition of P-OUT and Lemma 19, ′ ′ (1a) v1 = v1 where v1 is obtained by operations on v0 and is not a pair By definition of trace-projection, (2) ⌊i,ℓ,v1⌋i = (ℓ, v1) and ⌊i,ℓ,v1⌋j = · where i 6= j Case: P-IF-REFINE By Lemma 20 (1) ∀i ∈{1, 2}, ⌊δ⌋i / e ⇓ v and v is not a pair, By Lemma 18 (2) ∀{i, j}∈{1, 2}, ⌊rfLi(δ, X, ιpc g intvl (v))⌋i = rfL(⌊δ⌋i,X,ιpc g intvl (v)) and ⌊rfLi(δ, X, ιpc g intvl (v))⌋j = ⌊δ⌋j By (1), (2) and definition of P-IF-REFINE, the conclusion holds

Lemma 23 (Expression soundness). If E :: δ/e ⇓ v and ⊢ δ/e wf then ∀i ∈{1, 2}, ⌊δ/e⌋i ⇓⌊v⌋i Proof. By induction on the structure of E. Case: P-CONST By P-CONST and projection of values Case: P-VAR By assumption (1) v = rd δ(x) T.S. ∀i ∈{1, 2}, rd ⌊δ⌋i(x)= ⌊rd δ(x)⌋i

26 We show for i =1, the proof is similar for i =2 g Subcase I: δ(x)= hι1 u1 | ι2 u2i By definition of rd g (I1) ⌊rd δ(x)⌋1 = (ι1 u1) By store-projection definition and definition of rd g (I2) rd ⌊δ⌋1(x) = (ι1 u1) By (I1) and (I2), the conclusion holds Subcase II: δ(x) = (ιu)g By definition of rd g (II1) ⌊rd δ(x)⌋1 = (ιu) By store-projection definition and definition of rd g (II2) rd ⌊δ⌋1(x) = (ιu) By (II1) and (II2), the conclusion holds Case: P-BOP δ/e1 ⇓ v1 δ/e2 ⇓ v2 v = v1 bop v2

(1) δ/e1 bop e2 ⇓ v By (1) and IH (2) ∀i ∈{1, 2}, ⌊δ⌋i / e1 ⇓⌊v1⌋i and ⌊δ⌋i / e2 ⇓⌊v2⌋i T.S. ∀i ∈{1, 2}, ⌊v1⌋i bop ⌊v2⌋i = ⌊v1 bop v2⌋i We show for i =1, the proof is similar for i =2 ′ ′ g1 ′ ′ g2 Subcase I: v1 = hι1 u1 | ι1 u1i , v2 = hι2 u2 | ι2 u2i By definition of bop, g g (I1) v1 bop v2 = hιu | i and ⌊v1 bop v2⌋1 = (ιu) where ι = ι1 g ι2, u = u1 bop u2 and g = g1 gc g2 By value-projection definition g g (I2) ⌊v1⌋1 = (ι1 u1) and ⌊v2⌋1 = (ι2 u2) By (I2) and definition of bop, g (I3) ⌊v1⌋1 bop ⌊v2⌋1 = (ιu) where ι = ι1 g ι2, u = u1 bop u2 and g = g1 gc g2 By (I1) and (I3), the conclusion holds ′ ′ g1 g2 g1 ′ ′ g2 Subcase II: v1 = hι1 u1 | ι1 u1i , v2 = (ι2 u2) , similar for v1 = (ι1 u1) , v2 = hι2 u2 | ι2 u2i , By definition of bop, g g (II1) v1 bop v2 = hιu | i and ⌊v1 bop v2⌋1 = (ιu) where ι = ι1 g ι2, u = u1 bop u2 and g = g1 gc g2 By value-projection definition g g (II2) ⌊v1⌋1 = (ι1 u1) and ⌊v2⌋1 = (ι2 u2) By (II2) and definition of bop, g (II3) ⌊v1⌋1 bop ⌊v2⌋1 = (ιu) where ι = ι1 g ι2, u = u1 bop u2 and g = g1 gc g2 By (II1) and (II3), the conclusion holds g1 g2 Subcase III: v1 = (ι1 u1) , v2 = (ι2 u2) By definition of bop, g g (III1) v1 bop v2 = (ιu) and ⌊v1 bop v2⌋1 = (ιu) where ι = ι1 g ι2, u = u1 bop u2 and g = g1 gc g2 By value-projection definition g g (III2) ⌊v1⌋1 = (ι1 u1) and ⌊v2⌋1 = (ι2 u2) By (III2) and definition of bop, g (III3) ⌊v1⌋1 bop ⌊v2⌋1 = (ιu) where ι = ι1 g ι2, u = u1 bop u2 and g = g1 gc g2 By (III1) and (III3), the conclusion holds Case: P-CAST δ/e ⇓ v v′ = (E,g) ⊲ v (1) δ / Ege ⇓ v′ By IH and (1) (2) ∀i ∈{1, 2}, ⌊δ/e⌋i ⇓⌊v⌋i We show for i =1, the proof is similar for i =2 g′ Subcase I: v = hι1 u1 | ι2 u2i , By definition of ⊲ cast operation, ′ ′ ′ g ′ ′ g ′ (I1) v = hι1 u1 | ι2 u2i and ⌊v ⌋1 = (ι1 u1) where ι1 = ι1 ⊲⊳ E By value-projection definition and cast operation,

27 ′ g ′′ ′′ g ′′ (I2) ⌊v⌋1 = (ι1 u1) and v1 = (ι1 u1) where ι1 = ι1 ⊲⊳ E By (I1) and (I2), the conclusion holds ′ Subcase II: v = (ιu)g , By definition of cast ′ ′ g ′ ′ g ′ (II1) v = (ι u) and ⌊v ⌋1 = (ι u) where ι = ι ⊲⊳ E By definition of value-projection and cast ′ g ′′ ′′ g ′′ (II2) ⌊v⌋1 = (ιu) and v = (ι u) where ι = ι ⊲⊳ E By (II1) and (II2), the conclusion holds

α Lemma 24 (Soundness). If κ,δ/ c −→ κ′,δ′ / c′ where ⊢ κ,δ/ c wf, ⌊α⌋i ′ ′ ′ ′ ′ ′ then ∀i ∈{1, 2}, ⌊κ,δ/ c⌋i −→ ⌊κ ,δ / c ⌋i, or ⌊κ,δ/ c⌋i = ⌊κ ,δ / c ⌋i and ⌊α⌋i = · Proof. By induction on the structure of the command derivation. Case: P-SEQ α ′ ′ ′ κ,δ/ c1 −→ κ ,δ / c1 α ′ ′ ′ κ,δ/ c1; c2 −→ κ ,δ / c1; c2 By IH ⌊α⌋i ′ ′ ′ ′ ′ ′ (1) ∀i ∈{1, 2}, ⌊κ,δ/ c1⌋i −→ ⌊κ ,δ / c1⌋i, or ⌊κ,δ/ c1⌋i = ⌊κ ,δ / c1⌋i By (1), projection of commands and definition of P-SEQ ⌊α⌋i ′ ′ ′ ′ ′ ′ (2) ∀i ∈{1, 2}, ⌊κ,δ/ c1; c2⌋i −→ ⌊κ ,δ / c1; c2⌋i, or ⌊κ,δ/ c1; c2⌋i = ⌊κ ,δ / c1; c2⌋i Case: P-PC α κ,δ/ c −→ κ′,δ′ / c′ α ′ ′ ′ κ ⊲ ιpc gpc,δ/ {c} −→ κ ⊲ ιpc gpc,δ / {c } By IH ⌊α⌋i ′ ′ ′ ′ ′ ′ (1) ∀i ∈{1, 2}, ⌊κ,δ/ c⌋i −→ ⌊κ ,δ / c ⌋i, or ⌊κ,δ/ c⌋i = ⌊κ ,δ / c ⌋i By (1), projection of commands and definition of P-PC ⌊α⌋i ′ ′ ′ (2) ∀i ∈{1, 2}, ⌊κ ⊲ ιpc gpc,δ/ {c}⌋i −→ ⌊κ ⊲ ιpc gpc,δ / {c }⌋i ′ ′ ′ or ⌊κ ⊲ ιpc gpc,δ/ {c}⌋i = ⌊κ ⊲ ιpc gpc,δ / {c }⌋i Case: P-POP, P-SKIP,P-IF, P-WHILE By projection of commands, well-formedness definition and definition of P-POP, P-SKIP,P-IF, P-WHILE Case: P-ASSIGN By Lemma 23 (1) ∀i ∈{1, 2}, ⌊δ/e⌋i ⇓ vi such that vi = ⌊v⌋i, By projection of interval operations, Lemma 15, ′ ′ ′ ′ (2) ∀i ∈{1, 2}, v = refineLB(ιpc, v) and vi = refineLB(ιpc, ⌊v⌋i) and ⌊v ⌋i = vi, By (2), ′ ′ (3) ⌊δ (x)⌋i = ⌊δ ⌋i(x) By (1), projection of commands and definition of P-ASSIGN, ′ ′ ′ ′ (4) δ (x)= upd δ(x) v and δi(x)= upd ⌊δ⌋i(x) vi; By (3), (4) and Lemma 13, the conclusion follows Case: P-OUT By Lemma 23 (1) ∀i ∈{1, 2}, ⌊δ/e⌋i ⇓⌊v⌋i, By projection of interval operations, Lemmas 14 and 15, ′ ′′ ′ (2) ∀i ∈{1, 2}, v = refineLB(ιpc, v), v = updL([ℓ,ℓ], v ) ′′ ′ ′ ′′ ′′ vi = ⌊updL([ℓ,ℓ], v )⌋i = updL([ℓ,ℓ], ⌊v ⌋i), and ⌊v ⌋i = vi By (1), (2), projection of commands and traces, and definition of P-OUT, ′′ ′′ (3) ∀i ∈{1, 2}, ⌊(ℓ, v )⌋i = (ℓ, vi ), Case: P-IF-REFINE By Lemma 23 (1) ∀i ∈{1, 2}, ⌊δ/e⌋i ⇓⌊v⌋i, By Lemma 18

28 (2) ∀i ∈{1, 2}, ⌊rfL(δ, X, ιpc g intvl (v))⌋i = rfL(⌊δ⌋i,X,ιpc g intvl (⌊v⌋i)) By (1), (2), projection of commands and definition of P-IF-REFINE, the conclusion holds

Case: P-C-PAIR where c1 and c2 are not skip We show for i =1, j =2. The proof is similar for i =2, j =1 By assumption and Lemma 22 α ′ ′ ′ (1) κ1 ⊲ (ιpc g ι1) (g gc gpc), ⌊δ⌋1 / c1 −→ κ1 ⊲ (ιpc g ι1) (g gc gpc), ⌊δ ⌋1 / c1, ′ ′ ′ and κ2 = κ2, c2 = c2, ⌊δ⌋2 = ⌊δ ⌋2 By projection of commands (2) ⌊ιpc gpc,δ/ hκ1, ι1,c1 | κ2, ι2,c2ig⌋1 = κ1 ⊲ (ιpc g ι1) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋1 / {c1} ′ ′ ′ ′ ′ ′ ′ ′ (3) ⌊ιpc gpc,δ / hκ1, ι1,c1 | κ2, ι2,c2ig⌋1 = κ1 ⊲ (ιpc g ι1) (gpc gc g) ⊲ ιpc gpc, ⌊δ ⌋1 / {c1} (4) ⌊ιpc gpc,δ/ hκ1, ι1,c1 | κ2, ι2,c2ig⌋2 = κ2 ⊲ (ιpc g ι2) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋2 / {c2} ′ ′ ′ ′ ′ (5) ⌊ιpc gpc,δ / hκ1, ι1,c1 | κ2, ι2,c2ig⌋2 = κ2 ⊲ (ιpc g ι2) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋2 / {c2} By definition of P-PC α ′ ′ ′ α ′ ′ ′ (6) If κ,δ/ c −→ κ ,δ / c then κ ⊲ ιpc gpc,δ/ {c} −→ κ ⊲ ιpc gpc,δ / {c } By (1), (2), (3) and (6) α ′ ′ ′ (7) κ1 ⊲ (ιpc g ι1) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋1 / {c1} −→ κ1 ⊲ (ιpc g ι1) (gpc gc g) ⊲ ιpc gpc, ⌊δ ⌋1 / {c1} By (4), (5) ′ ′ ′ (8) κ2 ⊲ (ιpc g ι2) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋2 / {c2} = κ2 ⊲ (ιpc g ι2) (gpc gc g) ⊲ ιpc gpc, ⌊δ ⌋2 / {c2} By (7) and (8), the conclusion holds

Case: P-C-PAIR where c1 = skip and c2 is not skip. Similar for the symmetric case. We show for i =2, j =1. By assumption and Lemma 22 α ′ ′ ′ (1) κ2 ⊲ (ιpc g ι2) (g gc gpc), ⌊δ⌋2 / c2 −→ κ2 ⊲ (ιpc g ι2) (g gc gpc), ⌊δ ⌋2 / c2, ′ ′ and κ1 = κ1, ⌊δ⌋1 = ⌊δ ⌋1 By projection of commands (2) ⌊ιpc gpc,δ/ hκ1, ι1, skip | κ2, ι2,c2ig⌋1 = κ1 ⊲ (ιpc g ι1) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋1 / skip ′ ′ ′ ′ (3) ⌊ιpc gpc,δ / hκ1, ι1, skip | κ2, ι2,c2ig⌋1 = κ1 ⊲ (ιpc g ι1) (gpc gc g) ⊲ ιpc gpc, ⌊δ ⌋1 / skip (4) ⌊ιpc gpc,δ/ hκ1, ι1, skip | κ2, ι2,c2ig⌋2 = κ2 ⊲ (ιpc g ι2) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋2 / {c2} ′ ′ ′ ′ ′ ′ (5) ⌊ιpc gpc,δ / hκ1, ι1, skip | κ2, ι2,c2ig⌋2 = κ2 ⊲ (ιpc g ι2) (gpc gc g) ⊲ ιpc gpc, ⌊δ ⌋2 / {c2} By P-PC α κ,δ/ c −→ κ′,δ′ / c′ α ′ ′ ′ (6) κ ⊲ ιpc gpc,δ/ {c} −→ κ ⊲ ιpc gpc,δ / {c } By (1), (4), (5) and (6) α ′ ′ ′ (7) κ2 ⊲ (ιpc g ι2) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋2 / {c2} −→ κ2 ⊲ (ιpc g ι2) (gpc gc g) ⊲ ιpc gpc, ⌊δ ⌋2 / {c2} By (1), (2), (3) ′ (8) κ1 ⊲ (ιpc g ι1) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋1 / skip = κ1 ⊲ (ιpc g ι1) (gpc gc g) ⊲ ιpc gpc, ⌊δ ⌋1 / skip By (7) and (8), the conclusion holds Case: P-SKIP-PAIR By projection of commands (1) ⌊ιpc gpc,δ/ h∅, ι1, skip |∅, ι2, skipig⌋i = (ιpc g ιi) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋i / {skip} By definition of P-POP (2) ιpc gpc ⊲ κ,δ / {skip} −→ κ,δ / skip By (1), (2) (3) ⌊ιpc gpc,δ/ h∅, ι1, skip |∅, ι2, skipig⌋i −→ ιpc gpc, ⌊δ⌋i / skip By (3) and projection of commands, the conclusion holds Case: P-LIFT-IF By P-LIFT-IF g (1) ιpc gpc,δ/ if hι1 u1 | ι2 u2i then c1 else c2 −→ ιpc gpc,δ/ h∅, ι1,cj |∅, ι2,ckig By projection of commands g g (2) ⌊ιpc gpc,δ/ if hι1 u1 | ι2 u2i then c1 else c2⌋i = ιpc gpc, ⌊δ⌋i / if (ιi ui) then c1 else c2 (3) ⌊ιpc gpc,δ/ h∅, ι1,cj |∅, ι2,ckig⌋1 = (ιpc g ι1) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋1 / {cj} where cj is c1 if u1 = true and cj is c2 if u1 = false (4) ⌊ιpc gpc,δ/ h∅, ι1,cj |∅, ι2,ckig⌋2 = (ιpc g ι2) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋2 / {ck} where ck is c1 if u2 = true and cj is c2 if u2 = false By P-IF g (5) ιpc gpc, ⌊δ⌋1 / if(ι1 u1) then c1 else c2 −→ (ιpc g ι1) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋1 / {cj}

29 where cj is c1 if u1 = true and cj is c2 if u1 = false g (6) ιpc gpc, ⌊δ⌋2 / if(ι2 u2) then c1 else c2 −→ (ιpc g ι2) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋2 / {ck} where ck is c1 if u2 = true and ck is c2 if u2 = false By (2-6), the conclusion holds

T Theorem 8 (Soundness). If κ,δ/ c −→∗ κ′,δ′ / c′ where ⊢ κ,δ/ c wf, ⌊T⌋i ∗ ′ ′ ′ then ∀i ∈{1, 2}, ⌊κ,δ/ c⌋i −→ ⌊κ ,δ / c ⌋i, Proof. By induction on the number of steps in the sequence. Base case follows from assumption. Inductive Case: Holds for n steps; To show for n +1 steps, i.e., T α if κ,δ/ c −→n κ′,δ′ / c′ −→ κ′′,δ′′ / c′′, Ti j αi ′′ ′′ ′′ then ∀i ∈{1, 2}, ⌊κ,δ/ c⌋i −→ κ0i,δ0i / c0i −→ κ1i,δ1i / c1i, such that ⌊κ ,δ /c ⌋i = κ1i,δ1i / c1i By induction hypothesis, ′ ′ ′ (1) ∀i ∈{1, 2},κ0i,δ0i / c0i = ⌊κ ,δ / c ⌋i and Ti = ⌊T⌋i By Lemma 24, Lemma 11, (1) and projection of traces, the conclusion holds

H. Completeness of Paired-Execution ′ ′ ′ Lemma 25 (Expression Completeness). If ∀i ∈{1, 2}, ⌊δ⌋i / e ⇓ vi, then ∃v s.t. δ/e ⇓ v with ⌊v ⌋i = vi Proof. By induction on the structure of the expression-evaluation derivation. Case: P-CONST By P-CONST and projection of values Case: P-VAR By assumption ′ (1) vi = rd ⌊δ⌋i(x) and v = rd δ(x) By (1) and Lemma 12, ′ (2) ⌊rd δ(x)⌋i = rd ⌊δ⌋i(x) and ⌊v ⌋i = vi Case: P-BOP ⌊δ⌋i / e1 ⇓ v1i ⌊δ⌋i / e2 ⇓ v2i vi = v1i bop v2i

(1) ⌊δ⌋i / e1 bop e2 ⇓ vi By (1) and IH (2) δ/e1 ⇓ v1, δ/e2 ⇓ v2, v1i = ⌊v1⌋i and v2i = ⌊v2⌋i T.S. ∀i ∈{1, 2}, ⌊v1 bop v2⌋i = ⌊v1⌋i bop ⌊v2⌋i We show for i =1, the proof is similar for i =2 ′ ′ g1 ′ ′ g2 Subcase I: v1 = hι1 u1 | ι1 u1i , v2 = hι2 u2 | ι2 u2i By definition of bop, g g (I1) v1 bop v2 = hιu | i and ⌊v1 bop v2⌋1 = (ιu) where ι = ι1 g ι2, u = u1 bop u2 and g = g1 gc g2 By value-projection definition g g (I2) ⌊v1⌋1 = (ι1 u1) and ⌊v2⌋1 = (ι2 u2) By (I2) and definition of bop, g (I3) ⌊v1⌋1 bop ⌊v2⌋1 = (ιu) where ι = ι1 g ι2, u = u1 bop u2 and g = g1 gc g2 By (I1) and (I3), the conclusion holds ′ ′ g1 g2 g1 ′ ′ Subcase II: v1 = hι1 u1 | ι1 u1i , v2 = (ι2 u2) , similarly for v1 = (ι1 u1) , v2 = hι2 u2 | ι2 u2ig2 , By definition of bop, g g (II1) v1 bop v2 = hιu | i and ⌊v1 bop v2⌋1 = (ιu) where ι = ι1 g ι2, u = u1 bop u2 and g = g1 gc g2 By value-projection definition g g (II2) ⌊v1⌋1 = (ι1 u1) and ⌊v2⌋1 = (ι2 u2) By (II2) and definition of bop, g (II3) ⌊v1⌋1 bop ⌊v2⌋1 = (ιu) where ι = ι1 g ι2, u = u1 bop u2 and g = g1 gc g2 By (II1) and (II3), the conclusion holds g1 g2 Subcase III: v1 = (ι1 u1) , v2 = (ι2 u2)

30 By definition of bop, g g (III1) v1 bop v2 = (ιu) and ⌊v1 bop v2⌋1 = (ιu) where ι = ι1 g ι2, u = u1 bop u2 and g = g1 gc g2 By value-projection definition g g (III2) ⌊v1⌋1 = (ι1 u1) and ⌊v2⌋1 = (ι2 u2) By (III2) and definition of bop, g (III3) ⌊v1⌋1 bop ⌊v2⌋1 = (ιu) where ι = ι1 g ι2, u = u1 bop u2 and g = g1 gc g2 By (III1) and (III3), the conclusion holds Case: P-CAST ′ ⌊δ⌋i / e ⇓ vi vi = (E,g) ⊲ vi g ′ (1) ⌊δ⌋i / E e ⇓ vi By IH and (1) (2) ∀i ∈{1, 2}, δ/e ⇓ v and ⌊v⌋i = vi We show for i =1, the proof is similar for i =2 g′ Subcase I: v = hι1 u1 | ι2 u2i , By definition of ⊲ cast operation, ′ ′ ′ g ′ ′ g ′ (I1) v = hι1 u1 | ι2 u2i and ⌊v ⌋1 = (ι1 u1) where ι1 = ι1 ⊲⊳ E By value-projection definition and cast operation, ′ g ′ ′′ g ′′ (I2) ⌊v⌋1 = (ι1 u1) and v1 = (ι1 u1) where ι1 = ι1 ⊲⊳ E By (I1) and (I2), the conclusion holds ′ Subcase II: v = (ιu)g , By definition of cast ′ ′ g ′ ′ g ′ (II1) v = (ι u) and ⌊v ⌋1 = (ι u) where ι = ι ⊲⊳ E By definition of value-projection and cast ′ g ′′ ′′ g ′′ (II2) ⌊v⌋1 = (ιu) and v1 = (ι u) where ι = ι ⊲⊳ E ′ ′′ By (II1) and (II2), ⌊v ⌋1 = v1

Lemma 26. If ⊢ κ,δ/ c wf and c does not contain pairs or braces, then ∀i ∈{1, 2}, ⌊κ,δ/ c⌋i = κ, ⌊δ⌋i / c PROOF (SKETCH). By induction on the structure of c. Most cases use the projection of commands and respective rules. c1; c2 use the IH additionally. αi ′ ′ ′ ′ ′ ′ Lemma 27. If ∀i ∈ {1, 2}, ⌊κ,δ/ c⌋i −→ κi,δi / ci or ⌊κ,δ/ c⌋i = κ0,δ0 / skip, and ⊢ κ,δ / c wf then ∃κ ,δ ,c s.t. T ∗ ′ ′ ′ ′ ′ ′ ′ ′ ′ T κ,δ/ c −→ κ ,δ / c with ⌊κ ,δ / c ⌋i = κi,δi / ci and ⌊ ⌋i = αi

Proof. By induction on the structure of c. If ⌊κ,δ/ c⌋1 = κ0,δ0 / skip and ⌊κ,δ/ c⌋2 = κ0,δ0 / skip, then c = skip (from the projection of command-configurations). If c = skip, then κ,δ/ c takes 0 steps and the conclusion follows from the assumption. If at least one of the projected runs steps:

Case: c = c1; c2 By projection of commands, ⌊κ,δ/ c1⌋i = κi,δi / c1i

(1) ⌊κ,δ/ c1; c2⌋i = κi,δi / c1i; c2 By P-SEQ αi ′ ′ ′ κi,δi / c1i −→ κi,δi / c1i αi ′ ′ ′ (2) κi,δi / c1i; c2 −→ κi,δi / c1i; c2 By (2), αi ′ ′ ′ (3) ⌊κ,δ/ c1⌋i −→ κi,δi / c1i By (3) and IH, T ∗ ′ ′ ′ ′ ′ ′ ′ ′ ′ T (4) κ,δ/ c1 −→ κ ,δ / c1 and ∀i ∈{1, 2}, ⌊κ ,δ / c1⌋i = κi,δi / c1i and ⌊ ⌋i = αi, (or) ⌊κ,δ/ c1⌋i = κ0,δ0 / skip By (1), (2), (4) ′ ′ ′ ′ ′ ′ T (5) ∀i ∈{1, 2}, ⌊κ ,δ / c1; c2⌋i = κi,δi / c1i; c2, and ⌊ ⌋i = αi By (5), the conclusion holds Case: c = {c} By projection of commands,

31 ⌊κ,δ/ c⌋i = κi,δi / ci

(1) ⌊κ ⊲ ιpc gpc,δ/ {c}⌋i = κi ⊲ ιpc gpc,δi / {ci} By P-PC, αi ′ ′ ′ κi,δi / ci −→ κi,δi / ci αi ′ ′ ′ (2) κi ⊲ ιpc gpc,δi / {ci} −→ κi ⊲ ιpc gpc,δi / {ci} By (2), IH, T ∗ ′ ′ ′ ′ ′ ′ ′ ′ ′ T (3) κ,δ/ c −→ κ ,δ / c and ∀i ∈{1, 2}, ⌊κ ,δ / c ⌋i = κi,δi / ci and ⌊ ⌋i = αi, By (1), (2) and (3), the conclusion holds Case: c = skip; c By projection of commands, ⌊ιpc gpc,δ/ skip⌋i = ιpc gpc, ⌊δ⌋i / skip

(1) ⌊ιpc gpc,δ/ skip; c⌋i = ιpc gpc, ⌊δ⌋i / skip; c By P-SKIP,

(2) ιpc gpc, ⌊δ⌋i / skip; c −→ ιpc gpc, ⌊δ⌋i / c

(3) ιpc gpc,δ/ skip; c −→ ιpc gpc,δ/c T.S. ⌊ιpc gpc,δ/c⌋i = ιpc gpc, ⌊δ⌋i / c (4) From well-formedness definition, c does not contain pairs or braces From Lemma 26 and (4), the conclusion holds Case: c = {skip} By projection of commands, ⌊ιg,δ/ skip⌋i = ι g, ⌊δ⌋i / skip

(1) ⌊ιg ⊲ ιpc gpc,δ/ {skip}⌋i = ιg ⊲ ιpc gpc, ⌊δ⌋i / {skip} The rule forces κ = ιg By P-POP,

(2) ιg ⊲ ιpc gpc,δ/ {skip} −→ ιpc gpc,δ/ skip

(3) ιg ⊲ ιpc gpc, ⌊δ⌋i / {skip} −→ ιpc gpc, ⌊δ⌋i / skip By (1), (2) and (3), the conclusion holds g Case: c = if(ιb) then c1 else c2 By projection of commands, g g (1) ⌊ιpc gpc,δ/ if (ιb) then c1 else c2⌋i = ιpc gpc, ⌊δ⌋i / if (ιb) then c1 else c2 By P-IF, ′ ′ ιpc = ιpc g ι gpc = gpc gc g cj = c1 if b = true cj = c2 if b = false g ′ ′ (2) ιpc gpc, ⌊δ⌋i / if (ιb) then c1 else c2 −→ ιpc gpc ⊲ ιpc gpc, ⌊δ⌋i / {cj } ′ ′ ιpc = ιpc g ι gpc = gpc gc g cj = c1 if b = true cj = c2 if b = false g ′ ′ (3) ιpc gpc,δ/ if (ιb) then c1 else c2 −→ ιpc gpc ⊲ ιpc gpc,δ/ {cj} Suppose b = true. Similar for b = false ′ ′ ′ ′ T.S. ⌊ιpc gpc ⊲ ιpc gpc,δ/ {c1}⌋i = ιpc gpc ⊲ ιpc gpc, ⌊δ⌋i / {c1} By projection of commands, ′ ′ ′ ′ ′ ′ ⌊ιpc gpc,δ/c1⌋i = ιpc gpc,δ / c1 ′ ′ ′ ′ ′ ′ (4) ⌊ιpc gpc ⊲ ιpc gpc,δ/ {c1}⌋i = ιpc gpc ⊲ ιpc gpc,δ / {c1} (5) By well-formedness definition, c1 does not contain pairs or braces. By Lemma 26 and (5), the conclusion holds Case: c = whileX e do c By projection of commands and P-WHILE Case: c = x := e By projection of commands, ′ ′ ′ ′ ′ ′ T.S. ⌊δ ⌋i = δi where δi = ⌊δ⌋i[x 7→ upd ⌊δ⌋i(x) vi] and δ = δ[x 7→ upd δ(x) v ] By Lemma 25 (1) ∀i ∈{1, 2}, if ⌊δ⌋i / e ⇓ vi, then δ/e ⇓ v such that ⌊v⌋i = vi, By (1), Lemma 15, ′ ′ (2) ⌊v ⌋i = ⌊refineLB(ιpc, v)⌋i = refineLB(ιpc, ⌊v⌋i)= vi By (2), Lemma 13 and 12

32 ′′ ′ ′ ′′ (3) ⌊v ⌋i = ⌊upd δ(x) v ⌋i = upd ⌊δ⌋i(x) ⌊v ⌋i = vi ′ ′′ ′ ′′ (4) δ (x)= v and δi(x)= vi By (3) and (4) the conclusion holds X Case: c = if e then c1 else c2 By projection of commands, ′ ′ ′ ′ T.S. ⌊δ ⌋i = δi where δi = rfL(⌊δ⌋i,X,ιpc g intvl (vi)) and δ = rfL(δ, X, ιpc g intvl (v)) By Lemma 25 (1) ⌊v⌋i = vi, By (1), Lemma 18 (2) ⌊rfL(δ, X, ιpc g intvl (v))⌋i = rfL(⌊δ⌋i,X,ιpc g intvl (⌊v⌋i)) By (1), (2), the conclusion holds Case: c = output(ℓ,e) By projection of commands, ⌊ιpc gpc,δ/ skip⌋i = ιpc gpc, ⌊δ⌋i / skip. ′′ ′′ T.S. ⌊(ℓ, v )⌋i = (ℓ, vi ) By Lemma 25 (1) ∀i ∈{1, 2}, if ⌊δ⌋i / e ⇓ vi, then δ/e ⇓ v such that ⌊v⌋i = vi, By (1), Lemma 15 ′ ′ (2) ⌊v ⌋i = ⌊refineLB(ιpc, v)⌋i = refineLB(ιpc, ⌊v⌋i)= vi By (2),Lemma 14 ′′ ′ ′ ′′ (3) ⌊v ⌋i = ⌊updL([ℓ,ℓ], v )⌋i = updL([ℓ,ℓ], ⌊v ⌋i, [ℓ,ℓ]) = vi By (3) and projection of traces, the conclusion holds

Case: c = hκ1, ι1,c1 | κ2, ι2,c2i where c1 and c2 are not skip By projection of commands (1) ⌊ιpc gpc,δ/ hκ1, ι1,c1 | κ2, ι2,c2ig⌋i = κi ⊲ (ιpc g ιi) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋i / {ci} By assumption, P-PC and (1) αi ′′ ′′ ′′ (2) κi ⊲ (ιpc g ιi) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋i / {ci} −→ κi ⊲ ιpc gpc,δi / {ci } αi ′′ ′′ ′′ (3) κi ⊲ (ιpc g ιi) (gpc gc g), ⌊δ⌋i / ci −→ κi ,δi / ci Suppose i =1, j =2 followed by i =2, j =1. Similar for the symmetric case ′ α ′ ′ ′ (4) ιpc gpc,δ/ hκ1, ι1,c1 | κ2, ι2,c2ig −→ ιpc gpc,δ / hκ1, ι1,c1 | κ2, ι2,c2ig ′′ α ′′ ′ ′ ′ ′ −→ ιpc gpc,δ / hκ1, ι1,c1 | κ2, ι2,c2ig By (4), Lemma 22, ′ ⌊α ⌋1 ′ ′ ′ (5) κ1 ⊲ (ιpc g ι1 gpc gc g), ⌊δ⌋1 / c1 −→ κ1 ⊲ (ιpc g ι1 gpc gc g), ⌊δ ⌋1 / c1, ′ ′ ⌊δ⌋2 = ⌊δ ⌋2 and ⌊α ⌋2 = · ′′ ′ ⌊α ⌋2 ′ ′′ ′ (6) κ2 ⊲ (ιpc g ι2 gpc gc g), ⌊δ ⌋2 / c2 −→ κ2 ⊲ (ιpc g ι2 gpc gc g), ⌊δ ⌋2 / c2, ′ ′′ ′′ ⌊δ ⌋1 = ⌊δ ⌋1 and ⌊α ⌋1 = · α′,α′′ ∗ ′′ ′ ′ ′ ′ (7) ιpc gpc,δ/ hκ1, ι1,c1 | κ2, ι2,c2ig −→ ιpc gpc,δ / hκ1, ι1,c1 | κ2, ι2,c2ig ′′ ′ ′ ′ ′ ′′ ′′ ′′ ′ ′′ T.S. ⌊ιpc gpc,δ / hκ1, ι1,c1 | κ2, ι2,c2ig⌋i = κi ⊲ ιpc gpc,δi / {ci } and ⌊α , α ⌋i = αi By projection of commands, ′′ ′ ′ ′ ′ ′ ′′ ′ (8) ⌊ιpc gpc,δ / hκ1, ι1,c1 | κ2, ι2,c2ig⌋i = κi ⊲ (ιpc g ιi) (gpc gc g) ⊲ ιpc gpc, ⌊δ ⌋i / {ci} ′ ′′ ′′ ′′ ′ ′′ ′ ′′ By (8), T.S. κi ⊲ (ιpc g ιi) (gpc gc g)= κi , ⌊δ ⌋i = δ , ci = ci and ⌊α , α ⌋i = αi By (3), (5), (6) ′′ ′ ′′ ′ ′ ′′ ′ (9) κ1 = κ1 ⊲ (ιpc g ι1) (gpc gc g), δ1 = ⌊δ ⌋1, c1 = c1 , α1 = ⌊α ⌋1 ′′ ′ ′′ ′′ ′ ′′ ′′ (10) κ2 = κ2 ⊲ (ιpc g ι2) (gpc gc g), δ2 = ⌊δ ⌋2, c2 = c2 , α2 = ⌊α ⌋2 By (5), (6), (9), (10) and projection of traces, the conclusion holds

Case: c = hκ1, ι1,c1 | κ2, ι2,c2i where c1 = skip and c2 is not. Similar for c2 = skip and c1 6= skip By projection of commands (1) ⌊ιpc gpc,δ/ hκ1, ι1, skip | κ2, ι2,c2ig⌋1 = κ1 ⊲ (ιpc g ι1) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋1 / skip (2) ⌊ιpc gpc,δ/ hκ1, ι1, skip | κ2, ι2,c2ig⌋2 = κ2 ⊲ (ιpc g ι2) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋2 / {c2} (1) does not proceed as the projection of c gives skip By assumption, P-PC and (2) α2 ′′ ′′ ′′ (3) κ2 ⊲ (ιpc g ι2) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋2 / {c2} −→ κ2 ⊲ ιpc gpc,δ2 / {c2 } α2 ′′ ′′ ′′ (4) κ2 ⊲ (ιpc g ι2) (gpc gc g), ⌊δ⌋2 / c2 −→ κ2 ,δ2 / c2 Suppose i =2, j =1. ′ α ′ ′ ′ ′ (5) ιpc gpc,δ/ hκ1, ι1, skip | κ2, ι2,c2ig −→ ιpc gpc,δ / hκ1, ι1, skip | κ2, ι2,c2ig

33 By Lemma 22, ′ ⌊α ⌋2 ′ ′ ′ (6) κ2 ⊲ (ιpc g ι2 gpc gc g), ⌊δ⌋2 / c2 −→ κ2 ⊲ (ιpc g ι2 gpc gc g), ⌊δ ⌋2 / c2, ′ ′ ⌊δ ⌋1 = ⌊δ⌋1 and ⌊α ⌋1 = · ′ ′ ′ T.S. ⌊ιpc gpc,δ / hκ1, ι1, skip | κ2, ι2,c2ig⌋1 = κ1 ⊲ (ιpc g ι1) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋1 / skip and ′ ′ ′ ′′ ′′ ′′ ′ ′ ⌊ιpc gpc,δ / hκ1, ι1, skip | κ2, ι2,c2ig⌋2 = κ2 ⊲ ιpc gpc,δ2 / {c2 } and ⌊α ⌋1 = · and ⌊α ⌋2 = α2 By projection of commands, ′ ′ ′ ′ (7) ⌊ιpc gpc,δ / hκ1, ι1, skip | κ2, ι2,c2ig⌋1 = κ1 ⊲ (ιpc g ι1) (gpc gc g) ⊲ ιpc gpc, ⌊δ ⌋1 / skip ′ ′ ′ ′ ′ ′ (8) ⌊ιpc gpc,δ / hκ1, ι1, skip | κ2, ι2,c2ig⌋2 = κ2 ⊲ (ιpc g ι2) (gpc gc g) ⊲ ιpc gpc, ⌊δ ⌋2 / {c2} ′ ′′ ′ ′′ ′ ′′ ′ By (8), T.S. κ2 ⊲ (ιpc g ι2) (gpc gc g)= κ2 , ⌊δ ⌋2 = δ , c2 = c2 and ⌊α ⌋2 = α2 By (4) and (6) ′′ ′ ′′ ′ ′ ′′ ′ (9) κ2 = κ2 ⊲ (ιpc g ι2) (gpc gc g), δ = ⌊δ ⌋2, c2 = c2 , α2 = ⌊α ⌋2 By (6), (7), (9) and projection of traces, the conclusion holds

Case: c = h∅, ι1, skip |∅, ι2, skipi By projection of commands (1) ⌊ιpc gpc,δ/ h∅, ι1, skip |∅, ι2, skipig⌋i = (ιpc g ιi) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋i / {skip} (2) ⌊ιpc gpc,δ/ skip⌋i = ιpc gpc, ⌊δ⌋i / skip By (1) and definition of P-POP (3) (ιpc g ιi) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋i / {skip} −→ ιpc gpc, ⌊δ⌋i / skip By (2) and (3), the conclusion holds g Case: c = if hι1 u1 | ι2 u2i then c1 else c2 By P-LIFT-IF g (1) ⌊ιpc gpc,δ/ if hι1 u1 | ι2 u2i then c1 else c2⌋i −→ ⌊ιpc gpc,δ/ h∅, ι1,cj |∅, ι2,ckig⌋i By projection of commands g g (2) ⌊ιpc gpc,δ/ if hι1 u1 | ι2 u2i then c1 else c2⌋i = ιpc gpc, ⌊δ⌋i / if (ιi ui) then c1 else c2 (3) ⌊ιpc gpc,δ/ h∅, ι1,cj |∅, ι2,ckig⌋1 = (ιpc g ι1) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋1 / {cj} where cj is c1 if u1 = true and cj is c2 if u1 = false (4) ⌊ιpc gpc,δ/ h∅, ι1,cj |∅, ι2,ckig⌋2 = (ιpc g ι2) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋2 / {ck} where ck is c1 if u2 = true and cj is c2 if u2 = false By P-IF g (5) ιpc gpc, ⌊δ⌋1 / if(ι1 u1) then c1 else c2 −→ (ιpc g ι1) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋1 / {cj} where cj is c1 if u1 = true and cj is c2 if u1 = false g (6) ιpc gpc, ⌊δ⌋2 / if(ι2 u2) then c1 else c2 −→ (ιpc g ι2) (gpc gc g) ⊲ ιpc gpc, ⌊δ⌋2 / {ck} where ck is c1 if u2 = true and ck is c2 if u2 = false By (2), (3), (4), (5), (6), the conclusion holds

Ti T ∗ ′ ′ ∗ Theorem 9 (Completeness). If ∀i ∈ {1, 2}, ⌊κ,δ/ c⌋i −→ κi,δi / skip and ⊢ κ,δ / c wf, then ∃κ ,δ s.t. κ,δ / c −→ ′ ′ ′ ′ κ ,δ / skip with ⌊κ ,δ / skip⌋i = κi,δi / skip and ⌊T⌋i = Ti

Ti ni Proof. Suppose ∀i ∈{1, 2}, ⌊κ,δ/ c⌋i −→ κi,δi / skip. By induction over the number of steps n1,n2 in the two runs. Base Case: (1) ∀i ∈{1, 2}, ⌊κ,δ/ c⌋i = κi,δi / skip By (1) (2) c = skip and ⌊δ⌋i = δi By assumption (3) κ,δ/ c = κ′,δ′ / skip By (2), (3) ′ ′ (4) ⌊κ ,δ / skip⌋i = κi,δi / skip Inductive Case: By assumption αi ′ ′ ′ (1) ⌊κ,δ/ c⌋i −→ κi,δi / ci or ⌊κ,δ/ c⌋i ends in skip and doesn’t step By Lemma 27, T′ ∗ (2) ∃κ0,δ0,c0.κ, δ / c −→ κ0,δ0 / c0 By (1), (2), and Theorem 8, ′ ′ ′ T′ (3) ∀i ∈{1, 2}, ⌊κ0,δ0 / c0⌋i = κi,δi / ci and ⌊ ⌋i = αi Conclusion follows by IH

34 I. Preservation We define the following constraints on configurations to facilitate proofs related to paired values and commands. We start by defining ι ∈ H(ℓA), Π ∈ H(ℓA) and κ ∈ H(ℓA) for any observer at level ℓA.

ι = [ℓl,ℓr] ℓl 64 ℓA Π= hι1 | ι2i ιi ∈ H(ℓA) where i ∈{1, 2} ι-H Π-H ι ∈ H(ℓA) Π ∈ H(ℓA)

′ ′ ′ κ = ιg ⊲ κ ι ∈ H(ℓA) (κ ∈ H(ℓA) ∨ κ = ∅) κ-H κ ∈ H(ℓA)

We say a configuration is safe (written ⊢ κ,δ /i c sf for i ∈ {·, 1, 2}) if all of the following hold 1) if i ∈{1, 2}, then κ ∈ H(ℓA), ∀x ∈ WtSet(c), intvl (δ(x)) ∈ H(ℓA) 2) if c = if h | i then c1 else c2, then ∀x ∈ WtSet(c), intvl (δ(x)) ∈ H(ℓA) 3) if c = hκ1, ι1,c1 | κ2, ι2,c2ig, then ∀i ∈{1, 2}, ιi ⊢ g ∈ H(ℓA), and ∀x ∈ WtSet(c), intvl (δ(x)) ∈ H(ℓA)

Lemma 28 (Refinement maintains high label). ι1 ⊑ ι2 and ι2 ∈ H(ℓA) imply ι1 ∈ H(ℓA) PROOF (SKETCH). By examining the definitions of the operations. ′ ′ Lemma 29 (Consistent subtyping maintains high). ι ⊢ g ∈ H(ℓA), E ⊢ g 4 c g , and imply ι ⊲⊳ E ⊢ g ∈ H(ℓA) Proof. By inversion, ι = [ℓl,ℓr], ℓl 64 ℓA ι ⊑ γ(g) Assume ι ⊲⊳ E = (ℓx,ℓy), By the definition of ι ⊲⊳ E, ℓl 4 ℓx Therefore, ℓx 64 ℓA By Lemma 5, ι ⊲⊳ E ⊑ γ(g′). ′ Therefore, ι ⊲⊳ E ⊢ g ∈ H(ℓA)

′ ′ ′ ′ Lemma 30 (Join maintains high). ι ⊢ g ∈ H(ℓA), ι ⊑ γ(g ) imply ι g ι ⊢ (g gc g ) ∈ H(ℓA) Proof. By inversion, ι = [ℓl,ℓr], ℓl 64 ℓA, ι ⊑ γ(g) ′ Assume ι g ι = (ℓx,ℓy), ′ By the definition of ι g ι , ℓl 4 ℓx Therefore, ℓx 64 ℓA ′ ′ By Lemma 4, ι g ι ⊑ γ(g gc g ). ′ ′ Therefore, ι g ι ⊢ g gc g ∈ H(ℓA)

′ g ′ Lemma 31 (Preservation (cast)). Γ ⊢ v : U1, E ⊢ U1 ≤ c U2 and U2 = τ imply Γ ⊢ (E,g ) ⊲ v : U2. Proof. By examining the definition of (E,g′) ⊲ v. Case: v = (ιu)g By assumptions, ′ (1) ι′ = ι ⊲⊳ E and (E,g′) ⊲ v = (ι′ u)g By inversion of typing of v g (2) U1 = τ , ι ⊑ γ(g) By inversion of subtyping ′ (3) E ⊢ g ≤ c g By Lemma 5 on (1), (3) (4) ι′ ⊑ γ(g′) By applying the same typing rule using (4), the conclusion holds g Case: v = hι1 u1 | ι1 u1i By assumptions, ′ ′ ′ ′ ′ g (1) ιi = ιi ⊲⊳ E (i ∈{1, 2}) and (E,g ) ⊲ v = hι1 u1 | ι2 u2i By inversion of typing of v, g (2) U1 = τ , and for all i ∈{1, 2} ιi ⊑ γ(g), ιi ⊢ g ∈ H(ℓA)

35 By inversion of subtyping ′ (3) E ⊢ g ≤ c g By Lemma 5 on (1), (3) ′ ′ (4) ιi ⊑ γ(g ) By Lemma 29 ′ ′ (5) ιi ⊢ g ∈ H(ℓA) By applying the same typing rule using (4) and (5), the conclusion holds

gi g1 gcg2 Lemma 32 (Preservation (bop)). If ∀i ∈{1, 2}, Γ ⊢ vi : τ , then Γ ⊢ v1 bop v2 : τ .

PROOF (SKETCH). By examining the definitions of v1 bop v2. Apply Lemma 4 and Lemma 30.

Lemma 33 (Preservation (expression)). If E :: δ /i e ⇓ v, ⊢ δ :Γ, and Γ ⊢ e, then Γ ⊢ v

Proof. By induction on the structure of E. The proof is straightforward when E ends in P-CONST or P-VAR. Case: E ends in P-CAST By assumptions, δ/e ⇓ v v′ = (E,g′) ⊲ v ′ (1) δ / Eg e ⇓ v′ g′ (2) ⊢ δ :Γ, and Γ ⊢ E e : U2 By inversion of typing g′ (3) Γ ⊢ e : U1, E ⊢ U1 ≤ c U2 and U2 = τ By I.H. on e (4) Γ ⊢ v : U1 ′ By Lemma 31, Γ ⊢ v : U2 Case: E ends in P-BOP By assumptions, δ /i e1 ⇓ v1 δ /i e2 ⇓ v2 v = v1 bop v2

(1) δ /i e1 bop e2 ⇓ v (2) ⊢ δ :Γ, and Γ ⊢ e1 bop e2 : U By inversion of typing, ∀i ∈{1, 2} g g1 g g2 (3) Γ ⊢ ei : τ i , and U = τ c By I.H. on ei g (4) Γ ⊢ vi : τ i By Lemma 32, Γ ⊢ v : U

Lemma 34 (PC refinement). If Γ; ιpc gpc ⊢ c, and ι ⊑ ιpc, then Γ; ιgpc ⊢ c. PROOF (SKETCH). By induction over the typing derivation of c. g ′ ′ ′ g Lemma 35. If ⊢ v : τ , refineLBi(Π, v) = v , and when i ∈ {1, 2} or Π = hι | ι i, Π ∈ H(ℓA), then ⊢ v : τ and ′ intvl (v ) ∈ H(ℓA) when i ∈ 1, 2. Proof. By examining all the rules. Use Lemma 2 to show that the resulting intervals are still H. Lemma 36. If ⊢ v : τ g, updL(ι, v)= v′, then ⊢ v′ : τ g and intvl (v′) ⊑ ι. PROOF (SKETCH). By examining all the rules. Use Lemma 3.

′ ′ ′ Lemma 37. If ⊢ δ : Γ and rfLi(δ, X, Π) = δ and when i ∈ {1, 2} or Π = hι | ι i, Π ∈ H(ℓA), then ⊢ δ : Γ and when ′ Π ∈ H(ℓA), ∀x ∈ X, intvl (δ (x)) ∈ H(ℓA) Proof. By induction over the size of X and apply Lemma 35. g g g Lemma 38. If ⊢ vn : τ , ⊢ vo : τ , and when i ∈{1, 2}, intvl (vo) ∈ H(ℓA) and intvl (vn) ∈ H(ℓA), then ⊢ updi vo vn : τ

Proof. By examining the definition of updi vo vn Case: upd vo vn where either vo or vn is a pair By inversion of typing rules, intvl (vo) ∈ H(ℓA) or intvl (vn) ∈ H(ℓA) By Lemma 2, Lemma 3, and Lemma 28, intvl (upd vo vn) ∈ H(ℓA) g Therefore V-PAIR applies and ⊢ upd vo vn : τ

36 Case: upd vo vn where neither vo nor vn is a pair We use Lemma 2, Lemma 3, and transitivity of ⊑ and apply value typing rule directly.

Case: updi vo vn, where i ∈{1, 2} By assumption, intvl (vo) ∈ H(ℓA) and intvl (vn) ∈ H(ℓA) By Lemma 2, Lemma 3, and Lemma 28, the updated value’s interval is in H(ℓA) g Therefore V-PAIR applies and ⊢ updi vo vn : τ

α ′ ′ ′ ′ Lemma 39 (Preservation one-step). If E :: κ,δ /i c −→ κ ,δ /i c , ⊢ δ :Γ and D :: Γ; κ ⊢r c, and ⊢ κ,δ /i c sf then ⊢ δ :Γ, ′ ′ ′ ′ ′ Γ; κ ⊢r c , ⊢ α, and ⊢ κ ,δ /i c sf Proof. By induction on the structure of c Case: c = skip There is no rule to step skip, so the conclusion holds trivially. Case: c = c1; c2 By inversion of D ′ (1) κ = κ ⊲ ιpc gpc, Γ; ιpc gpc ⊢ c2, and Γ; κ ⊢r c1 or (Γ; ιpc gpc ⊢ c1 and κ = ιpc gpc) By examining E, there are two cases: P-SEQ or P-SKIP applies Subcase I: E ends in P-SEQ By assumption α ′ ′ ′ κ,δ /i c1 −→ κ ,δ /i c1 α ′ ′ ′ (I2) κ,δ /i c1; c2 −→ κ ,δ /i c1; c2 By I.H. on c1 ′ ′ ′ (I3) ⊢ δ :Γ, Γ; κ ⊢r c1 and ⊢ α By Lemma 21, (I3), (1), either R-END or R-C-SEQ applies ′ ′ (I4) Γ; κ ⊢r c1; c2 Subcase II: E ends in P-SKIP (II2) κ,δ /i skip; c2 −→ κ,δ /i c2 By (1) and c1 = skip (II3) κ = ιpc gpc By (1) and (II3) and R-END (II4) Γ; κ ⊢r c2 Case: c = x := e By inversion of D g g (1) κ = ιpc gpc, Γ ⊢ x : τ , Γ ⊢ e : τ , and gpc 4 c g By examining E, only P-ASSIGN applies ′ ′′ ′ ′ ′′ δ /i e ⇓ v v = refineLB(ιpc, v ) δ = δ[x 7→ updi δ(x) v ] ′ (2) ιpc gpc,δ/i x := e −→ ιpc gpc,δ /i skip By Lemma 33, Γ ⊢ v′ : τ g , ′′ g ′′ By Lemma 35, Γ ⊢ v : τ , and intvl (v ) ∈ H(ℓA) when i ∈ 1, 2 By assumption, intvl (δ(x)) ∈ H(ℓA) ′′ g By Lemma 38, Γ ⊢ updi δ(x) v : τ By store typing ⊢ δ′ :Γ Case: c = output(ℓ,e) By inversion of D g (1) κ = ιpc gpc, Γ ⊢ e : τ , g 4 c ℓ, gpc 4 c ℓ By examining E, only P-OUT applies ′ ′′ ′ ′′ δ /i e ⇓ v v = refineLB(ιpc, v ) v1 = updL([ℓ,ℓ], v ) (i,ℓ,v1) (2) ιpc gpc,δ/i output(ℓ,e) −→ ιpc gpc,δ/i skip By Lemma 33 (3) Γ ⊢ v′ : τ g By Lemma 35 ′′ g ′′ (4) Γ ⊢ v : τ and intvl (v ) ∈ H(ℓA) when i ∈{1, 2} By Lemma 36 g (5) Γ ⊢ v1 : τ and intvl (v1) ⊑ [ℓ,ℓ] By (5)

37 (6) intvl (v1) 4 [ℓ,ℓ] ′′ By (4), intvl (v1) ⊑ intvl (v ), and Lemma 28 (7) intvl (v1) ∈ H(ℓA) when i ∈{1, 2} By T-A-*, ⊢ (i,ℓ,v1) X Case: c = if e then c1 else c2 By inversion of D gc (1) κ = ιpc gpc, Γ ⊢ e : bool , ιc = γ(gc), (2) Γ; ιpc g ιc gpc gc gc ⊢ ci, where i ∈{1, 2} and (3) X = WtSet(c1) ∪ WtSet(c2) By examining E, only P-IF-REFINE applies ′ δ /i e ⇓ v δ = rfLi(δ, X, ιpc g intvl (v)) X ′ (4) ιpc gpc,δ/i if e then c1 else c2 −→ ιpc gpc,δ /i if v then c1 else c2 By Lemma 33 (5) Γ ⊢ v : boolgc , By (1) and R-C-IF (6) Γ; ιpc gpc ⊢r if v then c1 else c2 By Lemma 37, ⊢ δ′ :Γ By ⊢ ιpc gpc,δ/i c : sf (7) ιpc ∈ H(ℓA) when i ∈{1, 2} By Lemma 37, ′ (8) when i ∈{1, 2} or intvl (v) ∈ H(ℓA), ∀x ∈ X, intvl (δ (x)) ∈ H(ℓA). ′ By sf definition, ⊢ ιpc gpc,δ /i if v then c1 else c2 sf Case: c = if v then c1 else c2 By inversion of D gc (1) κ = ιpc gpc, Γ ⊢ e : bool , ιc = γ(gc), Γ; ιpc g ιc gpc gc gc ⊢ ci, where i ∈{1, 2} By examining E, there are three cases: P-LIFT-IF,P-IF applies Subcase I: v = (ι true)g By assumption, v = (ι true)g ′ ′ ιpc = ιpc g ι gpc = gpc gc g g ′ ′ (I2) ιpc gpc,δ/i if (ι true) then c1 else c2 −→ ιpc gpc ⊲ ιpc gpc,δ/i {c1} By inversion of typing for e (I3) gc = g By Lemma 34 and (I3), and (1) ′ (I4) Γ; ιpc g ιc gpc gc gc ⊢ c1 ′ ′ By (I4) and R-POP, Γ; ιpc gpc ⊲ ιpc gpc ⊢{c1}. Subcase II: v = (ι false)g, the proof is similar to the previous case. Subcase III: E ends in P-LIFT-IF, g By assumption, v = hι1 u1 | ι2 u2i i = {1, 2} cj = c1 if u1 = true cj = c2 if u1 = false ck = c1 if u2 = true ck = c2 if u2 = false g (III2) ιpc gpc,δ/ if hι1 u1 | ι2 u2i then c1 else c2 −→ ιpc gpc,δ/ h∅, ι1,cj |∅, ι2,ckig By inversion of typing for v (III3) g = gc, ιi = γ(g), and ιi ⊢ g ∈ H(ℓA) By similar arguments used in the previous subcase, (III4) Γ; ιpc g ιi gpc gc gc ⊢ ci By (III3), (III4) and R-C-PAIR, Γ; ιpc gpc ⊢ h∅, ι1,cj |∅, ι2,ckig By ⊢ ιpc gpc,δ/i c : sf (III5) ∀x ∈ WtSet(ci), intvl (δ(x)) ∈ H(ℓA) By ιi ∈ H(ℓA), (III6) ιi ∈ H(ℓA), By (III5) and (III6), ⊢ ιpc gpc,δ/ h∅, ι1,cj |∅, ι2,ckig : sf Case: c = whileX e do c′ By inversion of D g ′ ′ (1) κ = ιpc gpc, Γ ⊢ e : bool , ιc = γ(g), Γ; ιpc g ιc gpc gc g ⊢ c , X = WtSet(c ) By examining E, only P-WHILE applies X ′ X ′ X ′ (2) ιpc gpc,δ/i while e do c −→ ιpc gpc,δ/i if e then (c ; while e do c ) else skip

38 To type the resulting if statement, we need to show the following: X ′ Γ; ιpc g ιc gpc gc g ⊢ while e do c Because expression typing does not use pc context and g (gc) the same interval (label) twice does not change the result, the conclusion holds Case: c = {c′} By inversion of D ′ (1) κ = κ1 ⊲ ιpc gpc, Γ; κ1 ⊢ c By examining E, there are two cases: P-PC or P-POP applies Subcase I: E ends in P-POP By c′ = skip and (1) (I2) κ1 = ιg By assumption

(I3) ιg ⊲ ιpc gpc,δ/i {skip} −→ ιpc gpc,δ/i skip By G-SKIP and R-END (I4) Γ; ιpc gpc ⊢r skip Subcase II: E ends in P-PC By assumption α ′ ′ ′ κ,δ /i c −→ κ ,δ / c α ′ ′ ′ (II2) κ ⊲ ιpc gpc,δ/i {c} −→ κ ⊲ ιpc gpc,δ /i {c } By I.H. on c ′ ′ ′ (II3) ⊢ δ :Γ, Γ; κ ⊢r c and ⊢ α By R-POP ′ ′ (II4) Γ; κ ⊲ ιpc gpc ⊢r {c } Case: c = hκ1, ι1,c1 | κ2, ι2,c2ig By inversion of D (1) κ = ιpc gpc, Γ; κi ⊲ (ιpc g ιi) (gpc gc g) ⊢r ci, and ιi ⊢ g ∈ H, for i ∈{1, 2} By examining E, there are two cases: P-SKIP-PAIR or P-C-PAIR applies Subcase I: E ends in P-SKIP-PAIR (I2) κi = ∅ By assumption

(I3) ιpc gpc,δ/ h∅, ι1, skip |∅, ι2, skipig −→ ιpc gpc,δ/ skip By G-SKIP and R-END (I4) Γ; ιpc gpc ⊢r skip Subcase II: E ends in P-C-PAIR By assumption α ′ ′ ′ κi ⊲ ιpc g ιi gpc gc g,δ /i ci −→ κi ⊲ ιpc g ιi gpc gc g,δ /i ci ′ ′ cj = cj κj = κj {i, j} = {1, 2} α ′ ′ ′ ′ ′ (II2) ιpc gpc,δ/ hκ1, ι1,c1 | κ2, ι2,c2ig −→ ιpc gpc,δ / hκ1, ι1,c1 | κ2, ι2,c2ig Assume c1 takes a step. The other case when c2 takes a step can be proven similarly. By I.H. on c1 ′ ′ ′ (II3) ⊢ δ :Γ, Γ; κ ⊲ ιpc g ιi gpc gc g ⊢r c1 and ⊢ α By R-C-PAIR, (II3), and (1) ′ ′ ′ ′ (II4) Γ; ιpc gpc ⊢r hκ1, ι1,c1 | κ2, ι2,c2ig

α Lemma 40. If κ,δ/ c −→ κ′,δ′ / c′ with ⊢ κ,δ,c and ⊢ κ,δ/ c sf, then ⊢ κ′,δ′,c′ and ⊢ κ′,δ′ / c′ sf and ⊢ α Proof. Follows from Lemma 39 T Theorem 10 (Preservation). If κ,δ/ c −→∗ κ′,δ′ / c′ with ⊢ κ,δ,c and ⊢ κ,δ/ c sf, then ⊢ κ′,δ′,c′ and ⊢ T Proof. By induction on the number of steps in the sequence. Base case is trivial and follows from assumption. T α Inductive Case: Holds for n steps; To show for n +1 steps, i.e., if κ,δ/ c −→n κ′,δ′ / c′ −→ κ′′,δ′′ / c′′, then ⊢ κ′′,δ′′,c′′ and ⊢ T, α T (IH) If κ,δ/ c −→n κ′,δ′ / c′ with ⊢ κ,δ,c, then ⊢ κ′,δ′,c′ and ⊢ T

39 By Lemma 40 and IH (1) ⊢ κ′′,δ′′,c′′ and ⊢ T and ⊢ α By T-T-IND, conclusion holds

J. Noninterference

We first define when a gradual label of an initial store location is not observable by the attacker. Formally: g ∈ H(ℓA) iff g = ℓ and ℓ 64 ℓA. We define merging of two stores (δ1 ⊲⊳ δ2) as below: g Γ ⊢ δ1 ⊲⊳ δ2 = δ lab(Γ(x)) ∈ H(ℓA) vi = (ιi ui) (i ∈{1, 2} MGS-EMP g MGS-H Γ ⊢ · ⊲⊳ · = · Γ ⊢ δ1, x 7→ v1 ⊲⊳ δ2, x 7→ v2 = δ, x 7→ hι1 u1 | ι2 u2i

Γ ⊢ δ1 ⊲⊳ δ2 = δ lab(Γ(x)) 6∈ H(ℓA) v1 = v2 = v MGS-L Γ ⊢ δ1, x 7→ v1 ⊲⊳ δ2, x 7→ v2 = δ, x 7→ v T T T Lemma 41. If ⊢ then ⊢⌊ ⌋1 ≈ℓA ⌊ ⌋2 Proof. By induction on the structure of T. The base case is trivial. Case: T = α, T′ By inversion of ⊢ T (1) ⊢ α and ⊢ T′ By I.H. on T′ T′ T′ (2) ⊢⌊ ⌋1 ≈ℓA ⌊ ⌋2 By inversion of ⊢ α, we have two cases Subcase I: α = (ℓ, v) By projection rules ′ ′ ′ ′ (I3) ⌊α, T ⌋1 = α, ⌊T ⌋1, and ⌊α, T ⌋2 = α, ⌊T ⌋2 T T By applying either EQT-L or EQT-H-L then EQT-H-R on (2), ⊢⌊ ⌋1 ≈ℓA ⌊ ⌋2 Subcase II: α = (i,ℓ,v), we show the case when i =1, the other case when i =2 is similar By projection rules ′ ′ ′ ′ (II3) ⌊α, T ⌋1 = (ℓ, v), ⌊T ⌋1, and ⌊α, T ⌋2 = ⌊T ⌋2 By typing of α (II4) ⊢ ℓ 64 ℓA T T By (II4) and EQT-H-L and (2), ⊢⌊ ⌋1 ≈ℓA ⌊ ⌋2

Lemma 42. If ⊢ δ1 ≈ℓA δ2 :Γ then ∃δ s.t. Γ ⊢ δ1 ⊲⊳ δ2 = δ, ⊢ δ :Γ and ⌊δ⌋i = δi Proof. By induction on the structure of the equivalence definition. Base case is trivial Inductive Case: EQS-IND. By assumption

E1 ::⊢ δ1 ≈ℓA δ2 :Γ E2 ::⊢ v1 ≈ℓA v2 : U

(1) ⊢ δ1, x 7→ v1 ≈ℓA δ2, x 7→ v2 :Γ, x : U By I.H. on E1 (2) ∃δ s.t. Γ ⊢ δ1 ⊲⊳ δ2 = δ, ⊢ δ :Γ and ⌊δ⌋i = δi By inversion of E2, there are two subcases: Subcase I: E2 ends in EQV-L By assumption g g (I3) vi = (ιu) , g 4 c ℓA, ι ⊑ γ(g) and ⊢ (ιu) : U By casing on g and (I3), (I4) g 6∈ H(ℓA) By MGS-L on (I3), (I4), (2) g (I5) Γ, x : U ⊢ δ1, x 7→ v1 ⊲⊳ δ2, x 7→ v1 = δ, x 7→ (ιu) , By T-S-IND, (2), and (I3) (I6) ⊢ δ, x 7→ (ιu)g :Γ, x : U Subcase II: E2 ends in EQV-H By assumption

40 g g (II3) vi = (ιi ui) , ιi ⊢ g ∈ H(ℓA), and ⊢ (ιi ui) : U where i ∈{1, 2} By MGS-H on (II3), (2) g (II4) Γ, x : U ⊢ δ1, x 7→ v1 ⊲⊳ δ2, x 7→ v1 = δ, x 7→ hι2 u2 | ι2 u2i , By T-S-IND, (2), and (II3) g (II5) ⊢ δ, x 7→ hι1 u1 | ι2 u2i :Γ, x : U

Theorem 11 (Noninterference). Given an adversary label ℓA, a program c, and two stores δ1, δ2, s.t., ⊢ δ1 ≈ℓA δ2 :Γ, and Ti ∗ ′ T T Γ; [⊥, ⊥] ⊥⊢ c, and ∀i ∈{1, 2}, [⊥, ⊥] ⊥,δi / c −→ κi,δi / skip, then ⊢ 1 ≈ℓA 2. Proof. By assumptions and Lemma 42 (1) ∃δ s.t. Γ ⊢ δ1 ⊲⊳ δ2 = δ, ⊢ δ :Γ and ⌊δ⌋i = δi By Completeness Theorem (Theorem 9) T (2) ∃κ′, δ′, T, s.t. [⊥, ⊥] ⊥,δ/c −→∗ κ′,δ′ / skip By Soundness Theorem (Theorem 8) ⌊T⌋i ∗ ′ (3) ⌊[⊥, ⊥] ⊥,δ/c⌋i −→ ⌊κ,δ / skip⌋i By the operational semantic rules are deterministic and (3) (4) Ti = ⌊T⌋i By assumption and (1) and T-CONF (5) ⊢ [⊥, ⊥] ⊥,δ,c By Preservation Theorem (Theorem 10), (5), and (2) (6) ⊢ T By Lemma 41 and (6) T T (7) ⊢⌊ ⌋1 ≈ℓA ⌊ ⌋2 T T By (4) and (7), ⊢ 1 ≈ℓA 2

K. Gradual Guarantees Lemma 43 (Operations are closed under refinement). ′ ′ ′ ′ 1 if ι1 ⊑ ι1 and ι2 ⊑ ι2, then ι1 ⊲⊳ ι2 ⊑ ι1 ⊲⊳ ι2. ′ ′ ′ ′ 2 ι1 ⊑ ι1 and ι2 ⊑ ι2, then ι1 g ι2 ⊑ ι1 g ι2. ′ ′ ′ ′ 3 ι1 ⊑ ι1 and ι2 ⊑ ι2, then refine(ι1, ι2) ⊑ refine(ι1, ι2). ′ ′ ′ ′ 4 if ι1 ⊑ ι1 and E ⊑ E , then ι1 ⊲⊳ E ⊑ ι1 ⊲⊳ E . ′ ′ ′ ′ 5 g1 ⊑ g1 and g2 ⊑ g2, then g1 gc g2 ⊑ g1 gc g2. Proof. By assumptions ′ ′ ′ ′ ′ (1) ι1 = [ℓ1l,ℓ1r], ι1 = [ℓ1l,ℓ1r], ℓ1l 4 ℓ1l, and ℓ1r 4 ℓ1r ′ ′ ′ ′ ′ (2) ι2 = [ℓ2l,ℓ2r], ι2 = [ℓ2l,ℓ2r], ℓ2l 4 ℓ2l, and ℓ2r 4 ℓ2r By (1) and (2) ′ ′ ′ ′ (3) ℓ1l f ℓ2l 4 ℓ1l f ℓ2l and ℓ1r f ℓ2r 4 ℓ1r f ℓ2r ′ ′ ′ ′ (4) ℓ1l g ℓ2l 4 ℓ1l g ℓ2l and ℓ1r g ℓ2r 4 ℓ1r g ℓ2r By definition of ⊲⊳ ′ ′ ′ ′ ′ ′ (5) ι1 ⊲⊳ ι2 = [ℓ1l g ℓ2l,ℓ1r f ℓ2r], and ι1 ⊲⊳ ι2 = [ℓ1l g ℓ2l,ℓ1r f ℓ2r] ′ ′ By (3) and (4), ι1 ⊲⊳ ι2 ⊑ ι1 ⊲⊳ ι2 By definition of g ′ ′ ′ ′ ′ ′ (6) ι1 g ι2 = [ℓ1l g ℓ2l,ℓ1r g ℓ2r] and ι1 g ι2 = [ℓ1l g ℓ2l,ℓ1r g ℓ2r] ′ ′ By (3), and (4) ι1 g ι2 ⊑ ι1 g ι2. By definition of refine (7) refine(ι1, ι2) = ([ℓ1l,ℓ1r f ℓ2r], [ℓ2l g ℓ1l,ℓ2r]), and ′ ′ ′ ′ ′ ′ ′ ′ (8) refine(ι1, ι2) = ([ℓ1l,ℓ1r f ℓ2r], [ℓ2l g ℓ1l,ℓ2r]) ′ ′ ′ ′ ′ ′ T.S. [ℓ1l,ℓ1r f ℓ2r] ⊑ [ℓ1l,ℓ1r f ℓ2r] and [ℓ2l g ℓ1l,ℓ2r] ⊑ [ℓ2l g ℓ1l,ℓ2r] ′ ′ ′ By (1) and (3), [ℓ1l,ℓ1r f ℓ2r] ⊑ [ℓ1l,ℓ1r f ℓ2r] ′ ′ ′ By (2) and (4), [ℓ2l g ℓ1l,ℓ2r] ⊑ [ℓ2l g ℓ1l,ℓ2r]

41 By assumptions ′ ′ ′ ′ ′ (9) E = (ιa, ιb), E = (ιa, ιb), and ιa ⊑ ιa, ιb ⊑ ιb ′ By ι1 ⊑ ι1 and (9) and we have proven 1-3 of this lemma ′ ′ (10) ιa ⊲⊳ ι1 ⊑ ιa ⊲⊳ ι1 By (10) and we have proven 1-3 of this lemma ′ ′ ′ (11) refine(ιa ⊲⊳ ι1, ιb) ⊑ refine(ιa ⊲⊳ ι1, ιb) ′ ′ By definition of ι ⊲⊳ E and (11), ι1 ⊲⊳ E ⊑ ι1 ⊲⊳ E ′ ′ The proof of 5 cases on g1 and g2. When neither one is ?, the conclusion holds because ⊑ is reflexive. When one of them ′ ′ is ?, g1 gc g2 =?, it is defined that g1 gc g2 ⊑?.

L. Static Gradual Guarantee G We omit the definitions of e ⊑ e′ for WHILE , which are inductively defined over the structure of e. We only show the definition for cast expression below, as it requires the types to be the same. e ⊑ e′ e :: U ⊑ e′ :: U The precision of the cast operator is defined as shown above. As the precision operation is defined over labels of values in stores, the expressions have to be cast to the same type U. If we cast e′ to a different type U ′ and try to show that U ⊑ U ′, the proof results in cases that require a proof for ℓ1 ⊑ ℓ2 where ℓ1 6= ℓ2, which does not hold. ′ ′ ′ ′ Lemma 44. If g1 ⊑ g1, g2 ⊑ g2 and g1 4 c g2, then g1 4 c g2.

Proof. Assume g1 = ℓ1 and g2 = ℓ2 (L.H.S of ⊑ is a precise label). ′ ′ ′ ′ By precision definition, g1 = ℓ1 or g1 =?, and g2 = ℓ2 or g2 =?. ′ ′ If g1 = ℓ1 and g2 = ℓ2, then the conclusion holds by assumption ′ ′ If g1 =? and g2 = ℓ2, then ? 4 c ℓ2 holds by definition of 4 c ′ ′ If g1 = ℓ1 and g2 =?, then ℓ1 4 c? holds by definition of 4 c ′ ′ If g1 =? and g2 =?, then ? 4 c? holds by definition of 4 c Lemma 45 (Static Gradual Guarantee - Expressions). If Γ ⊢ e : U, Γ ⊑ Γ′, and e ⊑ e′, then Γ′ ⊢ e′ : U ′ and U ⊑ U ′.

Proof. By induction on the structure of the typing derivation. Follows from assumption for BOOL,INT,VAR. Case: BOP ′ ′ By IH, τ g1 ⊑ τ g1 and τ g2 ⊑ τ g2 ′ ′ By Lemma 43, g1 gc g2 ⊑ g gc g ′ 1 2 By BOP, τ g ⊑ τ g Case: CAST g1 g Γ ⊢ e : τ U = τ g1 4 c g Γ ⊢ e :: U : τ g ′ ′ ′ g ′ ′ ′ ′ g1 T.S. Γ ⊢ e :: U : τ and g1 4 c g where Γ ⊢ e : τ e′ is also cast to U instead of another type U ′ for reasons mentioned above. ′ ′ ′ ′ g1 g1 g1 ′ By IH, Γ ⊢ e : τ , τ ⊑ τ . Thus, g1 ⊑ g1. By assumption, g1 4 c g. g1 is a precise label (left-value of ⊑ is a precise label). ′ ′ ′ g1 = ℓ1, then g1 = ℓ1 or g1 =?. In both cases, g1 4 c g. By CAST, the conclusion holds.

Theorem 12 (Static Gradual Guarantee). If Γ; g ⊢ c, Γ ⊑ Γ′, g ⊑ g′, and c ⊑ c′, then Γ′; g′ ⊢ c′. Proof. By induction on command typing derivation. Most cases can be proven by using the induction hypothesis and the typing rule. When the derivation ends in ASSIGN,OUT,IF, WHILE, apply Lemma 45 on the premises and when the derivation ends in IF, WHILE, we additionally apply Lemma 43. We use the same typing rule to reach the conclusion.

M. Dynamic Gradual Guarantee

Lemma 46 (Dynamic Guarantee (Expressions)). If δ1 / e1 ⇓ v1, δ1 ⊑ δ2, and e1 ⊑ e2, then δ2 / e2 ⇓ v2 and v1 ⊑ v2. Proof. By induction on the structure of the expression evaluation. We apply the induction hypothesis directly for. The basecases M-CONST and M-VAR can be shown using assumptions directly. Case: M-BOP

42 By assumption the evaluation ends in M-BOP rule: g1 g2 δ/e1 ⇓ (ι1 u1) δ/e2 ⇓ (ι2 u2) ι = (ι1 g ι2) g = g1 gc g2 u = (u1 bop u2) g M-BOP (1) δ/e1 bop e2 ⇓ (ιu) ′ ′ (2) e = e1 bop e2, δ ⊑ δ , and e ⊑ e By inversion of (2) ′ ′ ′ ′ ′ (3) e = e1 bop e2, e1 ⊑ e1, and e2 ⊑ e2 By I.H. ′ ′ ′ ′ ′ g1 ′ ′ (4) δ / e ⇓ (ι u ) , ι1 ⊑ ι , and g1 ⊑ g , 1 1 1 ′ 1 1 ′ ′ ′ ′ g2 ′ ′ (5) δ / e2 ⇓ (ι2 u2) , ι2 ⊑ ι2, and g2 ⊑ g2, By M-BOP ′ ′ ′ ′ ′ g ′ ′ ′ ′ ′ ′ (6) δ / e1 bop e2 ⇓ (ι u) , where ι = ι1 g ι2, g = g1 gc g2’ By Lemma 43 ′ (7) (ιu)g ⊑ (ι′ u)g Case: M-CAST and P-CAST can be proven similarly by applying I.H. and Lemma 43.

Lemma 47. ′ ′ ′ ′ 1) if ι1 ⊑ ι2 and v1 ⊑ v2, and v1 = refineLB(ι1, v1) and v2 = refineLB(ι2, v2), then v1 ⊑ v2 ′ ′ ′ ′ 2) if ι1 ⊑ ι2 and v1 ⊑ v2, and v1 = updL(ι1, v1) and v2 = updL(ι2, v2), then v1 ⊑ v2 ′ ′ ′ ′ 3) if ι1 ⊑ ι2 and δ1 ⊑ δ2, and δ1 = rfL(δ1,X,ι1), and δ2 = rfL(δ2,X,ι2), then δ1 ⊑ δ2 Proof. Proofs of (1) and (2) examine the definitions of the operations and apply Lemma 43 directly. Proof of (3) is by induction over the size of X and (1). α1 ′ ′ ′ α2 Theorem 13 (Dynamic Gradual Guarantee). If κ1,δ1 / c1 −→ κ1,δ1 / c1 and κ1,δ1 / c1 ⊑ κ2,δ2 / c2, then κ2,δ2 / c2 −→ ′ ′ ′ ′ ′ ′ ′ ′ ′ κ2,δ2 / c2 such that κ1,δ1 / c1 ⊑ κ2,δ2 / c2 and α1 = α2. Proof. By induction on the command semantics. Most cases can be proven by using the induction hypothesis and Lemma 43 directly. When the derivation ends in M-ASSIGN, M-OUT, or M-IF-REFINE, apply Lemma 46 and Lemma 47 on the premises and use the same semantic rule to reach the conclusion.

43 α κ,δ/ c −→ κ′,δ′ / c′

α ′ ′ ′ α ′ ′ ′ κ,δ/ c1 −→ κ ,δ / c1 κ,δ/ c −→ κ ,δ / c M-SEQ M-PC α ′ ′ ′ α ′ ′ ′ κ,δ/ c1; c2 −→ κ ,δ / c1; c2 κ ⊲ ιpc gpc,δ/ {c} −→ κ ⊲ ιpc gpc,δ / {c }

M-POP M-SKIP ιpc gpc ⊲ κ,δ / {skip} −→ κ,δ / skip κ,δ / skip; c −→ κ,δ/ c

′ ′′ ′ δ/e ⇓ v v = refineLB(ιpc, v) v = updL(intvl (δ(x)), v ) ′′ M-ASSIGN ιpc gpc,δ/x := e −→ ιpc gpc,δ[x 7→ v ] / skip

′ ′′ ′ δ/e ⇓ v v = refineLB(ιpc, v) v = updL(intvl (δ(x)), v ) ′′ M-OUT (ℓ,v ) ιpc gpc,δ/ output(ℓ,e) −→ ιpc gpc,δ/ skip

′ ′ ιpc = ιpc g ι gpc = gpc gc g ci = c1 if b = true ci = c2 if b = false g ′ ′ M-IF ιpc gpc,δ/ if (ιb) then c1 else c2 −→ ιpc gpc ⊲ ιpc gpc,δ/ {ci}

′ δ/e ⇓ v δ = rfL(δ, X, ιpc g intvl (v)) M-IF-REFINE X ′ ιpc gpc,δ/ if e then c1 else c2 −→ ιpc gpc,δ / if v then c1 else c2

HILE X X X M-W ιpc gpc,δ/ while e do c −→ ιpc gpc,δ/ if e then (c; while e do c) else skip

undef κ,δ/ c1 −→ abort δ/e ⇓ v rfL(δ, X, ιpc g intvl (v)) = M-SEQ-ERR X M-IF-REFINE-ERR κ,δ/ c1; c2 −→ abort ιpc gpc,δ/ if e then c1 else c2 −→ abort

δ/e ⇓ v refineLB(ιpc, v)= undef M-ASSIGN-ERR ιpc gpc,δ/x := e −→ abort

′ ′ δ/e ⇓ v v = refineLB(ιpc, v) updL(intvl (δ(x)), v )= undef M-ASSIGN-ERR2 ιpc gpc,δ/x := e −→ abort

δ/e ⇓ v refineLB(ιpc, v)= undef M-OUT-ERR ιpc gpc,δ/ output(ℓ,e) −→ abort

′ ′ δ/e ⇓ v refineLB(ιpc, v)= v updL([ℓ,ℓ], v )= undef M-OUT-ERR2 ιpc gpc,δ/ output(ℓ,e) −→ abort

Fig. 19: Monitor semantics for commands

′ refine(ιc, ι) = ( , ι ) refine(ιc, ι)= undef g ′ g g refineLB(ιc, (ιu) ) = (ι u) refineLB(ιc, (ιu) )= undef rfL(δ, ·, ι)= δ

δ′ = rfL(δ, X, ι) v′ = refineLB(ι, v) 6= undef refineLB(ι, v)= undef rfL((δ, x 7→ v), (X, x), ι)= δ′, x 7→ v′ rfL((δ, x 7→ v), (X, x), ι)= undef

ℓ1l g ℓ2l 4 ℓ1r ℓ1l g ℓ2l 64 ℓ1r

restrictLB([ℓ1l,ℓ1r], [ℓ2l,ℓ2r]) = [ℓ1l g ℓ2l,ℓ1r] restrictLB([ℓ1l,ℓ1r], [ℓ2l,ℓ2r]) = undef

g g updL(ιo, (ιn un) ) = (restrictLB(ιo, ιn) un)

Fig. 20: Label-interval refinement operations for the monitor

44 refineLBi i ∈{1, 2}: ′ ′ ′ refine(ιc, ι) = ( , ι ) ιi = ι refine(ιc, ιi) = ( , ιi) ′ undef ιj = ι {i, j} = {1, 2} ιj = ιj {i, j} = {1, 2} refine(ιc, ι)= g g g ′ ′ g g undef refineLBi(ιc, (ιu) )= hι1 u | ι2 ui refineLBi(ιc, hι1 u1 | ι2 u2i )= hι1 u1 | ι2 u2i refineLBi(ιc, (ιu) )=

refine(ιc, ι1)= undef ∨ refine(ιc, ι2)= undef g undef refineLBi(ιc, hι1 u1 | ι2 u2i )= refineLB: ′ ′ refine(ιc, ι) = ( , ι ) ∀i ∈{1, 2}. refine(ιc, ιi) = ( , ιi) g ′ g g ′ ′ g refineLB(ιc, (ιu) ) = (ι u) refineLB(ιc, hι1 u1 | ι2 u2i )= hι1 u1 | ι2 u2i

′ ′ refine(ιi, ι) = ( , ιi) ∀i ∈{1, 2}. refine(ιci, ιi) = ( , ιi) g ′ ′ g g ′ ′ g refineLB(hι1 | ι2i, (ιu) )= hι1 u | ι2 ui refineLB(hιc1 | ιc2i, hι1 u1 | ι2 u2i )= hι1 u1 | ι2 u2i

refine(ιc, ι)= undef ∃i ∈{1, 2}. refine(ιc, ιi)= undef ∃i ∈{1, 2}. refine(ιi, ι)= undef g g g refineLB(ιc, (ιu) )= undef refineLB(ιc, hι1 u1 | ι2 u2i )= undef refineLB(hι1 | ι2i, (ιu) )= undef

∃i ∈{1, 2}. refine(ιci, ιi)= undef g refineLB(hιc1 | ιc2i, hι1 u1 | ι2 u2i )= undef

Fig. 21: refineLB for paired executions

δ′ = rfL(δ, X, ι) v′ = refineLB(ι, v) δ′ = rfL(δ, X, ι) refineLB(ι, v)= undef rfL(δ, ·, ι)= δ rfL((δ, x 7→ v), (X, x), ι)= δ′, x 7→ v′ rfL((δ, x 7→ v), (X, x), ι)= undef ′ ′ ′ undef δ = rfLi(δ, X, Π) v = refineLBi(Π, v) δ = rfLi(δ, X, Π) refineLBi(Π, v)= g ′ g ′ g undef rfLi(δ, ·, Π) = δ rfLi((δ, x 7→ v), (X, x), Π) = δ , x 7→ v rfLi((δ, x 7→ v), (X, x), Π) =

Fig. 22: rfL for paired executions

Value and interval projections: g g g g ⌊hι1 u1 | ι2 u2i ⌋i = (ιi ui) ⌊(ιu) ⌋i = (ιu) ⌊hι1 | ι2i⌋i = ιi ⌊ι⌋i = ι where i = {1, 2} Read operations:

rd v = v rd1 v = ⌊v⌋1 rd2 v = ⌊v⌋2 Write operations:

g ′ vn = hι1 u1 | ι2 u2i ∀i ∈ 1, 2, restrictLB(ιo, ιi)= ιi restrictLB(ιo, ιn)= ι ′ ′ g g g updL ιo vn = hι1 u1 | ι2 u2i updL ιo (ιn un) = (ιun)

g vn = hι1 u1 | ι2 u2i ∃j ∈ [1, 2], restrictLB(ιo, ιj )= undef restrictLB(ιo, ιn)= undef g updL ιo vn = undef updL ιo (ιn un) = undef

45 Simple write/output operations: ′ ′ g ′′ intvl (vo)= hι1 | ι2i or vn = hι1 u1 | ι2 u2i ∀i ∈ 1, 2, restrictLB(⌊intvl (vo)⌋i, ⌊intvl (vn)⌋i)= ιi ′′ ′′ g upd vo vn = hι1 u1 | ι2 u2i

′ ′ g intvl (vo)= hι1 | ι2i or vn = hι1 u1 | ι2 u2i restrictLB(ιo, ιn)= ι ∃i ∈ 1, 2, restrictLB(⌊intvl (vo)⌋i, ⌊intvl (vn)⌋i)= undef g g g upd (ιo uo) (ιn un) = (ιun) upd vo vn = undef

′ undef g ′ g restrictLB(ιo, ιn)= ⌊vn⌋1 = (ι1 un) restrictLB(⌊intvl (vo)⌋1, ι1)= ι1 ⌊vo⌋2 = (ι2 u2) g g undef g ′ g upd (ιo uo) (ιn un) = upd1 vo (ιn un) = hι1 un | ι2 u2i

′ g ′ g ⌊vn⌋2 = (ι2 un) restrictLB(⌊intvl (vo)⌋2, ι2)= ι2 ⌊vo⌋1 = (ι1 u1) g ′ g upd2 vo (ιn un) = hι1 u1 | ι2 uni

g′ ⌊vn⌋1 = (ι1 un) restrictLB(⌊intvl (vo)⌋1, ι1)= undef g undef upd1 vo (ιn un) =

g′ ⌊vn⌋2 = (ι2 un) restrictLB(⌊intvl (vo)⌋2, ι2)= undef g undef upd2 vo (ιn un) = Binary operations:

′ ′ g1 ′ ′ gi v1 = hι1 u1 | ι1 u1i vi = hιi ui | ιi uii ′ ′ g2 gj g1 v2 = hι2 u2 | ι2 u2i vj = (ιj uj) v1 = (ι1 u1) ′ ′ ′ ′ ′ g2 ι = (ι1 g ι2) ι = (ι1 g ι2) ι = (ιi g ιj ) ι = (ιi g ιj ) v2 = (ι2 u2) u = (u1 bop u2) u = (ui bop uj) ι = (ι1 g ι2) ′ ′ ′ ′ ′ u = (u1 bop u2) u = (ui bop uj ) u = (u1 bop u2) g = g1 gc g2 g = gi gc gj {i, j} = {1, 2} g = g1 gc g2 v = hιu | ι′ u′ig v = hιu | ι′ u′ig v = (ιu)g

v1 bop v2 = v v1 bop v2 = v v1 bop v2 = v Cast: g ′ g ′ g v = (ιu) ι = ι ⊲⊳ E v = hι1 u1 | ι2 u2i ∀i ∈{1, 2}, ιi = ιi ⊲⊳ E v = (ιu) ι ⊲⊳ E = undef ′ ′ ′ ′ g ′ ′ ′ g ′ undef (E,g ) ⊲ v = (ι u) (E,g ) ⊲ v = hι1 u1 | ι2 u2i (E,g ) ⊲ v =

g v = hι1 u1 | ι2 u2i ∃i ∈{1, 2}, ιi ⊲⊳ E = undef (E,g′) ⊲ v = undef

Fig. 23: Operations with pairs

Expression Semantics: δ /i e ⇓ v

′ δ /i e ⇓ v v = (E,g) ⊲ v g g P-CONST P-VAR g ′ P-CAST δ /i (ιu) ⇓ (ιu) δ /i x ⇓ rdi δ(x) δ /i E e ⇓ v

δ /i e ⇓ v (E,g) ⊲ v = undef δ /i e1 ⇓ v1 δ /i e2 ⇓ v2 g P-CAST-ERR P-BOP δ /i E e ⇓ abort δ /i e1 bop e2 ⇓ v1 bop v2

Fig. 24: Operational semantics for expression evaluation in paired executions

46 α ′ ′ ′ Command Semantics: κ,δ /i c −→ κ ,δ /i c

α ′ ′ ′ ′ ′ κi ⊲ ιpc g ιi gpc gc g,δ /i ci −→ κi ⊲ ιpc g ιi gpc gc g,δ /i ci cj = cj κj = κj {i, j} = {1, 2} P-C-PAIR α ′ ′ ′ ′ ′ ιpc gpc,δ/ hκ1, ι1,c1 | κ2, ι2,c2ig −→ ιpc gpc,δ / hκ1, ι1,c1 | κ2, ι2,c2ig

κi ⊲ ιpc g ιi gpc gc g,δ /i ci −→ abort {i, j} = {1, 2} P-C-PAIR-ERR ιpc gpc,δ/ hκ1, ι1,c1 | κ2, ι2,c2ig −→ abort

i = {1, 2} cj = c1 if u1 = true cj = c2 if u1 = false ck = c1 if u2 = true ck = c2 if u2 = false g P-LIFT-IF ιpc gpc,δ/ if hι1 u1 | ι2 u2i then c1 else c2 −→ ιpc gpc,δ/ h∅, ι1,cj |∅, ι2,ckig

P-SKIP-PAIR ιpc gpc,δ/ h∅, ι1, skip |∅, ι2, skipig −→ ιpc gpc,δ/ skip

′ δ /i e ⇓ v v = refineLB(ιpc, v) ′ P-ASSIGN ιpc gpc,δ/i x := e −→ ιpc gpc,δ[x 7→ updi δ(x) v ] /i skip

δ /i e ⇓ v refineLB(ιpc, v)= undef P-ASSIGN-ERR ιpc gpc,δ/i x := e −→ abort

′ ′ undef α ′ ′ ′ δ /i e ⇓ v refineLB(ιpc, v)= v updi δ(x) v = κ,δ /i c1 −→ κ ,δ /i c1 P-SEQ P-ASSIGN-ERR2 α ′ ′ ′ ιpc gpc,δ/i x := e −→ abort κ,δ /i c1; c2 −→ κ ,δ /i c1; c2

κ,δ /i c1 −→ abort P-SEQ-ERR P-POP P-SKIP κ,δ /i c1; c2 −→ abort ιg ⊲ κ,δ /i {skip} −→ κ,δ /i skip κ,δ /i skip; c −→ κ,δ /i c

α ′ ′ ′ κ,δ /i c −→ κ ,δ /i c κ,δ /i c −→ abort P-PC α ′ ′ ′ P-PC-ERR κ ⊲ ιpc gpc,δ/i {c} −→ κ ⊲ ιpc gpc,δ /i {c } κ ⊲ ιpc gpc,δ/i {c} −→ abort

undef δ /i e ⇓ v rfLi(δ, X, ιpc g intvl (v)) = F EFINE X P-I -R ιpc gpc,δ/i if e then c1 else c2 −→ abort

′ refineLB ′′ updL ′ δ /i e ⇓ v v = (ιpc, v) v = [ℓ,ℓ] v δ / e ⇓ v refineLB(ι , v)= undef ′′ P-OUT i pc (i,ℓ,v ) P-OUT-ERR ιpc gpc,δ/i output(ℓ,e) −→ ιpc gpc,δ/i skip ιpc gpc,δ/i output(ℓ,e) −→ abort

′ ′ δ /i e ⇓ v refineLB(ιpc, v)= v updL [ℓ,ℓ] v = undef P-OUT-ERR2 ιpc gpc,δ/i output(ℓ,e) −→ abort

′ ′ ιpc = ιpc g ι gpc = gpc gc g cj = c1 if b = true cj = c2 if b = false g ′ ′ P-IF ιpc gpc,δ/i if (ιb) then c1 else c2 −→ ιpc gpc ⊲ ιpc gpc,δ/i {cj}

X X X P-WHILE ιpc gpc,δ/i while e do c −→ ιpc gpc,δ/i if e then (c; while e do c) else skip

Fig. 25: Operational semantics for paired executions

47