4 ms·

That's great, but microarchitectural sidechannels in all modern hardware allow a program to read every byte in its entire address space.

by titzer 5y ago

mathetic 5y ago
Wouldn't that require the programmer to be adversarial? Since all type systems have escape hatches, I don't think they would be resilient at all in adversarial settings. This is more geared towards detecting accidental and _subtle_ data leakage.
andrew_ferr 5y ago
There is some research on preventing microarchitectural timing channels with information flow control as well. https://dl.acm.org/doi/10.1145/3243734.3243743 https://dl.acm.org/doi/10.1145/3243734.3243743
wyldfire 5y ago
That's a risk that should be independently assessed. This could mitigate accidental design decisions that would emit data that's not intended to be revealed. It would force designers to explicitly cast data as having been transformed to be safely emitted.
staticassertion 5y ago
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.
- jhgb 5y ago
  > Every program can already read its entire address space. Even on Harvard architecture machines?
gwbas1c 5y ago
You're confusing two different concepts. I once encountered a situation where a junior programmer just wrote the password to the log file. The point of using a separate type for secure data is to allow the compiler to try to trap situations where sensitive data is used incorrectly. (Yes, a dedicated moron could probably work around this kind of trap, but there is no such thing as a 100% perfect safety net.) Trying to prevent data leaks at the hardware level is a completely different problem with a completely different solution.

That's great, but microarchitectural sidechannels in all modern hardware allow a program to read every byte in its entire address space.

by titzer 5y ago

That's great, but microarchitectural sidechannels in all modern hardware allow a program to read every byte in its entire address space.

mathetic 5y ago

Wouldn't that require the programmer to be adversarial? Since all type systems have escape hatches, I don't think they would be resilient at all in adversarial settings. This is more geared towards detecting accidental and _subtle_ data leakage.

andrew_ferr 5y ago

There is some research on preventing microarchitectural timing channels with information flow control as well. https://dl.acm.org/doi/10.1145/3243734.3243743 https://dl.acm.org/doi/10.1145/3243734.3243743

wyldfire 5y ago

That's a risk that should be independently assessed. This could mitigate accidental design decisions that would emit data that's not intended to be revealed. It would force designers to explicitly cast data as having been transformed to be safely emitted.

staticassertion 5y ago

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.
jhgb 5y ago
> Every program can already read its entire address space. Even on Harvard architecture machines?

gwbas1c 5y ago

You're confusing two different concepts. I once encountered a situation where a junior programmer just wrote the password to the log file. The point of using a separate type for secure data is to allow the compiler to try to trap situations where sensitive data is used incorrectly. (Yes, a dedicated moron could probably work around this kind of trap, but there is no such thing as a 100% perfect safety net.) Trying to prevent data leaks at the hardware level is a completely different problem with a completely different solution.