6 ms·

The big news this year was that the majority of hardware isolation designs in existence were fundamentally unsound, this is a software sandbox. Are you referrin

• stcredzero 8y ago
  So is the idea to take a page from the RISC and VLSI playbooks and outsource the isolation and security to the compiler/JIT VM?
• gok 8y ago
  The big news this year was that you can't run code of different trust levels in the same address space.
  • infinite8s 8y ago
    Actually I think the big news is that you can't run them on the same CPU.
• geofft 8y ago
  As I understand it, there were basically two bug classes. One was that code that makes faulty fetches across a hardware privilege boundary can infer data from how long the fault takes. Another was that characteristics of branch prediction within the same process can reveal information about the branch path not taken, even if that branch is itself a bounds check or other security check. The first attack isn't relevant to designs that don't use hardware isolation, but the second one absolutely is. If your virtual bytecode (wasm, JVM, Lua, whatever) is allowed access to a portion of memory, and inside the same hardware address space is other memory it shouldn't read (e.g., because there are two software-isolated processes in the same hardware address space), and a supervisor or JIT is guarding its memory accesses with branches, the second attack will let the software-isolated process execute cache timing attacks against the data on the wrong side of the branch. (I believe the names are more-or-less that Meltdown is the first bug class and Spectre is the second, but the Spectre versions are rather different in characteristics - in particular I believe that Spectre v1 affects software-isolation-only systems and Spectre v2 less so. But the names confuse me.)
  • _wmd 8y ago
    For someone with only passing attention for this stuff, your comment explains it perfectly -- thanks! Now I'm wondering how browsers presumably already cope with this for JS, or how CloudFlare workers cope with it, or .. etc.
    • geofft 8y ago
      The immediate response from browsers was to disable shared memory across JavaScript contexts (previously you were allowed to create a SharedArrayBuffer and share it across WebWorkers, which if you're familiar with UNIX you should read as "mapping a shared memory segment in multiple processes" or "threads with shared memory") and to disable high-resolution timers, which makes it hard to get useful information out of timing attacks. I believe SharedArrayBuffer is coming back now-ish and I'm not totally sure what the mitigations are.
    • wolf550e 8y ago
      Browsers and cloudflare workers removed/neutered high resolution timers (and things from which you can build high resolution timers) to make exploitation difficult. CPU speculates past the bounds check and loads values you should not read into cache and you try to find out which value was loaded into cache using precise timing but the timer is imprecise so you don't know what the value was which you were not supposed to be able to read.
    • gok 8y ago
      Ultimately, code from each security origin is going to have to run in its own process space.
    • kllrnohj 8y ago
      The panic fix was to short term remove SharedArrayBuffer which was necessary to create a high precision timer. But the real fix is http://www.chromium.org/Home/chromium-security/site-isolation http://www.chromium.org/Home/chromium-security/site-isolatio... Browsers just resort to process sandboxing entirely. They assume JS can escape its sandbox, but since it can only read contents that were produced from its origin anyway it doesn't really matter.