<story><title>LLVM patch to fix half of Spectre attack</title><url>https://reviews.llvm.org/D41723</url></story><parent_chain><item><author>rayiner</author><text>Is glorious the right word for it? We’re going back to the stone ages where processors couldn’t predict the targets of indirect jumps. More generally, this seems to me like an attempt to patch out of what is really a class of attacks leveraging fundamental assumptions about high-performance CPU design. Before, OOO just had to preserve correctness and (some of) the order of exceptions and memory operations. Now, it has to preserve (some of) the timing of in-order execution too? Where does this path end?</text></item><item><author>tptacek</author><text>Page was down when I tried to read it, but it&amp;#x27;s archived here: &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;archive.is&amp;#x2F;s831k&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;archive.is&amp;#x2F;s831k&lt;/a&gt;.&lt;p&gt;Its hard to get your head around how big a deal this is. This vulnerability is so bad they killed x86 indirect jump instructions. It&amp;#x27;s so bad compilers --- all of them --- have to know about this bug, and use an incantation that hacks ret like an exploit developer would. It&amp;#x27;s so bad that to restore the original performance of a predictable indirect jump you might have to change the way you write high-level language code.&lt;p&gt;It&amp;#x27;s glorious.</text></item></parent_chain><comment><author>simias</author><text>Legitimate question: on any non-shared non-virtualized system is there any reason to enable these workarounds &lt;i&gt;besides&lt;/i&gt; running sandboxed applications such as javascript in a web browser (or flash&amp;#x2F;java applets&amp;#x2F;Active X, but those are not really super popular nowadays)?&lt;p&gt;For any other non-sanboxed application you pretty much have to trust the code anyway. Privilege escalation is always a bad thing of course, but for single user desktop machines getting user shell access as an attacker means that you can do pretty much anything you want.&lt;p&gt;As far as I can see the only surface of attack for my current machine would be a website running untrusted JS. For all other applications running on my machine if one of them is actually hostile them I&amp;#x27;m already screwed.&lt;p&gt;Frankly I&amp;#x27;m more annoyed at the ridiculous over-engineering of the Web than at CPU vendors. Because in 2017 you need to enable a turing complete language interpreter in your browser in order to display text and pictures on many (most?) websites.&lt;p&gt;Gopher should&amp;#x27;ve won.</text></comment>
<story><title>LLVM patch to fix half of Spectre attack</title><url>https://reviews.llvm.org/D41723</url></story><parent_chain><item><author>rayiner</author><text>Is glorious the right word for it? We’re going back to the stone ages where processors couldn’t predict the targets of indirect jumps. More generally, this seems to me like an attempt to patch out of what is really a class of attacks leveraging fundamental assumptions about high-performance CPU design. Before, OOO just had to preserve correctness and (some of) the order of exceptions and memory operations. Now, it has to preserve (some of) the timing of in-order execution too? Where does this path end?</text></item><item><author>tptacek</author><text>Page was down when I tried to read it, but it&amp;#x27;s archived here: &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;archive.is&amp;#x2F;s831k&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;archive.is&amp;#x2F;s831k&lt;/a&gt;.&lt;p&gt;Its hard to get your head around how big a deal this is. This vulnerability is so bad they killed x86 indirect jump instructions. It&amp;#x27;s so bad compilers --- all of them --- have to know about this bug, and use an incantation that hacks ret like an exploit developer would. It&amp;#x27;s so bad that to restore the original performance of a predictable indirect jump you might have to change the way you write high-level language code.&lt;p&gt;It&amp;#x27;s glorious.</text></item></parent_chain><comment><author>catnaroek</author><text>&amp;gt; Where does this path end?&lt;p&gt;It ends with the performance advantages of OOO execution being effectively negated by the workarounds to address the security issues it causes.&lt;p&gt;The following parable is edifying: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.cs.utexas.edu&amp;#x2F;users&amp;#x2F;EWD&amp;#x2F;transcriptions&amp;#x2F;EWD05xx&amp;#x2F;EWD594.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.cs.utexas.edu&amp;#x2F;users&amp;#x2F;EWD&amp;#x2F;transcriptions&amp;#x2F;EWD05xx&amp;#x2F;E...&lt;/a&gt;</text></comment>