5 ms·

A long two months: Reflecting on mitigating Meltdown

114 points by bcantrill 9y ago

userbinator 9y ago
segmentation is the closest feature really, and it was thrown out for 64-bit AMD64 That was one of the "big things" with the 286 and protected mode, and enhanced even further with the 386, so it's a bit ironic and sad that it can't be done in 64-bit mode --- and I'm sure it could be done in a backwards-compatible manner if AMD chose to (double-wide descriptors seem to be a reasonably popular thought), but it feels like a lot of the decisions made with AMD64 were more just to spite Intel than benefit anything or anyone else. Related: http://www.pagetable.com/?p=25 http://www.pagetable.com/?p=25
- dcow 9y ago
  It's not so insidious as you suggest (from your link): VMware chose not to support 64 bit virtualization until AMD reintroduced (optional) segment limits on later models of their Opteron and Athlon 64 CPUs. Intel never implemented 64 bit segment limits on their EM64T/Intel64 CPUs, because their 64 bit processors soon implemented VT/Vanderpool, which also worked around the problem. So this is why VMware requires a certain model and stepping of the AMD CPU line or a VT-enabled Intel CPU in order to support 64 bit virtualization. Intel was the one that dropped segment limits, AMD added them in later... It sounds more like advances in hardware virtualization yielded better solutions than a bunch of additional segment registers and slow context switches. It's only now that we realize without those you can trick a processor into fetching memory it shouldn't and that the only viable software solution has been to effectively implement separate page tables and enforce copying between their stack contexts at the user/kernel boundary anyway (so we're back where we started with slow context switches). In theory, you could mitigate specter by running every process in its own hardware virtualized address space, right? It's just much more complicated to do that because you'd need to move the kernel to the hypervisor ring or rewrite everything to communicate entirely using a shared physical resource like a network interface. If VT-x allowed shared memory regions with ownership restrictions (does it?) you wouldn't even need to do that.
  - bitwize 9y ago
    Every process already does run in its own virtualized address space, without VT-x. That's what virtual memory is and does. Spectre can cross process boundaries at points where processes have the same memory mapped into their private address space (to wit: shared libs). If you enable VT-x VMs to share chunks of memory, you'll have the same damn problem. (This may be what "Spectre type 2" is, I'm not sure).
    - dcow 9y ago
      I thought the issue was that under the same kernel all pages mapped into memory can be read because the processor does not perform the virtual memory checks for the speculatively executing code...which is why the fix involves unmapping pages on context switches. VT-x gives you "physical" isolation not virtual, I thought. Like two VT-x spaces don't share the same page table mappings, do they? I could be completely wrong.
      - bitwize 9y ago
        > I thought the issue was that under the same kernel all pages mapped into memory can be read because the processor does not perform the virtual memory checks for the speculatively executing code...which is why the fix involves unmapping pages on context switches. That's Meltdown. In Meltdown's case, the processor does not perform the check to see whether a mapped page is privileged, kernel memory (ring 0) or unprivileged, user space memory before speculatively executing it, and that's where the need to unmap kernel pages before leaving a syscall (and remap them before entering one) comes from. Spectre is confined to a single process's address space, so assuming no processes share code, an attacker would only be able to leak information from within the same process via Spectre. Which is enough a vulnerablility to warrant concern, as with precise enough timers you could exfiltrate information (passwords, etc.) from anywhere in a browser process via JavaScript. The problem is, processes share code all the time, via shared libs, which makes Spectre attacks able to cross process boundaries. VT-x is a hardware virtualization layer. It doesn't provide some sort of physical barrier to different contexts running on the same CPU wired to the same RAM leaking memory.

114 points by bcantrill 9y ago

segmentation is the closest feature really, and it was thrown out for 64-bit AMD64 That was one of the "big things" with the 286 and protected mode, and enhanced even further with the 386, so it's a bit ironic and sad that it can't be done in 64-bit mode --- and I'm sure it could be done in a backwards-compatible manner if AMD chose to (double-wide descriptors seem to be a reasonably popular thought), but it feels like a lot of the decisions made with AMD64 were more just to spite Intel than benefit anything or anyone else. Related: http://www.pagetable.com/?p=25 http://www.pagetable.com/?p=25

dcow 9y ago
It's not so insidious as you suggest (from your link): VMware chose not to support 64 bit virtualization until AMD reintroduced (optional) segment limits on later models of their Opteron and Athlon 64 CPUs. Intel never implemented 64 bit segment limits on their EM64T/Intel64 CPUs, because their 64 bit processors soon implemented VT/Vanderpool, which also worked around the problem. So this is why VMware requires a certain model and stepping of the AMD CPU line or a VT-enabled Intel CPU in order to support 64 bit virtualization. Intel was the one that dropped segment limits, AMD added them in later... It sounds more like advances in hardware virtualization yielded better solutions than a bunch of additional segment registers and slow context switches. It's only now that we realize without those you can trick a processor into fetching memory it shouldn't and that the only viable software solution has been to effectively implement separate page tables and enforce copying between their stack contexts at the user/kernel boundary anyway (so we're back where we started with slow context switches). In theory, you could mitigate specter by running every process in its own hardware virtualized address space, right? It's just much more complicated to do that because you'd need to move the kernel to the hypervisor ring or rewrite everything to communicate entirely using a shared physical resource like a network interface. If VT-x allowed shared memory regions with ownership restrictions (does it?) you wouldn't even need to do that.
- bitwize 9y ago
  Every process already does run in its own virtualized address space, without VT-x. That's what virtual memory is and does. Spectre can cross process boundaries at points where processes have the same memory mapped into their private address space (to wit: shared libs). If you enable VT-x VMs to share chunks of memory, you'll have the same damn problem. (This may be what "Spectre type 2" is, I'm not sure).
  - dcow 9y ago
    I thought the issue was that under the same kernel all pages mapped into memory can be read because the processor does not perform the virtual memory checks for the speculatively executing code...which is why the fix involves unmapping pages on context switches. VT-x gives you "physical" isolation not virtual, I thought. Like two VT-x spaces don't share the same page table mappings, do they? I could be completely wrong.
    - bitwize 9y ago
      > I thought the issue was that under the same kernel all pages mapped into memory can be read because the processor does not perform the virtual memory checks for the speculatively executing code...which is why the fix involves unmapping pages on context switches. That's Meltdown. In Meltdown's case, the processor does not perform the check to see whether a mapped page is privileged, kernel memory (ring 0) or unprivileged, user space memory before speculatively executing it, and that's where the need to unmap kernel pages before leaving a syscall (and remap them before entering one) comes from. Spectre is confined to a single process's address space, so assuming no processes share code, an attacker would only be able to leak information from within the same process via Spectre. Which is enough a vulnerablility to warrant concern, as with precise enough timers you could exfiltrate information (passwords, etc.) from anywhere in a browser process via JavaScript. The problem is, processes share code all the time, via shared libs, which makes Spectre attacks able to cross process boundaries. VT-x is a hardware virtualization layer. It doesn't provide some sort of physical barrier to different contexts running on the same CPU wired to the same RAM leaking memory.