3 ms·

Every program can already read its entire address space. What you're probably trying to refer to is when a subroutine is hosted within a virtual machine, given

Every program can already read its entire address space. What you're probably trying to refer to is when a subroutine is hosted within a virtual machine, given a side channel the subroutine can read the address space of the VM host. This is an extremely niche scenario, basically it's just browsers. Most people don't accept arbitrary programs to execute in their address space.

titzer 5y ago
Memory-safe languages are the basis for language VMs' isolation of programs. Programs in those languages generally cannot read the entire address space, unless they have unsafe hooks. Micro-architectural side-channels bypass language security mechanisms altogether.
- staticassertion 5y ago
  You're just saying what I just said back to me, except with the confusing assertion about memory safe languages being the basis for language VMs isolation. I'm clearly missing something. edit: > Programs in those languages generally cannot read the entire address space, unless they have unsafe hooks. Also, this isn't true? Unless we're splitting hairs about semantics (ie: "read that exact address that isn't allocated yet). Lots of memory safe languages can allocate and compute arbitrarily, and there is no isolation of what subroutines can or can't read the memory of others. Anyway IDK what points you're trying to make, this all seems very specific to VMs, and this post is tackling other problems.
  - vlovich123 5y ago
    Maybe depends on your definition of VM? I think the way you phrased it, I read it as VM in the sense of host guest (eg QEMU, VMware, etc). Spectre and meltdown were broader. So in this case, if you loaded a script into your own process and executed in its own sandbox (eg Lua, JavaScript, Python, etc) that script could now access the containing process’ memory space whereas without spectre and Meltdown it couldn’t. Those attacks are still relevant and browser vendors are trying to be very careful here to not reintroduce gadgets that could be used to resurrect the attack. It’s also not just browsers. Notepad++ had to patch some things in its plugin system to protect against spectre/meltdown if I recall correctly. In fact, the original spectre and meltdown vulnerabilities impacted the kernel on the same machine so process A could read process B’s memory although to my knowledge that’s been largely mitigated. You do have the Rowhammer attacks and those have not been mitigated so all these attack vectors are still a concern.
    - staticassertion 5y ago
      I'm talking about any program that provides an execution environment for other, untrusted programs.
    - a1369209993 5y ago
      > In fact, the original spectre and meltdown vulnerabilities impacted the kernel on the same machine so process A could read process B's memory Not quite; process A could read kernel memory, but reading process B's memory requires a further security problem[0] such as the kernel having the entire physical memory space identity mapped (for Meltdown or for Spectre with gadgets) or the kernel running ('near' enough to speculate) specter-exploitable gadgets when context-switched to process B (for Spectre). 0: It argubly wasn't a vulnerability until Meltdown and Spectre entered the threat model, but it evidently should have been, since they in fact did.
  - titzer 5y ago
    > this post is tackling other problems. I know we are off-topic, I was replying to your comment to clarify some misconceptions. No, memory-safe languages do not let programs read the entire address space. Memory-safe languages include static (and dynamic) type safety measures so that a datum of type A cannot be treated as a datum of type B (if they are incompatible types). That means if different subroutines work on different types, they cannot read each others' data. That also implies that the heap has separable structure; your routine cannot get to my objects unless it has a type-safe access path to them. It cannot hunt through memory to find my crypto keys, e.g. Therefore, security measures can be designed into programs that use the type system. The OP is an example of one. > You're just saying what I just said back to me Well, no. > with the confusing assertion about memory safe languages being the basis for language VMs isolation. I'm clearly missing something. Sorry if that confused you, it might have been cryptic. If you read what I've written in this comment it will be more clear now. Language VMs separate programs from each other because they can enforce a type system. Separate types in separate programs means they cannot interfere.
    - staticassertion 5y ago
      Got it, yeah I think what you're saying now is a lot clearer to me, I definitely felt like I must have been totally missing something.
jhgb 5y ago
> Every program can already read its entire address space. Even on Harvard architecture machines?

titzer 5y ago

Memory-safe languages are the basis for language VMs' isolation of programs. Programs in those languages generally cannot read the entire address space, unless they have unsafe hooks. Micro-architectural side-channels bypass language security mechanisms altogether.

staticassertion 5y ago
You're just saying what I just said back to me, except with the confusing assertion about memory safe languages being the basis for language VMs isolation. I'm clearly missing something. edit: > Programs in those languages generally cannot read the entire address space, unless they have unsafe hooks. Also, this isn't true? Unless we're splitting hairs about semantics (ie: "read that exact address that isn't allocated yet). Lots of memory safe languages can allocate and compute arbitrarily, and there is no isolation of what subroutines can or can't read the memory of others. Anyway IDK what points you're trying to make, this all seems very specific to VMs, and this post is tackling other problems.
- vlovich123 5y ago
  Maybe depends on your definition of VM? I think the way you phrased it, I read it as VM in the sense of host guest (eg QEMU, VMware, etc). Spectre and meltdown were broader. So in this case, if you loaded a script into your own process and executed in its own sandbox (eg Lua, JavaScript, Python, etc) that script could now access the containing process’ memory space whereas without spectre and Meltdown it couldn’t. Those attacks are still relevant and browser vendors are trying to be very careful here to not reintroduce gadgets that could be used to resurrect the attack. It’s also not just browsers. Notepad++ had to patch some things in its plugin system to protect against spectre/meltdown if I recall correctly. In fact, the original spectre and meltdown vulnerabilities impacted the kernel on the same machine so process A could read process B’s memory although to my knowledge that’s been largely mitigated. You do have the Rowhammer attacks and those have not been mitigated so all these attack vectors are still a concern.
  - staticassertion 5y ago
    I'm talking about any program that provides an execution environment for other, untrusted programs.
  - a1369209993 5y ago
    > In fact, the original spectre and meltdown vulnerabilities impacted the kernel on the same machine so process A could read process B's memory Not quite; process A could read kernel memory, but reading process B's memory requires a further security problem[0] such as the kernel having the entire physical memory space identity mapped (for Meltdown or for Spectre with gadgets) or the kernel running ('near' enough to speculate) specter-exploitable gadgets when context-switched to process B (for Spectre). 0: It argubly wasn't a vulnerability until Meltdown and Spectre entered the threat model, but it evidently should have been, since they in fact did.
- titzer 5y ago
  > this post is tackling other problems. I know we are off-topic, I was replying to your comment to clarify some misconceptions. No, memory-safe languages do not let programs read the entire address space. Memory-safe languages include static (and dynamic) type safety measures so that a datum of type A cannot be treated as a datum of type B (if they are incompatible types). That means if different subroutines work on different types, they cannot read each others' data. That also implies that the heap has separable structure; your routine cannot get to my objects unless it has a type-safe access path to them. It cannot hunt through memory to find my crypto keys, e.g. Therefore, security measures can be designed into programs that use the type system. The OP is an example of one. > You're just saying what I just said back to me Well, no. > with the confusing assertion about memory safe languages being the basis for language VMs isolation. I'm clearly missing something. Sorry if that confused you, it might have been cryptic. If you read what I've written in this comment it will be more clear now. Language VMs separate programs from each other because they can enforce a type system. Separate types in separate programs means they cannot interfere.
  - staticassertion 5y ago
    Got it, yeah I think what you're saying now is a lot clearer to me, I definitely felt like I must have been totally missing something.

jhgb 5y ago

> Every program can already read its entire address space. Even on Harvard architecture machines?