Trace-Relating Compiler Correctness and Secure Compilation

Abstract

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...

SecurePtrs: Proving Secure Compilation with Data-Flow Back-Translation and Turn-Taking Simulation

“…We extend both languages by allowing safe pointers to be passed to and dereferenced by other components, thus introducing dynamic memory sharing. We then prove again that this extended compilation step is secure with respect to a criterion called "robust safety preservation" [4,5,37]. For this, we apply our two new techniques, data-flow back-translation and turn-taking simulations.…”

A conflicts’ classification for IoT-based services: a comparative survey

“…A plethora of defense techniques and approaches have been proposed and applied in different domains and contexts for the above-mentioned issues. Among these techniques are Security Policy Enforcement ( Herrmann & Murari, 2004 ; Sicari et al, 2016 ; Neisse, Steri & Baldini, 2014 ; Keromytis & Wright, 2000 ; Adi, Hamza & Pene, 2018 ), Language-based Security ( Abadi, Morrisett & Sabelfeld, 2005 ; Bandi, Fellah & Bondalapati, 2019 ; Khan et al, 2019 ; Vaidya et al, 2019 ; Zigmond et al, 2019 ), Formal-language Verification ( Foughali et al, 2018 ; Fragoso Santos et al, 2017 ; Grimm, Lettnin & Hübner, 2018 ; Abbas et al, 2020 ; Halima et al, 2018 ), Software Verification ( Rodriguez, Piattini & Ebert, 2019 ; Feldt et al, 2010 ; Zheng et al, 2014 ; Miksa & Rauber, 2017 ; Zhang et al, 2019b ), and Developing Secure Compiler ( Busi & Galletta, 2019 ; Lee, Jeong & Son, 2017 ; Zúñiga et al, 2020 ; Abate et al, 2020 ; Hastings et al, 2019 ). All of these methods and others share the same approach.…”

Peer Review #1 of "A conflicts’ classification for IoT-based services: a comparative survey (v0.1)"

“…A plethora of defense techniques and approaches have been proposed and applied in different domains and contexts for the above-mentioned issues. Among these techniques are Security Policy Enforcement (Herrmann and Murari, 2004;Sicari et al, 2016;Neisse et al, 2014;Keromytis and Wright, 2000;Adi et al, 2018), Language-based Security (Abadi et al, 2005;Bandi et al, 2019;Khan et al, 2019;Vaidya et al, 2019;Zigmond et al, 2019), Formal-language Verification (Foughali et al, 2018;Fragoso Santos et al, 2017;Grimm et al, 2018;Abbas et al, 2020;Halima et al, 2018), Software Verification (Rodriguez et al, 2019;Feldt et al, 2010;Zheng et al, 2014;Miksa and Rauber, 2017;Zhang et al, 2019b), and Developing Secure Compiler (Busi and Galletta, 2019;Lee et al, 2017;Zúñiga et al, 2020;Abate et al, 2020;Hastings et al, 2019). All of these methods and others share the same approach.…”