<div dir="auto"><div><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 9, 2018, 2:35 PM David Collier-Brown via talk <<a href="mailto:talk@gtalug.org">talk@gtalug.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div class="m_8637643109926521633moz-cite-prefix">For any instruction that can be
      executed during speculation, if it has an effect, it's arguably
      usable as a covert channel (;-))<br></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><span style="font-family:sans-serif">Welcome to a web world of "jittery" java. Hardening against accurate timers seems like an oxymoron to me. </span><span style="font-family:sans-serif">On second thought tho, it does all start with military intelligence, so it must be a natural evolution.</span></div><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div dir="auto"><font face="sans-serif">"Mozilla Foundation: The Mozilla Foundation likewise acknowledged the issue. They decided to refrain from using compiler-assisted defenses, as they would seemingly require complex changes to JIT-compiled and C++ code. Instead, they aim to remove all (fine-granular) timers from Firefox to destroy caching-based feedback channels. Furthermore, they referred to an upcoming Firefox release that includes time jittering features similar to those described in FuzzyFox [23], which further harden against accurate timers. </font></div><div dir="auto"><font face="sans-serif"><br></font></div><div dir="auto"><font face="sans-serif">Google: Google acknowledged the problem in principle also affects Chrome. Similar to Firefox, they do not aim to address the problem with compiler-assisted solutions. Instead, they also refer to inaccurate timers, but more importantly, focus on a stronger isolation between sites of different origins. Chrome’s so-called Site Isolation prevents attackers from reading across origins (e.g., sites of other domains). However, as discussed in Section 6.1, this does not mitigate the problem that attackers can break ASLR with our attack technique."</font><br></div><div dir="auto"><font face="sans-serif"><br></font></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div class="m_8637643109926521633moz-cite-prefix">
    </div>
    <div class="m_8637643109926521633moz-cite-prefix"><br>
    </div>
    <div class="m_8637643109926521633moz-cite-prefix">--dave</div>
    <div class="m_8637643109926521633moz-cite-prefix"><br>
    </div>
    <div class="m_8637643109926521633moz-cite-prefix"><br>
    </div>
    <div class="m_8637643109926521633moz-cite-prefix">On 2018-08-09 10:03 a.m., Russell
      Reiter via talk wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="auto">More Intel woes. 
        <div dir="auto"><br>
        </div>
        <div dir="auto"><a href="http://www.digitaljournal.com/tech-and-science/technology/new-security-flaw-with-intel-processors/article/529077" target="_blank" rel="noreferrer">http://www.digitaljournal.com/tech-and-science/technology/new-security-flaw-with-intel-processors/article/529077</a><br>
          <div dir="auto"><br>
          </div>
          <div dir="auto">Quote from the whitepaper link in the article.</div>
          <div dir="auto"><br>
          </div>
          <div dir="auto">3 GENERAL ATTACK OVERVIEW</div>
          <div dir="auto"><br>
          </div>
          <div dir="auto">Before detailing specific attack scenarios, in
            this section, we introduce the basics of how RSB-based
            speculative execution can be achieved and be abused. We
            explore whether and how attackers may manipulate the RSB
            entries in order to leak sensitive data using speculative
            execution that they could not access otherwise. Similar to
            recent microarchitectural attacks [8, 10, 22, 26, 29], we
            trick the CPU to execute instructions that would not have
            been executed in a sequential execution. The goal is to leak
            sensitive information in speculation, e.g., by caching a
            certain memory area that can be detected in a normal
            (non-speculative) execution. The general idea of our attack
            can be divided into three steps: </div>
          <div dir="auto"><br>
          </div>
          <div dir="auto">(A1) trigger misspeculations in the return
            address predictor, i.e., enforce that returns mispredict </div>
          <div dir="auto"><br>
          </div>
          <div dir="auto">(A2) divert the speculative execution to a
            known/controlled code sequence with the required context </div>
          <div dir="auto"><br>
          </div>
          <div dir="auto">(A3) modify the architectural state in
            speculation, such that it can be detected from outside </div>
          <div dir="auto"><br>
          </div>
          <div dir="auto">(A1) Triggering Misspeculation: From an
            attacker’s perspective, enforcing that the return predictor
            misspeculates upon function return is essential to reliably
            divert speculative execution to attacker-controlled code
            (see A2 for how to control the speculated code).
            Misspeculations can be achieved in several ways, depending
            on the RSBs underflow behavior (as discussed in Section
            2.3).<br>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="m_8637643109926521633mimeAttachmentHeader"></fieldset>
      <pre class="m_8637643109926521633moz-quote-pre">---
Talk Mailing List
<a class="m_8637643109926521633moz-txt-link-abbreviated" href="mailto:talk@gtalug.org" target="_blank" rel="noreferrer">talk@gtalug.org</a>
<a class="m_8637643109926521633moz-txt-link-freetext" href="https://gtalug.org/mailman/listinfo/talk" target="_blank" rel="noreferrer">https://gtalug.org/mailman/listinfo/talk</a>
</pre>
    </blockquote>
    <p><br>
    </p>
    <pre class="m_8637643109926521633moz-signature" cols="72">-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
<a class="m_8637643109926521633moz-txt-link-abbreviated" href="mailto:davecb@spamcop.net" target="_blank" rel="noreferrer">davecb@spamcop.net</a>           |                      -- Mark Twain
</pre>
  </div>

---<br>
Talk Mailing List<br>
<a href="mailto:talk@gtalug.org" target="_blank" rel="noreferrer">talk@gtalug.org</a><br>
<a href="https://gtalug.org/mailman/listinfo/talk" rel="noreferrer noreferrer" target="_blank">https://gtalug.org/mailman/listinfo/talk</a><br>
</blockquote></div></div></div>