Glider from the game of Life, rising from the left




Topic: #mitigation

Microsoft C Compiler Fails to Obstruct Spectre


Last month, Microsoft announced an improvement in their compiler for Visual C and C++. It now blocks some variants of the Spectre attack by inserting LFENCE instructions to block speculative execution when it detects a pattern in the code it is compiling that is characteristic of Spectre attacks. In effect, the compiler is using the antivirus technique of looking for a "signature" of the attack and applying countermeasures when it finds one.

This approach has two main limitations. Firstly, blacklisting known attacks instead of whitelisting code patterns that are known to be safe, doesn't address the vulnerability in full generality, since an unanticipated variant of the attack that has a slightly different signature can still succeed. Secondly, it complicates debugging and maintenance, since it is much more difficult to identify, by manual inspection, cases in which the countermeasures should have been applied but weren't than to find (operationally) cases in which the countermeasures were applied even though they weren't needed.

Microsoft chose the signature-blacklisting approach because it entails less of a performance penalty: Programs compiled with the new compiler run almost as fast as the vulnerable versions produced by the old compiler. If it had been designed to insert LFENCE instructions whenever it could not prove that the code being compiled was safe without them, the performance hit would have been much, much larger.

“Spectre Mitigations in Microsoft's C/C++ Compiler”
Paul Kocher, February 13, 2018

The author of this article created a rough benchmark to determine how much protection the signature-blacklisting approach actually provides. He took the proof-of-concept C program provided by the team that devised the Spectre attack in the first place and developed fourteen variations of the key function. Most of the variations were easy and straightforward, not to say trivial.

Microsoft's new C compiler correctly inserted LFENCE instructions in the original proof-of-concept code and in one of the variants (in which the key instruction was replaced with a call to a function that executed the instruction and the function was then inlined). The new C compiler generated unsafe code for the other thirteen variants.

#microsoft #spectre #mitigation

Mitigations Have Consequences


Early attempts to patch operating systems and processor microcode in order to block Meltdown attacks and impede some known instances of the Spectre strategy have had adverse results (beyond slower performance, which was anticipated): incompatibility with some third-party anti-virus utilities, driver crashes, bricking of some AMD systems, and processor crashes on Intel systems that still use the Haswell and Broadwell designs.

Meanwhile, researchers are making progress in turning the proof-of-concept implementations described in the original papers on Meltdown and Spectre into practical attacks.

“Spectre and Meltdown Patches Causing Trouble As Realistic Attacks Get Closer”
Peter Bright, Ars Technica, January 15, 2018

This is all a mess. Some companies, such as cloud service providers, have no real option but to install all the updates, including the microcode updates, because their vulnerability is so great; their business is running untrusted third-party code. For the rest of us, there is urgency, but that needs to be balanced against reliability.

That urgency is growing each day, however, particularly when it comes to the Meltdown attack.

#meltdown #spectre #mitigation

Hashtag index

This work is licensed under a Creative Commons Attribution-ShareAlike License.

Atom feed

John David Stone (

created June 1, 2014 · last revised December 10, 2018