8 ms·

Sounds like the big idea from Singularity (run everything in the same hardware security ring, use static analysis for memory safety) is going mainstream, increm

by gok 8y ago

Sounds like the big idea from Singularity (run everything in the same hardware security ring, use static analysis for memory safety) is going mainstream, incrementally. Unfortunate that this is happening right as it becomes clear that such a design is fundamentally unsound on modern hardware.

yolo42 8y ago
There is another layer of abstraction that is heavily being exploited of running layers of kernels. I'm really interested in seeing more advances in this and unikernal approach where if you are running in the cloud, the hypervisor already provides you with a sandbox, so run things at a lower level than necessary. There are certain secuirty challenges that we see because we keep thinking in terms of user and kernal space. If we try to narrow (and slowly remove) the line separating the spaces, we can address these problems in more efficient way than done today for sure.
- bpye 8y ago
  gVisor is pretty interesting, it kinda takes this idea when you run it on KVM. https://github.com/google/gvisor https://github.com/google/gvisor
_wmd 8y ago
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 referring to the recent discovery of a new hardware bug class here?
- 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.
zimbatm 8y ago
+1 for pointing at the irony but it's not really true. 1. Hardware design flaws are not irremediable and will be fixed in time. 2. It's still very useful to run software that is trusted to not be malicious and/but not trusted to be void of memory bugs.
- wbl 8y ago
  Not without a big performance hit most servers don't need because they don't cross security domains.
  - monocasa 8y ago
    There's been remote Spectre exploits. https://lwn.net/Articles/761100/ https://lwn.net/Articles/761100/
- gok 8y ago
  Wasmjit doesn't really address #2. Memory bugs in nginx will continue to corrupt data and potentially allow RCE, they just will not be allowed to spread to the rest of the kernel (in theory)
  - johncolanduoni 8y ago
    If wasmjit is sound, it won’t allow general RCE. WASM enforces a significant level of control flow integrity; for the most part the worst you can do with an indirect branch is take advantage of type confusion to execute an unintended function. You cannot generate arbitrary code, or use something like return oriented programming to execute portions of existing functions.
- kllrnohj 8y ago
  > Hardware design flaws are not irremediable and will be fixed in time. There's no particular reason to believe this. Neither Intel nor AMD have committed to any form of side-effect-free speculative execution or similar. That'd required a rather large chunk of transistors and die space, and if nobody is footing the bill for it it's not going to happen. Preventing side-effects from leaking between processes (and ring levels) entirely at the hardware level is definitely going to happen. Within a process, though? That's not going to happen without multiple major players demanding it. Since nearly all the major CPU consumers are currently happy with process boundaries being the security enforcement zones, there's no particular reason to believe that in-process sandboxing will ever have hardware fixes to prevent spectre attacks.
twtw 8y ago
Except minus the static analysis, right?
- gok 8y ago
  WASM gets statically verified before it runs.
pjmlp 8y ago
Not only Singularity. Xerox Parc workstations, IBM and Unisys mainframes, UCSD Pascal, Oberon, Inferno, Java, .NET, Flash. Or for more actual examples, Garmin Apps, watchOS bitcode, DEX on Android.
- twtw 8y ago
  What IBM systems are you thinking of? System/360 had (and used) hardware privilege levels. Seems like few of your examples involve not using hardware for process isolation. Java: no, except a few research OSes. Flash: no.
  - monocasa 8y ago
    He's probably talking about AS/400, and it's hardware/software codesigned VM. For some reason people call those mainframes. AS/400 though does use hardware heavily in it's isolation model, going so far as to have a custom PowerPC variant currently that adds tagged memory.
    - pjmlp 8y ago
      Both AS/400 and System/370 have a so called language environments. And yes I call them mainframes, because it is as I always heard people referring to them during my Summer job back in the day, so the name stuck with me even it isn't correct.
      - monocasa 8y ago
        Language environment in IBM parlance is closer to "ABI" than "VM", or "sandbox" in the rest of the world. It's a common set of idioms to allow two languages (generally ASM and a higher level language like C) to call eachother and interoperate.
  - nickpsecurity 8y ago
    There's been quite a few of these systems over time. Especially sold commercially. IBM System/38, evolved into AS/400 and IBM i, is one of architectures described in this book: https://homes.cs.washington.edu/~levy/capabook/ https://homes.cs.washington.edu/~levy/capabook/ Far as language-based security, the first mainframe for businesses used a high-level language combined with a CPU that dynamically checked the programs. Still sold by Unisys but I doubt hardware checks still exist. http://www.smecc.org/The%20Architecture%20%20of%20the%20Burroughs%20B-5000.htm http://www.smecc.org/The%20Architecture%20%20of%20the%20Burr... The Flex Machine implemented capabilities and trusted procedures in the microcode: https://en.wikipedia.org/wiki/Flex_machine https://en.wikipedia.org/wiki/Flex_machine ASOS supported a mix of methods where each app was Ada for its safety features but a MLS kernel modeled in Gypsy separated various security levels: https://pdfs.semanticscholar.org/42a4/e6f812538c18461277c58a8464d2aa0c551f.pdf https://pdfs.semanticscholar.org/42a4/e6f812538c18461277c58a... SAFE explored tagging at CPU level which got commercialized as CoreGuard or Inherently Secure Processor: http://www.crash-safe.org/papers.html http://www.crash-safe.org/papers.html https://www.draper.com/explore-solutions/inherently-secure-processor https://www.draper.com/explore-solutions/inherently-secure-p... In embedded, there's Java processors that run bytecode natively with some support for separation. They blur the line between VM's and native apps: http://ajile.com/index.php?option=com_content&view=article&id=4&Itemid=5 http://ajile.com/index.php?option=com_content&view=article&i...

by gok 8y ago

yolo42 8y ago

There is another layer of abstraction that is heavily being exploited of running layers of kernels. I'm really interested in seeing more advances in this and unikernal approach where if you are running in the cloud, the hypervisor already provides you with a sandbox, so run things at a lower level than necessary. There are certain secuirty challenges that we see because we keep thinking in terms of user and kernal space. If we try to narrow (and slowly remove) the line separating the spaces, we can address these problems in more efficient way than done today for sure.

bpye 8y ago
gVisor is pretty interesting, it kinda takes this idea when you run it on KVM. https://github.com/google/gvisor https://github.com/google/gvisor

_wmd 8y ago

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 referring to the recent discovery of a new hardware bug class here?

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.

zimbatm 8y ago

+1 for pointing at the irony but it's not really true. 1. Hardware design flaws are not irremediable and will be fixed in time. 2. It's still very useful to run software that is trusted to not be malicious and/but not trusted to be void of memory bugs.

wbl 8y ago
Not without a big performance hit most servers don't need because they don't cross security domains.
- monocasa 8y ago
  There's been remote Spectre exploits. https://lwn.net/Articles/761100/ https://lwn.net/Articles/761100/
gok 8y ago
Wasmjit doesn't really address #2. Memory bugs in nginx will continue to corrupt data and potentially allow RCE, they just will not be allowed to spread to the rest of the kernel (in theory)
- johncolanduoni 8y ago
  If wasmjit is sound, it won’t allow general RCE. WASM enforces a significant level of control flow integrity; for the most part the worst you can do with an indirect branch is take advantage of type confusion to execute an unintended function. You cannot generate arbitrary code, or use something like return oriented programming to execute portions of existing functions.
kllrnohj 8y ago
> Hardware design flaws are not irremediable and will be fixed in time. There's no particular reason to believe this. Neither Intel nor AMD have committed to any form of side-effect-free speculative execution or similar. That'd required a rather large chunk of transistors and die space, and if nobody is footing the bill for it it's not going to happen. Preventing side-effects from leaking between processes (and ring levels) entirely at the hardware level is definitely going to happen. Within a process, though? That's not going to happen without multiple major players demanding it. Since nearly all the major CPU consumers are currently happy with process boundaries being the security enforcement zones, there's no particular reason to believe that in-process sandboxing will ever have hardware fixes to prevent spectre attacks.

twtw 8y ago

Except minus the static analysis, right?

gok 8y ago
WASM gets statically verified before it runs.

pjmlp 8y ago

Not only Singularity. Xerox Parc workstations, IBM and Unisys mainframes, UCSD Pascal, Oberon, Inferno, Java, .NET, Flash. Or for more actual examples, Garmin Apps, watchOS bitcode, DEX on Android.

twtw 8y ago
What IBM systems are you thinking of? System/360 had (and used) hardware privilege levels. Seems like few of your examples involve not using hardware for process isolation. Java: no, except a few research OSes. Flash: no.
- monocasa 8y ago
  He's probably talking about AS/400, and it's hardware/software codesigned VM. For some reason people call those mainframes. AS/400 though does use hardware heavily in it's isolation model, going so far as to have a custom PowerPC variant currently that adds tagged memory.
  - pjmlp 8y ago
    Both AS/400 and System/370 have a so called language environments. And yes I call them mainframes, because it is as I always heard people referring to them during my Summer job back in the day, so the name stuck with me even it isn't correct.
    - monocasa 8y ago
      Language environment in IBM parlance is closer to "ABI" than "VM", or "sandbox" in the rest of the world. It's a common set of idioms to allow two languages (generally ASM and a higher level language like C) to call eachother and interoperate.
- nickpsecurity 8y ago
  There's been quite a few of these systems over time. Especially sold commercially. IBM System/38, evolved into AS/400 and IBM i, is one of architectures described in this book: https://homes.cs.washington.edu/~levy/capabook/ https://homes.cs.washington.edu/~levy/capabook/ Far as language-based security, the first mainframe for businesses used a high-level language combined with a CPU that dynamically checked the programs. Still sold by Unisys but I doubt hardware checks still exist. http://www.smecc.org/The%20Architecture%20%20of%20the%20Burroughs%20B-5000.htm http://www.smecc.org/The%20Architecture%20%20of%20the%20Burr... The Flex Machine implemented capabilities and trusted procedures in the microcode: https://en.wikipedia.org/wiki/Flex_machine https://en.wikipedia.org/wiki/Flex_machine ASOS supported a mix of methods where each app was Ada for its safety features but a MLS kernel modeled in Gypsy separated various security levels: https://pdfs.semanticscholar.org/42a4/e6f812538c18461277c58a8464d2aa0c551f.pdf https://pdfs.semanticscholar.org/42a4/e6f812538c18461277c58a... SAFE explored tagging at CPU level which got commercialized as CoreGuard or Inherently Secure Processor: http://www.crash-safe.org/papers.html http://www.crash-safe.org/papers.html https://www.draper.com/explore-solutions/inherently-secure-processor https://www.draper.com/explore-solutions/inherently-secure-p... In embedded, there's Java processors that run bytecode natively with some support for separation. They blur the line between VM's and native apps: http://ajile.com/index.php?option=com_content&view=article&id=4&Itemid=5 http://ajile.com/index.php?option=com_content&view=article&i...