It is common to prove by reasoning over source code that programs do not leak sensitive data. But doing so leaves a gap between reasoning and reality that can only be filled by accounting for the behaviour of the compiler. This task is complicated when programs enforce value-dependent information-flow security properties (in which classification of locations can vary depending on values in other locations) and complicated further when programs exploit shared-variable concurrency. Prior work has formally defined a notion of concurrency-aware refinement for preserving value-dependent security properties. However, that notion is considerably more complex than standard refinement definitions typically applied in the verification of semantics preservation by compilers. To date it remains unclear whether it can be applied to a realistic compiler, because there exist no general decomposition principles for separating it into smaller, more familiar, proof obligations. In this work, we provide such a decomposition principle, which we show can almost halve the complexity of proving secure refinement. Further, we demonstrate its applicability to secure compilation, by proving in Isabelle HOL the preservation of value-dependent security by a proof-of-concept compiler from an imperative While language to a generic RISC-style assembly language, for programs with shared-memory concurrency mediated by locking primitives. Finally, we execute our compiler in Isabelle on a While language model of the Cross Domain Desktop Compositor, demonstrating to our knowledge the first use of a compiler verification result to carry an information-flow security property down to the assembly-level model of a non-trivial concurrent program.
@cite_27: Good programming languages provide helpful abstractions for writing more secure code, but the security properties from the source language are generally not preserved when compiling a program and linking it with adversarial low-level code. Linked low-level code that is malicious or compromised can for instance read and write the compiled program's data and code, jump to arbitrary instructions, or smash the stack, blatantly violating any source-level abstraction. By contrast, a secure compilation chain protects source-level abstractions all the way down, ensuring that even an adversarial target-level context cannot break the security properties of a compiled program any more than some source-level context could. However, the precise class of security properties one chooses to preserve crucially impacts not only the supported security goals and the strength of the attacker model, but also the kind of protections the compilation chain has to introduce and the kind of proof techniques one can use. Since efficiently achieving and proving secure compilation at scale are challenging open problems, designers of secure compilation chains have to strike a pragmatic balance between security and efficiency that matches their application domain. To inform this difficult design decision, we thoroughly explore a large space of secure compilation criteria based on the preservation of properties that are robustly satisfied against arbitrary adversarial contexts. We study robustly preserving classes of trace properties such as safety, of hyperproperties such as noninterference, and of relational hyperproperties such as trace equivalence. For each of the studied classes we propose an equivalent "property-free" characterization that is generally better tailored for proofs. We, moreover, order the secure compilation criteria by their relative strength and prove several separation results. ((((cropped))))
@cite_3: 
@cite_23: Secure compilation is a discipline aimed at developing compilers that preserve the security properties of the source programs they take as input in the target programs they produce as output. This discipline is broad in scope, targeting languages with a variety of features (including objects, higher-order functions, dynamic memory allocation, call cc, concurrency) and employing a range of different techniques to ensure that source-level security is preserved at the target level. This article provides a survey of the existing literature on formal approaches to secure compilation with a focus on those that prove fully abstract compilation, which has been the criterion adopted by much of the literature thus far. This article then describes the formal techniques employed to prove secure compilation in existing work, introducing relevant terminology, and discussing the merits and limitations of each work. Finally, this article discusses open challenges and possible directions for future work in secure compilation.
@cite_11: Secure compilers generate compiled code that withstands many target-level attacks such as alteration of control flow, data leaks or memory corruption. Many existing secure compilers are proven to be fully abstract, meaning that they reflect and preserve observational equivalence. Fully abstract compilation is strong and useful but, in certain cases, comes at the cost of requiring expensive runtime constructs in compiled code. These constructs may have no relevance for security, but are needed to accommodate differences between the source and target languages that fully abstract compilation necessarily needs.
Other recent works have improved on (surveyed @cite_23 ) by mapping out the spectrum @cite_27 or developing specific forms @cite_11 of , concerned with of source program (hyper)properties to concrete contexts. Like @cite_3 , these works differ from ours in quantifying over a wider range of hostile interference. They also focus prominently on changes to data types, which we do not support. Thus, as a 2-safety hyperproperty quantifying over a lesser range of interference, we expect CVDNI-preservation to be implied by R2HSP (robust 2-hypersafety preservation), but do not expect it to imply any other secure compilation criterion on 's @cite_27 spectrum.