Verified secure compilation for mixed-sensitivity concurrent programs

Abstract

Proving only over source code that programs do not leak sensitive data leaves a gap between reasoning and reality that can only be filled by accounting for the behaviour of the compiler. Furthermore, software does not always have the luxury of limiting itself to single-threaded computation with resources statically dedicated to each user to ensure the confidentiality of their data. This results in mixed-sensitivity concurrent programs, which might reuse memory shared between their threads to hold data of different sensitivity levels at different times; for such programs, a compiler must preserve the value-dependent coordination of such mixed-sensitivity reuse despite the impact of concurrency. Here we demonstrate, using Isabelle/HOL, that it is feasible to verify that a compiler preserves noninterference, the strictest kind of confidentiality property, for mixed-sensitivity concurrent programs. First, we present notions of refinement that preserve a concurrent value-dependent notion of noninterference that we have designed to support such programs. As proving noninterference-preserving refinement can be considerably more complex than the standard refinements typically used to verify semantics-preserving compilation, our notions include a decomposition principle that separates the semantics preservation from security preservation concerns. Second, we demonstrate that these refinement notions are applicable to verified secure compilation, by exercising them on a single-pass compiler for mixed-sensitivity concurrent programs that synchronise using mutex locks, from a generic imperative language to a generic RISC-style assembly language. Finally, we execute our compiler on a non-trivial mixed-sensitivity concurrent program modelling a real-world use case, thus preserving its source-level noninterference properties down to an assembly-level model automatically. All results are formalised and proved in the Isabelle/HOL interactive proof assistant. Our work paves the way for more fully featured compilers to offer verified secure compilation support to developers of multithreaded software that must handle data of multiple sensitivity levels.

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

“…Secure compilation of information-flow guarantees A long line of work [8,9,10,11,12,34,44,45] develops proof techniques and verified compilers to ensure that information flow properties like non-interference, the constant-time policy, or side-channel resistance are preserved by compilation. These techniques, however, are all concerned with whole-programs, unlike our work that starts with the premise that partial programs will interact with untrusted code.…”

Verified Secure Compilation for Mixed-Sensitivity Concurrent Programs

“…Discharging this once-off noncompositional proof obligation is crucial in enabling both composition of per-thread noninterference properties (using Theorem 2.8), and compositional whole-system secure refinement noninterference down to RISC by our compiler (using Theorem 2.23). Further details on the proof techniques for the per-thread noninterference and local-mode-compliance properties are relegated to Sison (2020), as well as Murray et al (2016b,c) from which they were adapted.…”

“…To ensure that the While evaluation semantics is defined for all possible configurations, the LOCKINVALID rule defines a stuttering evaluation step for attempts to unlock(k) that are an apparent violation of the locking discipline due to not having previously acquired the lock k. Program developers can rely on a local mode compliance check to reject programs that misbehave in attempting to do this; details are relegated to Sison (2020).…”

“…Disallowing lock-variables from being control variables thus simplifies the proof of soundness of the local compliance check, as lock(k) and unlock(k) (which only access lock-variable k) cannot violate any guarantees active for program-variables. Details are relegated to Sison (2020).…”

“…This section will present proof that global-modes-compatibility (Definition 2.12) holds as an invariant for concurrent While programs (Section 3.3) when initialised to have no locks held (Section 3.4). Consequently, it is sufficient for a developer to use a local compliance check (Sison, 2020) to obtain the sound-mode-use condition (Definition 2.10) needed for per-thread security proofs to be compositional via Theorem 2.8. Recall from Section 2.2 that this compatibility requirement formalises that for all reachable global configurations of a concurrent program, any assumptions made by any of the threads must be met by corresponding guarantees made by all of the other threads: Definition 2.12 (Global modes compatibility).…”