Multics and the Sun T-series did it right: check the permissions before letting an action complete. Interestingly, the authors of the DPS8m simulator had to scratch their head a bit to make sure an intel chipset wouldn't subvert the emulator's checks (;-))

--dave


On 2018-08-09 3:49 p.m., Russell Reiter wrote:

On Thu, Aug 9, 2018, 2:35 PM David Collier-Brown via talk <talk@gtalug.org <mailto:talk@gtalug.org>> wrote:

    For any instruction that can be executed during speculation, if it
    has an effect, it's arguably usable as a covert channel (;-))



Welcome to a web world of "jittery" java. Hardening against accurate timers seems like an oxymoron to me. On second thought tho, it does all start with military intelligence, so it must be a natural evolution.

"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.

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."


    --dave


    On 2018-08-09 10:03 a.m., Russell Reiter via talk wrote:
    More Intel woes.

    
http://www.digitaljournal.com/tech-and-science/technology/new-security-flaw-with-intel-processors/article/529077

    Quote from the whitepaper link in the article.

    3 GENERAL ATTACK OVERVIEW

    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:

    (A1) trigger misspeculations in the return address predictor,
    i.e., enforce that returns mispredict

    (A2) divert the speculative execution to a known/controlled code
    sequence with the required context

    (A3) modify the architectural state in speculation, such that it
    can be detected from outside

    (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).

    ---
    Talk Mailing List
    talk@gtalug.org  <mailto:talk@gtalug.org>
    https://gtalug.org/mailman/listinfo/talk


-- David Collier-Brown, | Always do right. This will gratify
    System Programmer and Author | some people and astonish the rest
    dav...@spamcop.net  <mailto:dav...@spamcop.net>            |                
      -- Mark Twain

    ---
    Talk Mailing List
    talk@gtalug.org <mailto:talk@gtalug.org>
    https://gtalug.org/mailman/listinfo/talk


--
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dav...@spamcop.net           |                      -- Mark Twain

---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk

Reply via email to