<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>apendleton</author><text>My understanding:&lt;p&gt;Because it may not be known whether or not the read will have ended up being prohibited at the time it&amp;#x27;s speculatively executed. Think of a simple for loop over the contents of an array: usually at the end of each loop iteration you jump back to the beginning of the loop, until the last time you don&amp;#x27;t, when i &amp;gt; array.length or whatever. The branch predictor will likely predict that the last time you&amp;#x27;ll jump back again (you always have before, and it doesn&amp;#x27;t know the actual value of array.length yet since that takes hundreds of cycles to come back from memory) and try to speculatively execute the contents of the loop body on what turns out to be out-of-bounds data. That&amp;#x27;s not typically malicious; it&amp;#x27;s at the end of pretty much every iteration over an array ever.&lt;p&gt;So then, if we can reliably get our loop to operate on a bit of data that might turn out to be out of bounds, the trick is then to have a loop body like this:&lt;p&gt;if (potentially_illegal_bit == 1) {
    load_legal_location_1()
} else {
    load_legal_location_2()
}&lt;p&gt;After the branch misprediction occurs, the state of the program gets rolled back so we don&amp;#x27;t know what potentially_illegal_bit itself was anymore, but we don&amp;#x27;t have to, we can surmise it from the cache contents. The program isn&amp;#x27;t going to do an illegal read, it&amp;#x27;s going to do a legal one, to either legal location 1 or legal location 2, and see which is faster (as only one of them should be cached). Both reads are legal and will succeed, so the only difference is the speed. We&amp;#x27;ve now exfiltrated one bit of data from outside of your array bounds, but the only actually illegal read was speculative, which, as far as the CPU is concerned, is par for the course (predictions are wrong all the time), so no harm, no foul.</text><parent_chain><item><author>Pxtl</author><text>Okay, one thing I don&amp;#x27;t get: Fundamentally, the Meltdown problem comes from a process getting to inspect the wreckage after the the CPU &lt;i&gt;tried&lt;/i&gt; to clean up access of protected memory, but failed to properly account for a fun trick of caching.&lt;p&gt;That is, the process tried to read some data from protected memory A and did some fancy stuff with it such that left enough breadcrumbs that after the CPU responds to the illegal read, the process still has enough info to piece together what was in A, at least from timing of reads, right?&lt;p&gt;Why not kill the process instantly on a prohibited read, then?  Do these prohibited reads happen too often to switch from &amp;quot;oh, that&amp;#x27;s okay, you can try again and do other stuff&amp;quot; to &amp;quot;the punishment is death&amp;quot;?</text></item></parent_chain></comment><story><title>How a researcher hacked his own computer and found &apos;worst&apos; chip flaw</title><url>https://www.reuters.com/article/us-cyber-intel-researcher/how-a-researcher-hacked-his-own-computer-and-found-worst-chip-flaw-idUSKBN1ET1ZR</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>conradev</author><text>Speculative execution executes code that might not actually run. The following example could access protected memory even if `has_privileges` is false (i.e. the processor predicts it might be true):&lt;p&gt;&lt;pre&gt;&lt;code&gt;    if (has_privileges) {
        &amp;#x2F;&amp;#x2F; Access protected memory
    } else {
        &amp;#x2F;&amp;#x2F; Do something else
    }&lt;/code&gt;&lt;/pre&gt;</text><parent_chain><item><author>Pxtl</author><text>Okay, one thing I don&amp;#x27;t get: Fundamentally, the Meltdown problem comes from a process getting to inspect the wreckage after the the CPU &lt;i&gt;tried&lt;/i&gt; to clean up access of protected memory, but failed to properly account for a fun trick of caching.&lt;p&gt;That is, the process tried to read some data from protected memory A and did some fancy stuff with it such that left enough breadcrumbs that after the CPU responds to the illegal read, the process still has enough info to piece together what was in A, at least from timing of reads, right?&lt;p&gt;Why not kill the process instantly on a prohibited read, then?  Do these prohibited reads happen too often to switch from &amp;quot;oh, that&amp;#x27;s okay, you can try again and do other stuff&amp;quot; to &amp;quot;the punishment is death&amp;quot;?</text></item></parent_chain></comment><story><title>How a researcher hacked his own computer and found &apos;worst&apos; chip flaw</title><url>https://www.reuters.com/article/us-cyber-intel-researcher/how-a-researcher-hacked-his-own-computer-and-found-worst-chip-flaw-idUSKBN1ET1ZR</url></story>