An Extended Account of Trace-relating Compiler Correctness and Secure Compilation

As explained in Section 1, trace-relating compiler correctness CC, by itself, lacks a crisp description of which trace properties are preserved by compilation. Since even the syntax of traces can differ between source and target, one can either focus on trace properties of the source (and then interpret them in the target) or on trace properties of the target (and then interpret them in the source). Formally, we need two property mappings, and , which lead us to the following generalization of trace property preservation ():

For an arbitrary source program , interprets a source property as the target guarantee for . Dually, defines a source obligation sufficient for the satisfaction of a target property after compilation. Ideally:

These requirements are satisfied when the two maps form a Galois connection between the posets of source and target properties ordered by inclusion. We briefly recall the definition and the characteristic property of Galois connections [20, 47].

We will often write to denote a Galois connection, or simply , or even when the involved posets are clear from context.

If two property mappings, and , form a Galois connection on trace properties ordered by set inclusion, then Lemma 2.3 (with and ) tells us that they satisfy conditions above, i.e., and .⁵ These conditions on and are sufficient to show the equivalence of the criteria they define, respectively, and .

Proof. Notice that if a program satisfies a property , then it satisfies every less restrictive i.e., bigger property . Building on this:

We now investigate the relation between CC, , and . We show that for a trace relation and its corresponding Galois connection (Lemma 2.7), the three criteria are equivalent (Theorem 2.8). This equivalence offers interesting insights for both verification and the design of a correct compiler. For a CC compiler, the equivalence makes explicit both the guarantees one has after compilation () and source proof obligations to ensure the satisfaction of a given target property (). However, a compiler designer might first determine the target guarantees the compiler itself must provide, i.e., , and then prove an equivalent statement, CC, for which more convenient proof techniques exist in the literature [9, 77].

When trace relations are considered, the corresponding existential and universal images can be used to instantiate Definition 2.1 leading to the trinitarian view already mentioned in Section 1.

This result relies both on Theorem 2.4 and on the fact that the existential and universal images of a trace relation form a Galois connection (). The theorem can be stated in a slightly more general form (Theorem 2.8), exploiting an isomorphism between the category of sets and relations and a subcategory of monotonic predicate transformers [26]. We specialize this isomorphism to what is of interest for our purposes and deduce a bijective correspondence between trace relations and Galois connections on properties.

The bijection just introduced allows us to generalize Theorem 2.6 and switch anytime between the three views of compiler correctness described earlier.

Note that sometimes the lifted properties may be trivial: The target guarantee can be the true property (the set of all traces) or the source obligation the false property (the empty set of traces). This might be the case when source observations abstract away too much information (Section 4.2 presents an example).

Hyperproperty preservation is a strong requirement in general. Fortunately, many interesting hyperproperties are subset-closed( for short) (e.g., noninterference), and these are known to be preserved by refinement [18]. When the trace semantics is common to source and target languages, a subset-closed hyperproperty is preserved if the behaviors of the compiled program refine the behaviors of the source program, which coincides with the statement of . We generalize this result to the trace-relating setting, introducing two other equivalent characterizations of CC in terms of preservation of subset-closed hyperproperties (Theorem 3.3). To do so, we close under subsets the images of both and so source subset-closed hyperproperties are mapped to target subset-closed ones and vice versa.

First, a hyperproperty is defined as a set of sets of traces, (recall that is the set of all traces) [18]. A program satisfies a hyperproperty when its complete set of traces, which from now on we will call its behavior, is a member of the hyperproperty.

To talk about hyperproperty preservation in the trace-relating setting, we need an interpretation of source hyperproperties into the target and vice versa. The one we consider builds on top of the two trace property mappings and , which are naturally lifted to hyperproperty mappings. This way, we are able to extract two hyperproperty mappings from a trace relation similarly to Section 2.2:

Formally, we are defining two new mappings, this time on hyperproperties, but with a small abuse of notation, we still denote them and .

Interestingly, it is not possible to apply the argument used for to show that a CC compiler guarantees whenever . This is because direct images do not necessarily preserve subset-closure [44, 55]. We therefore close the image of and under subsets (denoted as ) and obtain the following result:

The use of in Theorem 3.3 implies a loss of precision in preserving subset-closed hyperproperties through compilation. In Section 5, we focus on a specific security-relevant subset-closed hyperproperty, noninterference, and show that such a loss of precision can be seen as a declassification. Instead, now we define the trinity and the related formal machinery for safety properties preservation.

The class of Safety properties collects all trace properties prescribing that “something bad never happens” or equivalently, all trace properties whose violation can be monitored and, once observed, no longer restored [18]. More abstractly, safety properties can be defined as the closed sets of a topology [18, 58], with no need to consider any particular structure on the traces. To ease the presentation, we consider the trace model adopted by Abate et al. [3] where traces resemble lists and streams of events. This model naturally comes with a notion of prefixes and a relation between a prefix and a trace , written . Intuitively, is a safety property if any trace violating the property extends a “bad prefix” that witnesses such a violation. Every safety property is therefore uniquely defined by the set of its “bad prefixes.” We recall below the definition and the characterization of safety properties in terms of sets of finite prefixes .

Due to this characterization of safety properties through finite prefixes (Definition 3.4), the preservation of all and only the safety properties is equivalent to restricted to finite prefixes.

Unfolding , we can interpret as follows: Whenever produces a trace that violates a specific safety property, namely, the one defined by the singleton prefix set , then violates the same safety property, producing a trace but possibly distinct from .

The generalization we propose of to the trace-relating setting, states that whenever produces a trace that violates a target safety property, then violates the source interpretation of the property, i.e., its image through .⁷ The following theorem defines and its two equivalent formulations:

Coherent with the informal meaning we aimed to give to , quantifies over target safety properties, while quantifies over arbitrary source properties, but imposes the composition of with , which maps an arbitrary target property to the target safety property that best over-approximates . ⁸ More precisely, is a closure operator on target properties, with being the class of target safety properties.

In Figure 2 the blue and red ellipses represent source and target properties properties, respectively, and are connected by . The red ellipse is the class of all target safety properties. is a Galois connection between target properties and the target safety properties, as is a closure operator [21]. Finally, the composition of Galois connections is still a Galois connection [21]. Hence,is a Galois connection between source properties and target safety properties, which we used to prove the equivalence (). We notice that this argument generalizes to arbitrary closure operators on target properties (). We come back to this in Section 6, where more such results will be needed when considering other classes of properties being preserved by secure compilers. Now, we define the trinity for arbitrary hyperproperties, not just the subset-closed ones.

Subset-closed hyperproperties are not expressive enough to all capture interesting properties, e.g., possibilistic notions of information-flow [18], so we aim to briefly discuss the preservation of arbitrary hyperproperties. In general, one cannot lift a Galois connection over trace properties to a Galois connection over arbitrary hyperproperties.

While two out of three of the criteria we introduce in this section are equivalent under no assumptions (), for a comparison with the third one, we require that no information is lost in the pre or post composition of and . For this, we label the trinity in Theorem 3.8 as weak.

To start, we note that the following strengthening of , denoted , is equivalent to the preservation of arbitrary hyperproperties. Here, is the set of all traces of :

requires that the behavior of is exactly the same as the behavior of . We generalize this to the trace-relating setting by requiring that the behavior of coincide with the target interpretation of the source properties describing the behavior of . ⁹

In other words, it is still possible (and sound) to deduce a source obligation for a given target hyperproperty () when no information is lost in the composition . Dually, (and hence ) is a consequence of when no information is lost in composing in the other direction, .

At this point, we have presented four trinities of criteria that preserve trace properties, subset-closed hyperproperties, safety properties, and arbitrary hyperproperties. Figure 3 sums up our trinities and orders them according their relative strength.

In Section 6, we will also consider, in the setting of secure compilation, the class of safety hyperproperties or hypersafety, and relational hyperproperties. In the setting of correct compilation—which focuses only on whole programs—it is straightforward to show that the trinity for hypersafety coincides with the one for safety properties in the same way the trinity of trace properties and subset-closed hyperproperties coincide. Similarly the trinity for relational hyperproperties coincides with the one for hyperproperties.

We start by expanding upon the discussion of undefined behavior in Section 1. We first study the model of CompCert, where source and target alphabets are the same, including the event for undefined behavior. The trace relation weakens equality by allowing undefined behavior to be replaced with an arbitrary sequence of events.

This relation can be easily generalized to other settings. For instance, consider the setting in which we compile down to a low-level language like machine code. Target traces can now contain new events that cannot occur in the source: Indeed, in modern architectures like x86 a compiler typically uses only a fraction of the available instruction set. Some instructions might even perform dangerous operations, such as writing to the hard drive or controlling a device that is hidden from the source language. Formally, the source and target do not have the same events anymore. Thus, we consider a source alphabet, , and a target alphabet, . The trace relation is defined in the same way and we obtain the same property mappings as above, except that target traces now have more events (some of which may be dangerous), the arbitrary continuations of target traces get more interesting. For instance, consider a new event that represents writing data on the hard drive, and suppose we want to prove that this event cannot happen for a compiled program. Then, proving this property requires exactly proving that the source program exhibits no undefined behavior [14]. More generally, what one can prove about target-only events can only be either that they cannot appear (because there is no undefined behavior) or that any of them can appear (in the case of undefined behavior).

In Section 7.1, we study a similar example, showing that even in a safe language linked adversarial contexts can cause dangerous target events that have no source correspondent.

Let us return to the discussion about resource exhaustion in Section 1.

We conclude this subsection by noting that the resource exhaustion relation and the undefined behavior relation from the previous subsection can easily be combined. Indeed, given a relation and a relation defined as above on the same sets of traces, we can build a new relation that allows both refinement of undefined behavior and resource exhaustion by taking their union: . A compiler that is or is trivially CC, though the converse is not true.

This section first presents the common language formalization (Section 4.3.1) that the following (Section 4.3.2) and later instances (Section 4.4 and Section 7.1) build upon. This shared language formalization does not contain a key language feature, namely, the expressions that generate actions and thus labels. This is because each instance deals with specific ways to generate actions, so each instance will define its own extension to each of the languages defined below. Additionally, each instance will define its own compiler and the trace relation used to attain CC.

We now consider how to relate traces where a single source action is compiled to multiple target ones. To illustrate this, we extend our source language to output (nested) pairs of arbitrary size and our target language to send values that have a fixed size. Concretely, the source is analogous to the language of Section 4.3, except that it does not have inputs (nor Booleans for simplicity) but it has pairs. Additionally, it has an expression that can emit a (nested) pair of values in a single action. Given that reduces to a pair, e.g., , expression emits action . That expression is eventually compiled into a sequence of individual sends in the target language , since in the target, sends the value that reduces to, but the language cannot send pairs (although it has pair constructs).

The source and target languages are formally extended (respectively, in the first and second lines below) with pairs and sending constructs as follows: For reasons that we explain when the compiler is presented, we extend the target language with a let-in construct and variables. Finally, source traces are sequences of sent values (which include nested pairs) and target traces are only sequences of natural numbers.The source additions are well-typed and their semantics is unsurprising; the semantics relies on the usual capture-avoiding substitution of a result for a variable The compiler is defined inductively on the type derivation of a source expression (). The only interesting case is when compiling a , where we use the source type information concerning the message (i.e., a pair) being sent to deconstruct that pair into a sequence of natural numbers, which is what is sent in the target. This is the reason we need the let-in construct in the target, since we run the pair once (as the argument of the let-in) and then we send all of its projection to avoid duplicating side effects. Technically, since it is defined on the type derivations of terms, the compiler is defined inductively on type derivations (and not simply on terms). Thus, compiling would look like the following (using as a metavariable to range over derivations):However, note that each judgment uniquely identifies which typing rule is being applied and the underlying derivation. Thus, for compactness, we only write the judgment in the compilation and implicitly apply the related typing rule to obtain the underlying judgments for recursive calls. To differentiate this from the compiler of Section 4.3.2, this compiler has parentheses over its input.Relating Traces. We start with the trivial relation between numbers: , i.e., numbers are related when they are the same. We cannot build a relation between single actions, since a single source action is related to multiple target ones. Therefore, we define a relation between a source action and a target trace (a list of numbers) inductively on the structure of .

A pair of naturals is related to the two actions that send each element of the pair (Rule Trace-Rel-N-N). If a pair is made of sub-pairs, then we require all such sub-pairs to be related (Rules Trace-Rel-N-M to Trace-Rel-M-M).

We build on these rules to define the relation between source and target traces for which the compiler is correct (4.5). Trivially, traces are related when they are both empty. Alternatively, given related traces, we can concatenate a source action and a second target trace provided that they are related (Rule Trace-Rel-Single). Before proving that the compiler is correct, we need 4.4. Intuitively, that lemma tells us that the way we break down a source sent value into multiple target sends is correct.

With our trace relation, the trace property mappings capture the following intuitions:

Intuitively, noninterference (NI) requires that publicly observable outputs do not reveal information about private inputs. To define this formally, we need a few additions to our setup. We indicate the (disjoint) input and output projections of a trace as and , respectively.¹¹ Denote with the equivalence class of a trace , obtained using a standard low-equivalence relation that relates low (public) events only if they are equal, and ignores any difference between private events. Then, NI for source traces can be defined as:That is, source NI comprises the sets of traces that have equivalent low output projections as long as their low input projections are equivalent.

When additional observations are possible in the target, it is unclear whether a noninterfering source program is compiled to a noninterfering target program or not, and if so, whether the notion of NI in the target is the expected (or desired) one. We illustrate this issue by considering a scenario where target traces extend source traces by exposing the execution time. While source noninterference requires that private inputs do not affect public outputs, additionally requires that the execution time is not affected by varying private inputs.

To model the scenario described, we represent target traces as pairs of a source trace and a natural number that denotes the time spent to produce the trace (using for infinite time units). Formally, if denotes the set of source traces, then is the set of target traces, where .

Notice that if two source traces , are low-equivalent, then and , but and .

Consider the following straightforward trace relation, which relates a source trace to any target trace whose first component is equal to it, irrespective of execution time:A compiler is CC for this trace relation if any trace that can be exhibited in the target can be simulated in the source in some amount of time. For such a compiler, 3.3 says that if satisfies , then satisfies . This hyperproperty is, however, strictly weaker than , as it contains for example , and one cannot conclude that is noninterfering in the target. It is easy to check thatthe first equality coming from , and the second from being subset-closed. As we will see, this hyperproperty can be characterized as a form of NI, which one might call timing-insensitive noninterference, i.e., ensured only against attackers that cannot measure execution time. For this characterization, and to describe different forms of noninterference as well as formally analyze their preservation by a CC compiler, we rely on the general framework of abstract noninterference [27].

ANI [27] is a generalization of NI whose formulation relies on abstractions (in the sense of Abstract Interpretation [20]) to encompass arbitrary variants of NI. ANI is parameterized by an observer abstraction , which denotes the distinguishing power of the attacker, and a selection abstraction , which specifies when to check NI, and therefore captures a form of declassification [69]. ¹² Formally:

By picking , we recover the standard noninterference defined above, where NI must hold for all low inputs (i.e., no declassification of private inputs), and the observational power of the attacker is limited to distinguishing low outputs. The observational power of the attacker can be weakened by choosing a more liberal relation for . For instance, one may limit the attacker to observe the parity of output integer values. Another way to weaken ANI is to use to specify that noninterference is only required to hold for a subset of low inputs.

The operators and are defined over sets of (input and output projections of) traces, explicitly and . When we write like above, this should be understood as a convenience notation for . Likewise, should be understood as , i.e., the powerset lifting of . Additionally, and are required to be upper-closed operators ()—i.e., monotonic, idempotent, and extensive (i.e., ) —on the poset that is the powerset of (input and output projections of) traces ordered by inclusion [27].

We can now reformulate our example with observable execution times in target traces in terms of ANI. We have with . In this case, the hyperproperty that a compiled program satisfies whenever satisfies can be described as an instance of ANI:The definition of tells us that the trace relation does not affect the selection abstraction, i.e., declassification is unaffected. The definition of characterizes an observer that cannot distinguish execution times for noninterfering traces (notice that in the definition of is discarded). For instance, , for any , , . Therefore, in this setting, we know explicitly through that a CC compiler degrades source noninterference to target timing-insensitive noninterference.

While the particular and above can be discovered by intuition, we want to know whether there is a systematic way of obtaining them in general. In other words, for any trace relation and any notion of source NI, what property is guaranteed on noninterfering source programs by any CC compiler?

We can now answer this question generally (Theorem 5.1): Any source notion of noninterference expressible as an instance of ANI is mapped to a corresponding instance of ANI in the target, whenever source traces are an abstraction of target ones (i.e., when is a total and surjective map). For this result, we consider trace relations that can be split into input and output trace relations (denoted as ) such that . The trace relation corresponds to a Galois connection between the sets of trace properties as described in Section 2.2. Similarly, the pair and corresponds to a pair of Galois connections, and , between the sets of input and output properties. In the timing example, time is an output so we have and is defined as .

The target abstract noninterference has to be intended as the best correct approximation of the source one. The mappings are the existential and universal images of the relation , defined by if and only if . Therefore, and are lower and upper adjoints, respectively (Section 2). The operator is the best correct approximation of w.r.t. to [20] (hence, the choice of the notation). A similar result holds for .

Coming back to our example above, we can formally recover the intuitively justified definitions, i.e., .

As stated above, Theorem 5.1 does not apply to several scenarios from Section 4 such as undefined behavior (Section 4.1). Indeed, in these cases, the relation is not a total map. Nevertheless, we can still exploit our framework to reason about the impact of compilation on noninterference.

Let us consider where is any total and surjective map from target to source inputs (e.g., equality) and is defined as . Intuitively, a CC compiler guarantees noninterference for the compiled program, provided that the target attacker cannot exploit undefined behavior to learn private information. This intuition can be made formal by the following theorem:

Technically, instead of giving us a definition of , the theorem gives a property of it. The property states that, given a target output trace , the attacker cannot distinguish it from any other target output traces produced by other possible compilations () of the source trace it relates to, up to the observational power of the source-level attacker . Therefore, given a source attacker , the theorem characterizes a family of attackers that cannot observe any interference for a correctly compiled noninterfering program. Notice that the target attacker satisfies the premise of the theorem, but defines a trivial hyperproperty, so we cannot prove in general that . Also, this degenerate attacker shows that the family of attackers described in Theorem 5.2 is nonempty, which ensures the existence of a most powerful attacker among them [27].

We now explore the dual question: Under what hypothesis does trace-relating compiler correctness alone allow target noninterference to be reduced to source noninterference? This is of practical interest, as one would be able to protect from target attackers by ensuring noninterference in the source. This task can be made easier if the source language has some static enforcement mechanism [1, 44].

Let us consider the languages from Section 4.4 extended with the ability to accept inputs as (pairs of) values. It is easy to show that the compiler described in Section 4.4 (extended to treat the new input expressions homomorphically) is still CC: Given a target trace with the same inputs of the source one (i.e., ), the compiler of Section 4.4 ensures that simulates the same outputs of (i.e., ). Assume that we want to satisfy a given notion of target noninterference after compilation, i.e., . Recall that the observational power of the target attacker, , is expressed as a property of sequences of values. To express the same property (or attacker) in the source, we have to abstract the way pairs of values are nested. For instance, the source attacker should not distinguish and . In general (i.e., when is not the identity), this argument is valid only when can be represented in the source. More precisely, must consider as equivalent all target inputs that are related to the same source input, because in the source it is not possible to have a finer distinction of inputs. This intuitive correspondence can be formalized as follows:

The results presented in this section formalize and generalize some intuitive facts about compiler correctness and noninterference, clarifying which noninterference property follows “for free” from trace-relating compiler correctness. Of course, in the general case, compiler correctness alone is not a strong enough criterion for dealing with many security properties [8, 23]. This section exploits our ANI-based framework and results to analyze two compilers from the recent literature [7, 74] that are both proven to be correct and to preserve two interesting notions of noninterference: cryptographic constant time (Section 5.7.1) and value-dependent noninterference (Section 5.7.2). For each, we explain how to express compiler correctness as an instance of CC, describe the noninterference property that is implied by the trace relation and the correctness result, and compare it with the noninterference properties of interest as established by their authors.

This section shows the simple generalization of to the trace-relating setting () and its corresponding trinitarian view (6.1). Then, it presents the trinitarian view for criteria that preserve subset-closed hyperproperties (6.2).

The trinity for robust trace property preservation is the straightforward adaptation of the concepts of Section 2 to the definitions of Abate et al. [3]. Intuitively, these criteria simply deal with partial programs instead of whole programs . Necessarily, these criteria then consider arbitrary program contexts linked with ; the universal quantification over and are tacit in the expression .

We can also generalize Section 2 to robust subset-closed hyperproperties (6.2). However, unlike the correct compilation case of Section 2, the equivalent property-free criterion () does not coincide with , but states the existence of a single source context for all the target traces produced by a program in a given context.

In this section, we elaborate the robust preservation of safety (6.3) and hypersafety properties (6.4). Similar to Section 3.2, we consider the trace model adopted by Abate et al. [3] to ease the presentation. Our starting point is the two equivalent criteria for preservation of robust satisfaction of all and only the safety properties [3],where is a shorthand for .

differs from as it only quantifies over safety properties, and differs from as it quantifies over finite prefixes , rather than complete traces . This comes from the fact that safety properties can be characterized in terms of sets of bad prefixes (as in Definition 3.4). Unfolding , we can interpret as follows: If produces a trace that violates a specific safety property, namely, the one defined by , then there exists in which violates the same safety property, producing a trace but possibly distinct from .

Our generalization of to the trace-relating setting states that whenever produces a trace that violates a target safety property, there exists a source context in which violates the source interpretation of the property, i.e., its image through . The following theorem defines and its two equivalent formulations:

Exactly like Section 3.2, Theorem 6.3 exploits the fact thatis a Galois connection between source properties and target safety properties and the argument generalizes to arbitrary closure operators on target properties (). More interestingly, we can further generalize this idea to hypersafety. Hypersafety lifts the idea of safety with another level of sets (just like hyperproperties do w.r.t. trace properties) to talk about multiple runs of the same program. Just like for safety, hypersafety is concerned with a set of bad prefixes (called ) that no program upholding the hypersafety property should extend. Formally, a hyperproperty is hypersafety if: In Theorem 6.4, we indeed exploit the following Galois connection between source subset-closed hyperproperties and target:where and is the closure operator that maps an arbitrary target hyperproperty to the target hypersafety that best over-approximates . ¹⁶

We conclude this section with the following remark: The reader might wonder about extracting a “new” trace relation from the Galois connection and get another formulation of . We note that this is not possible in general, as the class of safety properties, i.e., closed sets, is not necessarily a powerset and hence Lemma 2.7 cannot be applied.

We already mentioned that some properties of interest for security, e.g., possibilistic information-flow are not subset closed [18]. In this section, we lift the results from Section 3.3 to the secure compilation setting. Once again, the trinity is weak, as the equivalence to requires an extra assumption.

It is therefore possible and correct to deduce a source obligation for a given target hyperproperty () when no information is lost in the composition . However, is a consequence of when no information is lost in composing in the other direction, .

Finally, we turn to relational properties and hyperproperties. Relational hyperproperties, as defined by Abate et al. [3], are predicates on a sequence of behaviors; a sequence of programs has the relational hyperproperty if their behaviors collectively satisfy the predicate. Depending on the arity of the sequence, there exist different subclasses of relational hyperproperties, though, for simplicity, here, we only study relational hyperproperties of arity 2. A key example of a relational hyperproperty is trace equivalence, which holds if two programs have identical behaviors.

All the trinities in this section follow the pattern of their non-relational counterparts. We first explain how one can get a Galois connection between source and target relational properties from a trace relation.

Given a trace relation , we can relate pairs of source traces with pairs of target traces point-wise,Formally this is , the product of the relation with itself. Therefore, by Lemma 2.7 it corresponds to a Galois connection between source and target relational properties (), that with a little abuse of notation¹⁷ we still denote by

Explicitly, for and ,

and are then lifted to relational hyperproperties similarly to Definition 3.2. Explicitly, for and ,

Given a relational property and two programs , we write for

Given a relational hyperproperty , by , we mean

Next, we propose the trinity for 2-relational subset-closed hyperproperties, i.e., elements of that are closed under subsets. Exactly as in the case of subset-closed hyperproperties, the application of and may lose the information of being subset-closed. To guarantee the equivalence of the three criteria, we compose the two mappings with a closure operator that we still denote by .

We move now to the class of relational safety properties, a notion that generalizes safety properties to relations on programs. Similarly to Theorem 6.3, quantifies over target relational safety properties, while quantifies over all source relational property and compose with a closure operator that best approximates a relational property with a relational safety property.

Finally, we present the most general criterion: preservation of arbitrary 2-relational hyperproperties. As for the preservation of arbitrary hyperproperties, this (weak) trinity requires additional assumptions to hold, namely, that the Galois connection is an insertion or a reflection.

Figure 4 orders criteria referring to the same trace relation according to their relative strength. If a trinity entails another (denoted by ), then the former provides stronger security for a compilation chain than the latter.

The hypotheses of insertion and reflection mentioned in Theorem 6.9 and Theorem 6.5 are highlighted with the labels “Ins” and “Refl.” Recall that when composing with , we quantify over the whole class of source trace properties rather than only safety properties. This is represented by the blue background in . The trinity for the robust preservation of arbitrary trace properties is on the same blue background. Red and green backgrounds are reserved for subset-closed hyperproperties and arbitrary relational properties and serve the same purpose.

We now describe how to interpret the acronyms in Figure 4. All criteria start with meaning they refer to robust preservation (secure compilation criteria). Criteria for relational hyperproperties—here only arity 2 is shown for simplicity—contain . Next, criteria names spell the class of hyperproperties they preserve: for hyperproperties, for subset-closed hyperproperties, for hypersafety, for trace properties, and for safety properties. Finally, property-free criteria end with a while property-full ones involving and end with . Thus, robust () subset-closed hyperproperty-preserving () compilation () is , robust () two-relational () safety-preserving () compilation () is , and so on.

This subsection illustrates trace-relating secure compilation when the target events are strictly more events than the source ones.

The source and target languages used here extend the syntax of the source language of Section 4.3.1. Both languages have outputs of naturals, and the expressions that generate them: and . Additionally, the target has a different output action and its related expression ; this is the only difference between the languages. The extra events in the target model the ability of target language to perform potentially dangerous operations (e.g., writing to the hard drive), which cannot be performed by the source language, and against which source-level reasoning can therefore offer no protection.

Both languages and compilation chains now deal with partial programs , contexts , and linking of those two to produce whole programs . In this setting, a whole program is the combination of a main expression to be evaluated and a set of function definitions (with distinct names) that can refer to their argument () symbolically and can be called by the main expression and by other functions (. The set of functions of a whole program is the union of the functions of a partial program and a context; the latter also contains the main expression.

The extensions of the typing rules and the operational semantics for whole programs are unsurprising and therefore elided. The trace model also follows closely that of Section 4.3: It consists of a list of regular events (including the new outputs) terminated by a result event.¹⁸ A partial program and a context can be linked into a whole program when their functions satisfy the requirements mentioned above.

We define the homomorphic compiler () that translates each source construct into its target correspondent. Thus, the compiler never introduces the additional target instruction . Since it is straightforward, the formalization of the compiler is elided.

Relating Traces. In the present model, source and target traces differ only in the fact that the target draws (regular) events from a strictly larger set than the source, i.e., . A natural relation between source and target traces essentially maps a given target trace the source trace that erases from those events that exist only at the target level. This is reasonable, because only target contexts (not compiled programs ) can perform the extra target actions, as the compiler does not introduce them. Let indicate trace filtered to retain only those elements included in alphabet . We define the trace relation as:

In the opposite direction, a source trace is related to many target ones, as any target-only events can be inserted at any point in . The induced mappings for this relation are:

That is, the target guarantee of a source property is that the target has the same source-level behavior, sprinkled with arbitrary target-level behavior. Conversely, the source-level obligation of a target property is the aggregate of those source traces, all of whose target-level enrichments are in the target property.

Since the languages are very similar, it is simple to prove that our compiler is secure according to the trace relation defined above.

I/O events are not the only instance of events that compilers consider. Especially in the setting of secure compilation, where a compartmentalized partial program interacts with a context, interaction traces are often used [3, 35, 59, 64]. Consider a language analogous to that of the previous section, where the context defines a set of functions and the program defines a different set . Interaction traces (generally) record the control flow of calls between these two sets via actions that are and [34]. These actions indicate a call to function with parameter and a return with return value . In case the context calls a function in (or returns to a function in ), the action is decorated with a (i.e., those actions are and ). Dually, the program calling a function in (or returning to it) generates an action decorated with a (i.e., those actions are and ).

Patrignani and Garg [64] consider precisely such a setting. Their languages are simple like those presented here but impure; their source has an ML-like heap and the target has a memory that is indexed by natural numbers and capabilities to protect addresses. Moreover, they define a compiler that preserves safety properties of source programs (i.e., it is in the sense of 6.3) by relying on the target capabilities. The interesting point, however, is that they also consider source and target traces to be distinct, since the two languages have different values. Concretely, the source has and and the target only has , plus in the source, heap addresses are abstract locations while in the target they are . Thus, to prove , they rely on a cross-language relation on values, which is lifted to trace actions, and then lifted point-wise to traces (analogously to what we have done in Section 4.3, 4.4, and 7.1). To relate addresses, their cross-language relation is equipped with a partial bijection between source and target addresses, this bijection grows monotonically with every reduction step.

Besides defining a relation on traces (which is an instance of ), they also define a relation between source and target safety properties that supports concurrent programs. ¹⁹ Thus, they really provide an instantiation of that maps all safe source traces to the related target ones. This ensures that no additional target trace is introduced in the target property, and source safety properties are mapped to target safety ones by . Thus, their compiler is proven to generate code that respects , so they really achieve a variation of from 6.3. Their proofs are based on standard techniques either for secure compilation (i.e., trace-based backtranslation [61]) and for correct compilation (i.e., forward/backward simulation [42]).

Patrignani and Garg [63] study the preservation of hypersafety from the perspective of secure compilation. Again, their result can be interpreted in our setting. They consider reactive systems, where trace alphabets are partitioned in input actions and output actions , whose concatenation generate traces . We use the same notation as before and indicate such sequences as and , respectively. The set of target output actions includes an action that has no source counterpart (i.e., ) and whose output does not depend on internal state (thus, it cannot leak secrets). ²⁰ By emitting whenever undesired inputs are fed to a compiled program (e.g., passing a when a is expected), hypersafety is preserved (as does not leak secrets) [63].

More formally, they assume a relation on actions that is total on the source actions and injective. From there, they define —which here corresponds to an instance of — that maps the set of valid source traces to the set of valid target traces (that now mention ) as follows:where indicates that is an undesired input (intuitively, this is an information that can be derived from the set of source traces [63]).

Informally, given a set of source traces , generates all target traces that are related (point-wise) to a source trace (case ). Then (case ), it adds all traces () with interleavings of undesired input (third conjunct) followed by (first conjunct) as long as the interleavings split a trace that has already been mapped (second conjunct).

is an instance of that maps source hypersafety to target hypersafety (and therefore, safety to safety), thus our theory can be instantiated for the preservation of these classes of hyperproperties as well.