<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 5, 2018 at 9:49 PM, Howard Chu <span dir="ltr"><<a href="mailto:hyc@symas.com" target="_blank">hyc@symas.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">Henry Baker wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So-called "two phase commit protocols" attempt to gather all the information and resources necessary to *complete* a transaction prior to "committing" the transaction.  If the transaction can't be completed, than it must need to be "rolled back" -- a process of *undoing* any actions that were done during the gathering phase.<br>
<br>
There's only one slight problem: you can't unring a bell: you can't "unlearn"/"forget" a bit that you learned during the gathering phase.  Or more precisely, you can't force a party to the transaction to forget such bits.<br>
<br>
I don't have a clean solution to this "forgetting" problem, and I doubt that anyone else does, either.<br>
</blockquote>
<br></span>
Eh. In the context of Spectre, the CPU knows which cachelines it loaded in a speculative fetch. It should simply mark them invalid when unrolling the speculation.<span class="gmail-HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>It might help to edit the subject of this thread to also include pipelining and cache.<br>Pipelines can be deep and look like speculation if a pipeline generated value is tested<br>and a branch kills the pipeline (same thing different things to google depending on the<br>schools and chronology of the hardware being discussed.<br><br>Cache can leak information via cache line associativity and aliasing.</div><div><a href="https://sudiptac.bitbucket.io/papers/chalice.pdf">https://sudiptac.bitbucket.io/papers/chalice.pdf</a><br><a href="https://cyber.wtf/2016/06/16/cache-side-channel-attacks-cpu-design-as-a-security-problem/">https://cyber.wtf/2016/06/16/cache-side-channel-attacks-cpu-design-as-a-security-problem/</a><br></div></div><a href="https://arxiv.org/pdf/1606.01356.pdf">https://arxiv.org/pdf/1606.01356.pdf</a><br><br>Understanding cache is critical for benchmarks if cache line aliasing</div><div class="gmail_extra">triggers cache timing changes.   Anytime benchmark values change<br>from mixed system loads it is obvious someone can see and open a side channel.</div><div class="gmail_extra">Some system calls for mutex in I/O can invalidate cache .  Most devices are not<br>cache coherent so they must trigger a flush behind the curtain.  <br>See also page attribute table (PAT).  </div><div class="gmail_extra"><br></div><div class="gmail_extra"><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">  T o m    M i t c h e l l</div></div>
</div></div>