SafeSpec: Banishing the Spectre of a Meltdown with Leakage-Free Speculation

Submitted on 13 Jun 2018

Speculative execution which is used pervasively in modern CPUs can leave side effects in the processor caches and other structures even when the speculated instructions do not commit and their direct effect is not visible. The recent Meltdown and Spectre attacks have shown that this behavior can be exploited to expose privileged information to an unprivileged attacker. In particular, the attack forces the speculative execution of a code gadget that will carry out the illegal read, which eventually gets squashed, but which leaves a side-channel trail that can be used by the attacker to infer the value. Several attack variations are possible, allowing arbitrary exposure of the full kernel memory to an unprivileged attacker. In this paper, we introduce a new model (SafeSpec) for supporting speculation in a way that is immune to side-channel leakage necessary for attacks such as Meltdown and Spectre. In particular, SafeSpec stores side effects of speculation in a way that is not visible to the attacker while the instructions are speculative. The speculative state is then either committed to the main CPU structures if the branch commits, or squashed if it does not, making all direct side effects of speculative code invisible. The solution must also address the possibility of a covert channel from speculative instructions to committed instructions before these instructions are committed. We show that SafeSpec prevents all three variants of Spectre and Meltdown, as well as new variants that we introduce. We also develop a cycle accurate model of modified design of an x86-64 processor and show that the performance impact is negligible. We build prototypes of the hardware support in a hardware description language to show that the additional overhead is small. We believe that SafeSpec completely closes this class of attacks, and that it is practical to implement.

FreeBSD 11.2R released, with speculative execution and UEFI updates

The latest version of FreeBSD is out, and has a few speculative execution and UEFI changes, including:

[arm64] The bsdinstall(8) installer has been updated to default to UEFI-only boot. [r322254]
(Sponsored by The FreeBSD Foundation)

The efibootmgr(8) utility has been added, which is used to manipulate the EFI boot manager. [r332126]
(Sponsored by Netflix)

The cpucontrol(8) utility has been updated to include a new flag, -e, which is used to re-evaluate reported CPU features after applying firmware updates. [r327871]
Note: The cpucontrol(8) -e flag should only be used after microcode update have been applied to all CPUs in the system, otherwise system instability may be experienced if processor features are not identical across the system.

FreeBSD-SA-18:03.speculative_execution 14 March 2018.  Speculative Execution Vulnerabilities
Note: This advisory addresses the most significant issues for FreeBSD 11.x on amd64 CPUs. We expect to update this advisory to include i386 and other CPUs.

Graz: School on Security and Correctness in the IoT 2018

Welcome to our second School on Security & Correctness in the Internet of Things 2018, held from 3.-9. September. It is hosted by the research center “Dependable Internet of Things“, located at Graz University of Technology. This school targets graduate students interested in security aspects of tomorrow’s IoT devices. Current advances in technology drive miniaturization and efficiency of computing devices, opening a variety of novel use cases like autonomous transportation, smart cities and health monitoring devices. However, device malfunction could potentially threaten human welfare or even life. Malfunction might not only be caused by design errors but also by intentional impairment. As computing devices are supposed to have high and permanent network connectivity, an attacker finding a vulnerability might easily target millions of devices at once. Moreover, integration of computing devices in everyday items exposes them to a potentially hostile physical environment. A central requirement of tomorrow’s IoT is the ability to execute software dependably on all kinds of devices. IoT devices need to provide security in the presence of network attacks as well as against attackers having physical access to the device. During the five-day school, participants will gain awareness of these IoT-related challenges. Introductory classes are supplemented by advanced courses in the area of system security, cryptography as well as software and hardware side-channels. During spare time participants are invited to enjoy the city of Graz and attend organized events.

Chromium: Post-Spectre Threat Model Re-Think

In light of Spectre/Meltdown, we needed to re-think our threat model and defenses for Chrome renderer processes. Spectre is a new class of hardware side-channel attack that affects (among many other targets) web browsers. This document describes the impact of these side-channel attacks and our approach to mitigating them. The upshot of the latest developments is that the folks working on this from the V8 side are increasingly convinced that there is no viable alternative to Site Isolation as a systematic mitigation to SSCAs [speculative side-channel attacks]. In this new mental model, we have to assume that user code can reliably gain access to all data within a renderer process through speculation. This means that we definitely need some sort of ‘privileged/PII data isolation’ guarantees as well, for example ensuring that password and credit card info are not speculatively loaded into a renderer process without user consent. […] In fact, any software that both (a) runs (native or interpreted) code from more than one source; and (b) attempts to create a security boundary inside a single address space, is potentially affected. For example, software that processes document formats with scripting capabilities, and which loads multiple documents from different sources into the same process, may need to take defense measures similar to those described here.[…]


Spectre Variant 4 released


Polymorphic Linux: stops zero-day attacks like Spectre and Meltdown

QEMU v2.12.0 released (with Spectre/Meltdown update)

QEMU version 2.12.0 released
24 Apr 2018
This release contains 2700+ commits from 204 authors.

* Spectre/Meltdown mitigation support for x86/pseries/s390 guests.
* Better IPMI support for Platform Events and SEL logging in internal BMC emulation
* SMBIOS support for “OEM Strings”, which can be used for automating guest image activation without relying on network-based querying

[…]A previous post detailed how QEMU/KVM might be affected by Spectre/Meltdown attacks, and what the plan was to mitigate them in QEMU 2.11.1 (and eventually QEMU 2.12). QEMU 2.11.1 is now available, and contains the aforementioned mitigation functionality for x86 guests, along with additional mitigation functionality for pseries and s390x guests (ARM guests do not currently require additional QEMU patches). However, enabling this functionality requires additional configuration beyond just updating QEMU, which we want to address with this post.[…]

More on QEMU and Spectre/Meltdown:

Microsoft: C++ Developer Guidance for Speculative Execution Side Channels

C++ Developer Guidance for Speculative Execution Side Channels
Matt Miller Colin Robertson Mike B

This article contains guidance for developers to assist with identifying and mitigating speculative execution side channel hardware vulnerabilities in C++ software. These vulnerabilities can disclose sensitive information across trust boundaries and can affect software that runs on processors that support speculative, out-of-order execution of instructions. This class of vulnerabilities was first described in January, 2018 and additional background and guidance can be found in Microsoft’s security advisory. The guidance provided by this article is related to the class of vulnerabilities represented by CVE-2017-5753, also known as Spectre variant 1. This hardware vulnerability class is related to side channels that can arise due to speculative execution that occurs as a result of a conditional branch misprediction. The Visual C++ compiler in Visual Studio 2017 (starting with version 15.5.5) includes support for the /Qspectre switch provides a compile-time mitigation for a limited set of potentially vulnerable coding patterns related to CVE-2017-5753. The documentation for the /Qspectre flag provides more information on its effects and usage.[…]

[…]An accessible introduction to speculative execution side channel vulnerabilities can be found in the presentation titled The Case of Spectre and Meltdown by one of the research teams that discovered these issues.[…]


more on Spectre/Meltdown

A few new Spectre/Meltdown-related things in the news:

US CERT update on Spectre/Meltdown

This updated alert is a follow-up to the updated alert titled ICS-ALERT-18-011-01 Meltdown and Spectre Vulnerabilities (Update F) that was published March 1, 2018, on the NCCIC/ICS-CERT website.


AMD: Spectre Mitigation Update

Spectre Mitigation Update

Today, AMD is providing updates regarding our recommended mitigations for Google Project Zero (GPZ) Variant 2 (Spectre) for Microsoft Windows users. These mitigations require a combination of processor microcode updates from our OEM and motherboard partners, as well as running the current and fully up-to-date version of Windows. For Linux users, AMD recommended mitigations for GPZ Variant 2 were made available to our Linux partners and have been released to distribution earlier this year.[…]

LLVM: Speculative Load Hardening (a Spectre variant #1 mitigation)


Using Intel C/Fortran to mitigate against Spectre/Meltdown

Using Intel® Compilers to Mitigate Speculative Execution Side-Channel Issues
Jennifer J. (Intel)
March 23, 2018

Table of Content:
Mitigating Bounds Check Bypass (Spectre Variant 1)
Mitigating Branch Target Injection (Spectre Variant 2)
How to Obtain the Latest Intel® C++ Compiler and Intel® Fortran Compiler
Conclusion and Further Reading

LLVM 6.0.0 Released, includuing Spectre variant2 mitigations

This release is the result of the community’s work over the past six months, including: retpoline Spectre variant 2 mitigation, significantly improved CodeView debug info for Windows, GlobalISel by default for AArch64 at -O0, improved scheduling on several x86 micro-architectures, Clang defaults to -std=gnu++14 instead of -std=gnu++98, support for some upcoming C++2a features, improved optimizations, new compiler warnings, many bug fixes, and more.