On Modular and Fully-Abstract Compilation

Patrignani, Marco; Devriese, Dominique; Piessens, Frank

doi:10.1109/csf.2016.9

Cited by 22 publications

(65 citation statements)

References 50 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Unfortunately, they do not have traces, though were one to add them, the logical relation on values would serve as the basis for the trace relation and therefore their result would attain CC ∼ . Some secure compilation results do not rely on traces for their security criterion (instead proving compiler full abstraction [1,40]) but they rely on target-level traces as a proof technique [3,18,20,38,39]. Most of these results consider a cross-language relation that could be lifted to source traces (were they added), so they can be proved to attain one of the criteria from Figure 3.…”

Section: Related Workmentioning

confidence: 99%

Trace-Relating Compiler Correctness and Secure Compilation

Abate

Blanco

Ciobâcă³

et al. 2020

Programming Languages and Systems

Self Cite

View full text Add to dashboard Cite

Compiler correctness is, in its simplest form, defined as the inclusion of the set of traces of the compiled program into the set of traces of the original program, which is equivalent to the preservation of all trace properties. Here traces collect, for instance, the externally observable events of each execution. This definition requires, however, the set of traces of the source and target languages to be exactly the same, which is not the case when the languages are far apart or when observations are fine grained. To overcome this issue, we study a generalized compiler correctness definition, which uses source and target traces drawn from potentially different sets and connected by an arbitrary relation. We set out to understand what guarantees this generalized compiler correctness definition gives us when instantiated with a non-trivial relation on traces. When this trace relation is not equality, it is no longer possible to preserve the trace properties of the source program unchanged. Instead, we provide a generic characterization of the target trace property ensured by correctly compiling a program that satisfies a given source property, and dually, of the source trace property one is required to show in order to obtain a certain target property for the compiled code. We show that this view on compiler correctness can naturally account for undefined behavior, resource exhaustion, different source and target values, side-channels, and various abstraction mismatches. Finally, we show that the same generalization also applies to a large class of secure compilation definitions, which characterize the protection of a compiled program against linked adversarial code. INTRODUCTIONCompiler correctness is an old idea [28,30,31] that has seen a significant revival in the recent past. This new wave was started by the creation of the CompCert verified C compiler [25] and continued by the proposal of many significant extensions and variants of CompCert [7,13,21,22,32,42,47,49,53] and the success of many other milestone compiler verification projects, including Vellvm [54], Pilsner [33], CakeML [50], Jasmin [5], CertiCoq [6], etc. Yet, even for these verified compilers, the precise statement of correctness matters. Since proof assistants are used to conduct the verification, an external observer does not have to understand the proofs in order to trust them, but one still has to deeply understand the statement that was proved. And this is true not just for correct compilation, but also for secure compilation, which is the more recent idea that our compilation chains should do more to also ensure the security of our programs [4,16].Basic Compiler Correctness. The gold standard for compiler correctness is semantic preservation, which intuitively says that the semantics of a compiled program (in the target language) is compatible with the semantics of the original program (in the source language). For practical verified compilers, such as CompCert [25] and CakeML [50], semantic preservation is stated extrinsically, by refer...

show abstract

Section: Related Workmentioning

confidence: 99%

Trace-Relating Compiler Correctness and Secure Compilation

Abate

Blanco

Ciobâcă³

et al. 2020

Programming Languages and Systems

Self Cite

View full text Add to dashboard Cite

show abstract

“…Full-abstraction as stated in Theorem 6.3 is not a correct criterion for modular compilers, as it is stated for closed terms. Instead, a generalisation exists for modular compilers: modular full-abstraction [Patrignani et al, 2016]. Modular full-abstraction forces one to reason about linking of programs when developing a fully-abstract compiler.…”

Section: Modular Fully-abstract Compilationmentioning

confidence: 99%

“…An earlier version of this paper, published at POPL 2016, introduced the technique of approximate back-translations, and applied it to prove full abstraction for a whole-program compiler from λ τ to λ u [Devriese et al, 2016]. This journal version extends the conference version in two ways.…”

Section: Introductionmentioning

confidence: 99%

Fully-abstract compilation by approximate back-translation

2016

Self Cite

View full text Add to dashboard Cite

A compiler is fully-abstract if the compilation from source language programs to target language programs reflects and preserves behavioural equivalence. Such compilers have important security benefits, as they limit the power of an attacker interacting with the program in the target language to that of an attacker interacting with the program in the source language. Proving compiler full-abstraction is, however, rather complicated. A common proof technique is based on the back-translation of target-level program contexts to behaviourally-equivalent source-level contexts. However, constructing such a backtranslation is problematic when the source language is not strong enough to embed an encoding of the target language. For instance, when compiling from a simply-typed λcalculus (λ τ ) to an untyped λ-calculus (λ u ), the lack of recursive types in λ τ prevents such a back-translation.We propose a general and elegant solution for this problem. The key insight is that it suffices to construct an approximate back-translation. The approximation is only accurate up to a certain number of steps and conservative beyond that, in the sense that the context generated by the back-translation may diverge when the original would not, but not vice versa. Based on this insight, we describe a general technique for proving compiler full-abstraction and demonstrate it on a compiler from λ τ to λ u . The proof uses asymmetric cross-language logical relations and makes innovative use of step-indexing to express the relation between a context and its approximate back-translation. The proof extends easily to common compiler patterns such as modular compilation and, to the best of our knowledge, it is the first compiler full abstraction proof to have been fully mechanised in Coq. We believe this proof technique can scale to challenging settings and enable simpler, more scalable proofs of compiler full-abstraction. 2012 ACM CCS: [Security and privacy Logic and verification]: 300; [Software and its engineering General programming languages]: 300; [Software and its engineering Compilers]: 300.

show abstract

“…When the target language is low-level, hiding code attributes can be difficult: it may require padding the code segment of the compiled program to a fixed size, and cleaning or hiding any code-layout-dependent data like code pointers from memory and registers when passing control to the context. These complex protections are not necessary for any non-relational preservation criteria (even RHP), but are already known to be necessary for fully abstract compilation to low-level code [55,57,76,77]. They can also be trivially circumvented if the context has access to any side-channels, e.g., it can measure time via a different thread.…”

Section: Separation Between Relational and Non-relationalmentioning

confidence: 99%

“…They were interested in proving full abstraction for so-called trace semantics. This technique was then adapted to show full abstraction of compilation chains to low-level target languages [6,73,76,77]. In §6.4, we showed how these trace-based techniques can be extended to prove all the criteria below RFrXP in Figure 1, which includes robust preservation of safety, of noninterference, and in a determinate setting also of observational equivalence.…”

Section: Hypersafety Preservationmentioning

confidence: 99%

Journey Beyond Full Abstraction: Exploring Robust Property Preservation for Secure Compilation

Abate

Blanco

Garg

et al. 2019

2019 IEEE 32nd Computer Security Foundations Symposium (CSF)

Self Cite

View full text Add to dashboard Cite

Good programming languages provide helpful abstractions for writing secure code, but the security properties of the source language are generally not preserved when compiling a program and linking it with adversarial code in a low-level target language (e.g., a library or a legacy application). Linked target code that is compromised or malicious may, for instance, read and write the compiled program's data and code, jump to arbitrary memory locations, or smash the stack, blatantly violating any source-level abstraction. By contrast, a fully abstract compilation chain protects source-level abstractions all the way down, ensuring that linked adversarial target code cannot observe more about the compiled program than what some linked source code could about the source program. However, while research in this area has so far focused on preserving observational equivalence, as needed for achieving full abstraction, there is a much larger space of security properties one can choose to preserve against linked adversarial code. And the precise class of security properties one chooses crucially impacts not only the supported security goals and the strength of the attacker model, but also the kind of protections a secure compilation chain has to introduce.We are the first to thoroughly explore a large space of formal secure compilation criteria based on robust property preservation, i.e., the preservation of properties satisfied against arbitrary adversarial contexts. We study robustly preserving various classes of trace properties such as safety, of hyperproperties such as noninterference, and of relational hyperproperties such as trace equivalence. This leads to many new secure compilation criteria, some of which are easier to practically achieve and prove than full abstraction, and some of which provide strictly stronger security guarantees. For each of the studied criteria we propose an equivalent "property-free" characterization that clarifies which proof techniques apply. For relational properties and hyperproperties, which relate the behaviors of multiple programs, our formal definitions of the property classes themselves are novel. We order our criteria by their relative strength and show several collapses and separation results. Finally, we adapt existing proof techniques to show that even the strongest of our secure compilation criteria, the robust preservation of all relational hyperproperties, is achievable for a simple translation from a statically typed to a dynamically typed language.(∀C T . ∀t 1 , .., t k , ..(∀i.C T [P i ] t i ) ⇒ (t 1 , .., t k , ..) ∈ R)

show abstract

On Modular and Fully-Abstract Compilation

Cited by 22 publications

References 50 publications

Trace-Relating Compiler Correctness and Secure Compilation

Trace-Relating Compiler Correctness and Secure Compilation

Fully-abstract compilation by approximate back-translation

Journey Beyond Full Abstraction: Exploring Robust Property Preservation for Secure Compilation

Contact Info

Product

Resources

About