4 ms·

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 la

by 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.
    - mgerdts 9y ago
      > The problem is, processes share code all the time, via shared libs, which makes Spectre attacks able to cross process boundaries. I don't think that is how it works. Just because multiple processes map the same code (read-only) doesn't mean that they also have mappings to each others' data. If two processes shared mappings to the same data (e.g. after a fork() with no exec()) then what you say may be true. Just because I can write a program that uses libc doesn't mean that I can use that as a means to extract ssh keys from an ssh-agent that also is using libc.
      - bitwize 9y ago
        Actually, it does. By warming up the branch-target buffer to call a particular function (called a "gadget") inside libc as the attacker, you can induce the victim process to speculatively execute that function, and thereby leak data. It's a bit more complicated and involved than Meltdown, or Spectre within the same process, but it is possible and depending on the gadget chosen, any data within the victim process could be recovered.
nickpsecurity 9y ago
"t sounds more like advances in hardware virtualization yielded better solutions than a bunch of additional segment registers and slow context switches." The most secure OS's of the past used both paging and segments but for different things. Later on, the numbers I saw on Atom put segments at twice as fast as paging which matters given too much overhead makes people use mechanisms less. Finally, both Native Client and Code Pointer Integrity used segments for app-level protection which could run in VM's isolated by other mechanisms. So, they still have value given simplicity, efficiency, and fine granularity. I didnt like seeing them go given new developments were happening on segment-based designs.
kijiki 9y ago
> Intel was the one that dropped segment limits, AMD added them in later... I was there (at VMware). That isn't quite what happened. We got an early engineering prototype of the AMD64 chip. Ran at like 400Mhz or something, and was in an impressively massive case. It caused two big problems for us: 1) as you note, it disabled segment offsets on all segment registers except %FS and %GS, which are commonly used for thread local storage. And much worse for us, it disabled segment limit checking entirely, which we used to protect the virtual machine monitor (VMM) in the guest's virtual address space. 2) it disabled LAHF and SAHF instructions, which cause a pretty noticeable performance regression in the binary translator (BT). AMD was pretty helpful when we notified them, and Rev D and later of their chip had a special "VMware bit" that re-enabled segment limit checking and LAHF/SAHF. Intel was less helpful, and told us to just wait for Vanderpool (later renamed VT-X). Early versions of Vanderpool were actually slower than the traditional BT VMM. And annoyingly, for years VT-X didn't support real-mode or big-real-mode, so we had to keep emulation/BT around for that, which is really only used for the first half-second of bootup. AMD's Pacifica got this right from the start. Ole and some of the other early monitor hackers wrote a paper that covers some of this history if you want the gory details: https://www.ece.cmu.edu/~ece845/docs/vmware-evolution.pdf https://www.ece.cmu.edu/~ece845/docs/vmware-evolution.pdf

by dcow 9y ago

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.
  - mgerdts 9y ago
    > The problem is, processes share code all the time, via shared libs, which makes Spectre attacks able to cross process boundaries. I don't think that is how it works. Just because multiple processes map the same code (read-only) doesn't mean that they also have mappings to each others' data. If two processes shared mappings to the same data (e.g. after a fork() with no exec()) then what you say may be true. Just because I can write a program that uses libc doesn't mean that I can use that as a means to extract ssh keys from an ssh-agent that also is using libc.
    - bitwize 9y ago
      Actually, it does. By warming up the branch-target buffer to call a particular function (called a "gadget") inside libc as the attacker, you can induce the victim process to speculatively execute that function, and thereby leak data. It's a bit more complicated and involved than Meltdown, or Spectre within the same process, but it is possible and depending on the gadget chosen, any data within the victim process could be recovered.

nickpsecurity 9y ago

"t sounds more like advances in hardware virtualization yielded better solutions than a bunch of additional segment registers and slow context switches." The most secure OS's of the past used both paging and segments but for different things. Later on, the numbers I saw on Atom put segments at twice as fast as paging which matters given too much overhead makes people use mechanisms less. Finally, both Native Client and Code Pointer Integrity used segments for app-level protection which could run in VM's isolated by other mechanisms. So, they still have value given simplicity, efficiency, and fine granularity. I didnt like seeing them go given new developments were happening on segment-based designs.

kijiki 9y ago

> Intel was the one that dropped segment limits, AMD added them in later... I was there (at VMware). That isn't quite what happened. We got an early engineering prototype of the AMD64 chip. Ran at like 400Mhz or something, and was in an impressively massive case. It caused two big problems for us: 1) as you note, it disabled segment offsets on all segment registers except %FS and %GS, which are commonly used for thread local storage. And much worse for us, it disabled segment limit checking entirely, which we used to protect the virtual machine monitor (VMM) in the guest's virtual address space. 2) it disabled LAHF and SAHF instructions, which cause a pretty noticeable performance regression in the binary translator (BT). AMD was pretty helpful when we notified them, and Rev D and later of their chip had a special "VMware bit" that re-enabled segment limit checking and LAHF/SAHF. Intel was less helpful, and told us to just wait for Vanderpool (later renamed VT-X). Early versions of Vanderpool were actually slower than the traditional BT VMM. And annoyingly, for years VT-X didn't support real-mode or big-real-mode, so we had to keep emulation/BT around for that, which is really only used for the first half-second of bootup. AMD's Pacifica got this right from the start. Ole and some of the other early monitor hackers wrote a paper that covers some of this history if you want the gory details: https://www.ece.cmu.edu/~ece845/docs/vmware-evolution.pdf https://www.ece.cmu.edu/~ece845/docs/vmware-evolution.pdf