Spectre Mitigations in Microsoft's C/C++ Compiler

https://www.paulkocher.com/doc/MicrosoftCompilerSpectreMitigation.html

by ENOTTY • 8 years ago

163 40 8 years ago

kbenson• 8 years ago

Here's the big takeaway.

At first, I thought I had the wrong version of the compiler, since I wasn't seeing any LFENCEs. Finally, I tried compiling my example code from the Appendix of the Spectre paper, and saw LFENCEs appearing. Still, even small variations in the source code resulted in unprotected code being emitted, with no warning to developers.

Theres some explanation for why this is the case, but it's not looking all that good for Microsoft's implementation, IMO.

zkomp• 8 years ago

The actual conclusion is fairly clear also "Developers and users cannot rely on Microsoft's current compiler mitigation to protect against the conditional branch variant of Spectre."

"Speculation barriers are only an effective defense if they are applied to all vulnerable code patterns in a process" Which they are not, since that would be a huge performance hit.

brianpgordon• 8 years ago

It's important that no exploitable paths get missed. An attacker needs only a single vulnerable code pattern, which can be anywhere in a process's address space (including libraries and other code that have nothing to do with security).

Hmm, I don't understand this statement. My (simplistic) understanding of this attack is that speculative execution produces detectable side-effects that result in memory being leaked from another address space that the attacker isn't supposed to be able to read. Surely if Spectre is used to leak the contents of something useless then that's not going to help the attacker compromise the application. Spectre is read-only, right? Am I missing something?

foota2• 8 years ago

Spectre can be used to leak arbitrary memory from a process iirc. So, if you have a process with nothing interesting it should be fine.

josteink• 8 years ago

I thought for Intel processors it leaked across all processes, including outside user-space.

Or was that meltdown?

criddell2• 8 years ago

That's my understanding as well. If you are writing a new Notepad.exe, you probably don't care about Spectre.

beebmam• 8 years ago

What an absolute disaster spectre has been, and what a shame it is that intel won't be punished for it

ygra• 8 years ago

And all other chipmakers? Unlike Meltdown Spectre applies to pretty much all modern processors.

ChrisSD2• 8 years ago

Except most low end chips (mostly ARM) are immune.

xtrapolate• 8 years ago

People make mistakes, "punishment" isn't the way forward here. There are alternatives out there to Intel, but kindly remember that other chip makers also released hardware that is susceptible. Also, you can trust this won't be the last time issues such as this come up.

pdpi2• 8 years ago

The only thing Intel deserves to be punished for here is their "nothing to see, move along" posture.

At the technical level, these are subtle bugs that affect most of the industry (with the Meltdown bug affecting a more restricted set of chips). It's a mess we'll be paying for for years to come, but not one that Intel is especially culpable for.

microcolonel• 8 years ago

I can't actually see it, but I believe this ticket[0] in the Chromium bugtracker is for Spectre mitigations (in V8). If you search in the V8 commit log for BUG=chromium:798964, you'll find a number of commits affecting most of the backends (and if you're really looking, you'll also see related or similar commits which are no longer tagged with the bug number, later in the log)

[0] https://bugs.chromium.org/p/chromium/issues/detail?id=798964

richdougherty• 8 years ago

I've been in touch with the Microsoft compiler team ... Given the limitations of static analysis and messiness of the available Spectre mitigations, they are struggling to do what they can without significantly impacting performance. They would welcome feedback – should /Qspectre (or a different option) automatically inserts LFENCEs in all potentially non-safe code patterns, rather than the current approach of protecting known-vulnerable patterns?

The fact that this isn't a full mitigation is mentioned in the original post from Microsoft, but it's more of a footnote. I think it would be better if it was spelled out more clearly so people don't think they're safe when they're not.

From https://blogs.msdn.microsoft.com/vcblog/2018/01/15/spectre-m...

It is important to note that there are limits to the analysis that MSVC and compilers in general can perform when attempting to identify instances of variant 1. As such, there is no guarantee that all possible instances of variant 1 will be instrumented under /Qspectre.

jlebar3• 8 years ago

Yeah, even this footnote really oversells it imo. I have trouble imagining a person who would want the level of (non) protection delivered by this flag.

Kind of reminds me of https://digitizor.com/internet-explorer-9-caught-cheating-in... (sorry for the non-primary source, the original blog post has since been taken down).

apardoe-MSFT• 8 years ago

Hi, I'm the guy who wrote the original VCBlog post. I would assert that we've been consistent in our messaging: there is not an automatic fix available for Spectre. The /Qspectre switch offers help in mitigation. It doesn't offer, nor does it claim to offer, complete protection.

We--as an industry--are learning as we go with Spectre. There's a lot of data that went into the decision to release this switch with its current implementation. And this isn't the last iteration: note in Paul Kocher's writeup that we've asked for feedback as to whether anyone would use a switch that was sound (for known variants) but incurred very large performance regressions.

As evidence that this is an industry-wide issue, I ask that you reread Paul Kocher's post. Also, see Chandler Carruth's tweet this morning about this topic: https://twitter.com/chandlerc1024/status/963995521705627648. Chandler is the guy driving Spectre in LLVM.

Lastly, understand that Microsoft has a lot of customers who rely on our technologies. For their benefit it's often better to say less than to say more, especially when talking about security vulnerabilities.

Beltiras• 8 years ago

I think the big thing here that is unspoken is that the Windows operating systems are compiled with that compiler. MS devs make tradeoffs for performance and their statement that no significant performance degradation is present in updated Win10 should be taken as: "We are delivering vulnerable operating systems because otherwise it would be unacceptably slow".

Scary times.

dzdt2• 8 years ago

I wonder why they aren't using the approach others are taking.

That is, compile an array access a[i] into an array of size N as a[i&M] where M is one less than the next power of two larger than N.

The logical and is very fast; it can be applied everywhere without a big performance hit. And this removes almost all the attack surface, as the real vulnerability is when the attacker forces speculative access to go way outside the array to unrelated memory that probably even belongs to another process.

Edit: actually there is an even better masking approach the linux kernel is using -- see https://lwn.net/Articles/744287/

IshKebab• 8 years ago

You can't read other process's memory with Spectre. And your solution would only work for statically sized arrays. In that case though it seems like a reasonable thing to do. Not a full solution though.

dzdt2• 8 years ago

Spectre can read from other processes! Meltdown can even read across privilege levels (userland to kernel). But within userland, spectre lets you read anything. See: https://isc.sans.edu/forums/diary/Meltdown+and+Spectre+clear...

microtonal• 8 years ago

That is, compile an array access a[i] into an array of size N as a[i&M] where M is one less than the next power of two larger than N.

Doesn't that still permit speculatively getting an out-of-bound element, where the problem gets worse with larger arrays?

The following LWN article describes a more sophisticated masking approach by Alexei Starovoitov:

https://lwn.net/Articles/744287/

Of course, the same question still applies: why not use this cheaper masking approach. Are there known problems with it?

amelius• 8 years ago

I don't think the compiler always knows N. This would then be something the programmer (and/or a library implementer) should provide.

motohagiography• 8 years ago

Been looking for an answer to a related question on this.

DRM technologies like "white box crypto," seem to be designed for the same use case. Is encoding sensitive operations in an application using these techs not a viable medium term mitigation as well?

tptacek• 8 years ago

No. White-box and obfuscated encryption cores are extremely slow, can't protect program logic (unless you encrypt the program and run it as a VM, which is even slower), and are themselves failure-prone. They work in DRM because DRM is an economic defense intended mostly to protect the new-release window for a title and to impose greater costs on copiers than a title is worth. They're not general-purpose countermeasures.

Spectre Mitigations in Microsoft's C/C++ Compiler

Related Stories