The /Qspectre switch will be available in MSVC toolsets included in all future releases of Visual Studio (including Previews).
Please update to using /Qspectre as soon as you get a compiler that supports the switch as the /Qspectre switch will be maintained with new mitigations going forward.
You can use /d2guardspecload to apply the same mitigations to your code. What versions of MSVC support the /Qspectre switch?Īll versions of Visual Studio 2017 version 15.5 and all Previews of Visual Studio version 15.6 already include an undocumented switch, /d2guardspecload, that is currently equivalent to /Qspectre.
The MSVC team is evaluating the Microsoft Visual C++ Redistributables to make certain that any necessary mitigations are applied. Work is ongoing now to make the /Qspectre mitigation work on unoptimized code.
Similarly, inspect any code that uses #pragma optimize(, off). You should make sure to compile your code with any of the optimization switches (e.g., /O2 or /O1 but NOT /Od) to have the mitigation applied. In current versions of the MSVC compiler, the /Qspectre switch only works on optimized code. Standard sandboxing techniques may not be sufficient: you should investigate your sandboxing carefully before deciding that your code does not cross a trust boundary. Examples of code that operates on data that crosses a trust boundary include code that loads untrusted input that can affect execution such as remote procedure calls, parsing untrusted input for files, and other local inter-process communication (IPC) interfaces. If you are a developer whose code operates on data that crosses a trust boundary then you should consider downloading an updated version of the MSVC compiler, recompiling your code with the /Qspectre switch enabled, and redeploying your code to your customers as soon as possible. In this post, we’ll provide an overview of variant 1 and describe the steps that we’ve taken with the MSVC compiler to provide mitigation assistance. The mitigations for variant 2 and variant 3 are outside the scope of this post but are explained in Terry’s post. The following table from Terry’s blog provides the decoder ring for each of these variants:Įxploited Vulnerability CVE Exploit Name Public Vulnerability Name Spectre 2017-5753 Variant 1 Bounds Check Bypass Spectre 2017-5715 Variant 2 Branch Target Injection Meltdown 2017-5754 Variant 3 Rogue Data Cache Load The security researchers that discovered these vulnerabilities identified three variants that could enable speculative execution side-channel attacks. If you haven’t had a chance to read Terry’s post you should take a moment to read it before reading this one.
This post is intended as a follow-up to Terry Myerson’s recent Windows System post with a focus on the assessment for MSVC. On the MSVC team, we’ve reviewed information in detail and conducted extensive tests, which showed the performance impact of the new /Qspectre switch to be negligible. Microsoft is aware of a new publicly disclosed class of vulnerabilities, called “speculative execution side-channel attacks,” that affect many operating systems and modern processors, including processors from Intel, AMD, and ARM.