Reading 'Spectre is here to stay'
14 Mar 2019
This paper addresses three open problems made more relevant since Spectre:
- finding side-channels
- understanding speculative vulnerabilities
- mitigating them
This paper begins by introducing a formal model for CPU architectures in order to study spectre. They distinguish the observable state of an architecture (what a developer might see from its API) from the micro architecture (extra state kept by the CPU). They then study the model and a class of attacks known as side-channel attacks. Whenever state is exposed from the micro architecture, there is a possibility of an attacker to gain information they should not have. For example, speculative execution can cause data to be read into a cache. Based on timing, an attacker might gain some information about the, perhaps confidential, data.
A main result from their study is that in most programming languages
with timers, speculative vulnerabilities on most modern CPUs allow for
the construction of a (well-typed) function with signature
read(address: int, bit: int) → bit. Frightening.
The paper then describes possible mitigations and their runtime impact.
For instance, one mitigation was to augment every branch with an
instruction (as suggested by Intel). This led to a 2.8x slowdown on
led to a 1.52x slowdown on Octane.
none of the mitigations completely protect against Spectre.