7 ms·
Spectre Mitigations in Microsoft's C/C++ Compiler
- kbenson 9y agoHere'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 9y agoThe 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 9y agoIt'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?
- foota 9y agoSpectre 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 9y agoI thought for Intel processors it leaked across all processes, including outside user-space. Or was that meltdown?
- ChrisSD 9y agoMeltdown allows information to leak across ring boundaries. Spectre by itself doesn't. Meltdown is relatively easy to fix whereas Spectre is a more fundamental issue with how most modern chips are designed.
- criddell 9y agoThat's my understanding as well. If you are writing a new Notepad.exe, you probably don't care about Spectre.
- beebmam 9y agoWhat an absolute disaster spectre has been, and what a shame it is that intel won't be punished for it
- ygra 9y agoAnd all other chipmakers? Unlike Meltdown Spectre applies to pretty much all modern processors.
- ChrisSD 9y agoExcept most low end chips (mostly ARM) are immune.
- ornitorrincos 9y agoarm chips are vulnerabe to spectre, and some even to meltdown: https://developer.arm.com/support/security-update https://developer.arm.com/support/security-update ans mips to spectre: https://www.mips.com/blog/mips-response-on-speculative-execution-and-side-channel-vulnerabilities/ https://www.mips.com/blog/mips-response-on-speculative-execu...
- pdpi 9y agoInsofar as they are immune, is it because of some sort of foresight and/or better engineering practices, or because the immune chips are simply cheaper, less sophisticated designs? Hint: The fact that ARM ranges from "completely immune" to "affected by the less-common Meltdown" gives away the answer.
- xtrapolate 9y agoPeople 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.
- pdpi 9y agoThe 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 9y agoI 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 https://bugs.chromium.org/p/chromium/issues/detail?id=798964
- richdougherty 9y 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-mitigations-in-msvc/ 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 9y agoYeah, 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-sunspider-benchmark/ 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 9y agoHi, 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 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 9y agoI 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.
- dzdt 9y agoI 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/ https://lwn.net/Articles/744287/
- IshKebab 9y agoYou 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.
- dzdt 9y agoSpectre 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+clearing+up+the+confusion/23197/ https://isc.sans.edu/forums/diary/Meltdown+and+Spectre+clear...
- bennofs 9y agoYou can only read memory that is mapped in the address space of vulnerable processes with Spectre. Usually, that is only memory from the current process and maybe a small bit of shared memory (and code segments of shared libraries, but those don't contain any interesting secrets). So while you can read memory from other processes, those processes need to be vulnerable and you cannot read memory from processes that applied mitigation.
- jjnoakes 9y agoIs this true? I'm no spectre expert but I thought that if you could detect cache changes correctly, you could infer the value of memory that you did not have mapped (but the other process did) as long as the other process changes its cache-touching behavior based on the value of the memory it had access to.
- motohagiography 9y agoBeen 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 9y agoNo. 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.