<div dir="ltr"><div>There's a difference between control flow speculation and data flow. <br></div><div>By entangling the control flow & data, the cpu should stall the memory load until the condition is known, since the pointer value also isn't known.</div><div><br></div><div>I assume that actual experts (not me) tested this, and / or asked intel if this was sufficient to prevent the speculative memory load, given how speculation is actually implemented.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 17 Sep 2019 at 02:04, Praveen Velliengiri via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi all,</div><div><br></div><div>I understand how the speculative information flow attack works. I'm trying get my head around the spectre v1 mitigation of LLVM.</div><div>In the design document here : <a href="https://llvm.org/docs/SpeculativeLoadHardening.html#speculative-load-hardening" target="_blank">https://llvm.org/docs/SpeculativeLoadHardening.html#speculative-load-hardening.</a></div><div><br></div><div>Example: <br></div><div><pre><span class="gmail-m_7769756769736594767gmail-n">void</span> <span class="gmail-m_7769756769736594767gmail-n">leak</span><span class="gmail-m_7769756769736594767gmail-p">(</span><span class="gmail-m_7769756769736594767gmail-nb">int</span> <span class="gmail-m_7769756769736594767gmail-n">data</span><span class="gmail-m_7769756769736594767gmail-p">);</span>
<span class="gmail-m_7769756769736594767gmail-n">void</span> <span class="gmail-m_7769756769736594767gmail-n">example</span><span class="gmail-m_7769756769736594767gmail-p">(</span><span class="gmail-m_7769756769736594767gmail-nb">int</span><span class="gmail-m_7769756769736594767gmail-o">*</span> <span class="gmail-m_7769756769736594767gmail-n">pointer1</span><span class="gmail-m_7769756769736594767gmail-p">,</span> <span class="gmail-m_7769756769736594767gmail-nb">int</span><span class="gmail-m_7769756769736594767gmail-o">*</span> <span class="gmail-m_7769756769736594767gmail-n">pointer2</span><span class="gmail-m_7769756769736594767gmail-p">)</span> <span class="gmail-m_7769756769736594767gmail-p">{</span>
  <span class="gmail-m_7769756769736594767gmail-k">if</span> <span class="gmail-m_7769756769736594767gmail-p">(</span><span class="gmail-m_7769756769736594767gmail-n">condition</span><span class="gmail-m_7769756769736594767gmail-p">)</span><span class="gmail-m_7769756769736594767gmail-p"></span><span class="gmail-m_7769756769736594767gmail-o"></span><span class="gmail-m_7769756769736594767gmail-o"></span><span class="gmail-m_7769756769736594767gmail-n"></span><span class="gmail-m_7769756769736594767gmail-n"></span><span class="gmail-m_7769756769736594767gmail-n"></span><span class="gmail-m_7769756769736594767gmail-o"></span>
    <span class="gmail-m_7769756769736594767gmail-n">leak</span><span class="gmail-m_7769756769736594767gmail-p">(</span><span class="gmail-m_7769756769736594767gmail-o">*</span><span class="gmail-m_7769756769736594767gmail-n">pointer1</span><span class="gmail-m_7769756769736594767gmail-p">);</span>
 <span class="gmail-m_7769756769736594767gmail-p"></span> <span class="gmail-m_7769756769736594767gmail-k">else</span><span class="gmail-m_7769756769736594767gmail-p"></span><span class="gmail-m_7769756769736594767gmail-o"></span><span class="gmail-m_7769756769736594767gmail-o"></span><span class="gmail-m_7769756769736594767gmail-n"></span><span class="gmail-m_7769756769736594767gmail-n"></span><span class="gmail-m_7769756769736594767gmail-o"></span>
    <span class="gmail-m_7769756769736594767gmail-n">leak</span><span class="gmail-m_7769756769736594767gmail-p">(</span><span class="gmail-m_7769756769736594767gmail-o">*</span><span class="gmail-m_7769756769736594767gmail-n">pointer2</span><span class="gmail-m_7769756769736594767gmail-p">);</span><span class="gmail-m_7769756769736594767gmail-p"></span>
<span class="gmail-m_7769756769736594767gmail-p">}<br></span></pre><pre><span class="gmail-m_7769756769736594767gmail-p">After the applying the mitigation the code resembles like:<br><br>void leak(int data);<br>void example(int* pointer1, int* pointer2) {
  uintptr_t predicate_state = all_ones_mask;
  if (condition) {
    predicate_state = !condition ? all_zeros_mask : predicate_state;
    pointer1 &= predicate_state;
    leak(*pointer1);
  } else {
    int value2 = *pointer2 & predicate_state;
    leak(value2);
  }
}<br></span></pre><pre><span class="gmail-m_7769756769736594767gmail-p"><span style="font-family:arial,sans-serif">Let's assume that the branch is mispredicted and if body is taken. The value predicate_state mask is depend on the "result of the condition" but which is not yet available </span>hence<font face="arial,sans-serif"> <br></font></span></pre><pre><span class="gmail-m_7769756769736594767gmail-p"><font face="arial,sans-serif">speculative execution. My question whether the value of predicate_state is also guessed by the processor? If it is correct, then the value of predicate_state will be <br>predicate_state, if the processor mis-predicts the condition as true. Is my assumption is correct? i.e predicate_state = ! 1 ? all_zeros_mask : predicate_state, where processor predicts <br>condition as true. <br><br>Or Whether the execution stalls at "predicate_state = !condition ? all_zeros_mask : predicate_state until the result of condition became available? If this is true, why we have to <br></font></span></pre><pre><span class="gmail-m_7769756769736594767gmail-p"><font face="arial,sans-serif">harden the pointers in the first place, because after the condition is actually computed, the processors will revert back right the execution trace of mis-prediction. <br><br></font></span></pre><pre><span class="gmail-m_7769756769736594767gmail-p"><font face="arial,sans-serif">I know that I'm missing something fundamental here, I would highly appreciate your help on this? Please let me know if you more info!<br><br></font></span></pre><pre><span class="gmail-m_7769756769736594767gmail-p"><font face="arial,sans-serif">Cheeers,<br></font></span></pre><pre><span class="gmail-m_7769756769736594767gmail-p"><font face="arial,sans-serif">Praveen<br></font></span></pre><pre><span class="gmail-m_7769756769736594767gmail-p"><font face="arial,sans-serif"><br></font></span></pre></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>