Exorcising Spectres with Secure Compilers
share
Speculative execution has been demonstrated to leak information about execution in case the speculation is ill-informed. This has lead to the Spectre family of attacks (i.e., Spectre v1, v2 and rbr) and the related compiler-inserted countermeasures. Spectre (v1) and the speculative semantics needed to express it has been recently formalised in a number of works, so we have the techniques to formally express a Spectre-like violation. However, the correctness (and security) of compiler-inserted Spectre countermeasures has not been ascertained yet. Even worse, while some of the existing countermeasures seem to be secure, others are known to be insecure and still leave vulnerabilities to Spectre. We want to investigate whether existing compilers are effectively secure against Spectre attacks or not. For this, we build on recent secure compilation theory telling that a compiler is secure when it preserves certain classes of (hyper)properties. In fact, Spectre-like attacks are violations of speculative non-interference, a non-interference-like property, which is a 2-Hypersafety property. We aim to show that certain compiler countermeasures preserve any 2-Hypersafety property and therefore are secure against Spectre. On the other hand, we want to demonstrate that other compilers do not preserve speculative non-interference, and as such they do not defend against Spectre. We believe this is the first step towards talking about compiler security against the whole Spectre family of attacks.
READ FULL TEXT