> 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.
> 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.
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.
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.
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.
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.
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.
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?
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?
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.
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)
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.
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.
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".
[+] [-] richdougherty|8 years ago|reply
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.
[+] [-] jlebar|8 years ago|reply
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).
[+] [-] dzdt|8 years ago|reply
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/
[+] [-] microtonal|8 years ago|reply
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|reply
[+] [-] IshKebab|8 years ago|reply
[+] [-] kbenson|8 years ago|reply
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|reply
"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|reply
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?
[+] [-] foota|8 years ago|reply
[+] [-] motohagiography|8 years ago|reply
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|reply
[+] [-] microcolonel|8 years ago|reply
[0]: https://bugs.chromium.org/p/chromium/issues/detail?id=798964
[+] [-] beebmam|8 years ago|reply
[+] [-] ygra|8 years ago|reply
[+] [-] xtrapolate|8 years ago|reply
[+] [-] pdpi|8 years ago|reply
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.
[+] [-] Beltiras|8 years ago|reply
Scary times.