Threat Mitigation & Lessons from Meltdown & Spectre

By Richard Grisenthwaite, Chief Architect and Fellow, Arm

At the very start of 2018, Meltdown and Spectre broke into the news headlines as a new class of attack using timing side channels to enable the revelation of more privileged data through the exploitation of processor speculation. Until these approaches were discovered, CPU designers regarded speculation as being effectively invisible to the programmer, as there are no architectural state changes caused by the speculation.

However, Meltdown and Spectre make speculation visible to an attacker. Speculation causes changes to the micro-architectural state, such as the loading of data into caches or translation lookaside buffers (TLBs), and this improves performance by allowing data to be accessed earlier than would be the case without speculation. Meltdown and Spectre used the time taken to perform some operations to detect the changes in the micro-architectural state of the processor, and from that infer data that should not be accessible. The different terms “Spectre” and “Meltdown” are actually different manifestations of this style of retrieving information, and they are given different names as they have quite different properties.

Comparing Meltdown, Spectre approaches Meltdown is a form of this approach that an attacker can exploit with relative ease. Meltdown exploits a micro-architectural behavior in some CPUs where data loaded from memory locations associated with memory permission faults could still be used speculatively to generate addresses for speculative accesses. Fortunately, it is relatively straightforward to modify an operating system to avoid this issue, and patches to all the main operating systems used on Arm have been made available to ensure that the Meltdown cannot be exploited even where the hardware has the susceptible micro-architecture behavior. In addition, this particular micro- architecture behavior is prohibited from all Arm implementations going forward.

The term Spectre is used more generically to cover the exploitation of speculative execution in sequences of code present at a level of privilege that an attacker cannot access. In the various Spectre scenarios, the attacker is able to influence how that speculation is occurring, for example by passing out-of-range data values to some supervisory software, or by training the branch predictor. These approaches are inherently much harder to exploit than Meltdown. Some of the variants of Spectre can be addressed by patches to the operating system or hypervisor and can be prohibited in future hardware. Where this is practical it is being done.

However, for Spectre variant 1 in particular, identification of exploitable code requires the identification of an extremely common code sequence – checking that an offset to memory is in-range and then using that offset to access memory – combined with the knowledge that the offset is controlled by the attacker. Where the code sequence exists, but the offset is not controlled by the attacker, the code sequence is benign, and speculation can occur. But if the offset is attacker- controlled, then there is a potentially exploitable vulnerability.

Tradeoffs in design-for-security This means that the compiler, which typically does not have sufficient information to identify the provenance of the offset, cannot distinguish the safe places to speculate from the unsafe without more information. In this case, if we simply disable speculation wherever these sequences are found, we end up disabling a lot of the common harmless speculation as well as the rare exploitable cases.

Disabling speculation in all such cases would secure the system against Spectre attacks, but with a potentially unacceptable performance cost. Therefore, for many systems, depending on the level of security required, the performance cost of trying to address Spectre variant 1 automatically in a compiler will be unacceptably high. The optimal approach is that speculation is disabled only where the software has been annotated at the source code level to indicate that an offset is potentially attacker-controllable. A small number of such annotations have been added into operating systems such as the Linux kernel where possibly exploitable vulnerabilities have been identified.

Arm is also investigating ways in the design of the hardware to make it far harder for an attacker to exploit Spectre variant 1 in the places in the software that haven’t been identified as needing to have speculation disabled, without losing all the key benefits of speculation in the performance of our devices. This will give systems a layered approach to addressing Spectre variant 1, with software annotations to provide safety for identified cases where an offset can be influenced by the attacker, and an inherent robustness should such a case be overlooked.