Yes, Virginia. We deliver GP's on control flow transfers at the wrong EIP.
Busted! This is just one of those tough situations where "perfect" software and "useful" software are in unresolvable conflict. While we could, in theory, get this corner case completely right, no customer would want us to. To patch up this hole we'd have to make all indirect kernel control flow transfers slower. Since literally nothing we've ever run into in the wild cares, we just get this wrong. C'est la vie. Though, interestingly enough, the one piece of software out there that we know relies on this behavior: the VMware VMM itself.
Since there are both architected (the backdoor port) and unarchitected (i.e., the s[gi]dt/lsl instructions) ways of discovering you're in a VM, this isn't really "news," per se, but interesting x86 trivia none the less. If it makes you upset, you have a few options to make the behavior in a VM more like that of real hardware. As Derek discovered, you can tick the "disable acceleration" checkbox in your VM. You can also buy a shiny, new Intel processor and drop "monitor_control.vt32=TRUE" into your config file, but expect lousy performance. (VT32 really only exists as a check on the correctness of our VT implementation; all the VT performance work has been sunk into running 64-bit guests.)
At the end of the day, discovering you're in a VM, in general, is always likely to be easy, just because of timing attacks. These pieces of code that folks write to detect that you're in a VM are sort of modern-day equivalents of the little assembly programs that were used for CPU identification before the CPUID instruction came along; these terribly clever little DOS programs would try to infer the size of the write buffer, time a few instructions, etc., and come up with a "fingerprint" of the CPU. These programs are serious fun to write, and have some educational value. I haven't seen any legitimate, practical uses of the VM detection programs thus far, though. I.e., congratulations, you now know you're on a VMware Workstation 4.5 VM. What are you going to do about it?
Since there are both architected (the backdoor port) and unarchitected (i.e., the s[gi]dt/lsl instructions) ways of discovering you're in a VM, this isn't really "news," per se, but interesting x86 trivia none the less. If it makes you upset, you have a few options to make the behavior in a VM more like that of real hardware. As Derek discovered, you can tick the "disable acceleration" checkbox in your VM. You can also buy a shiny, new Intel processor and drop "monitor_control.vt32=TRUE" into your config file, but expect lousy performance. (VT32 really only exists as a check on the correctness of our VT implementation; all the VT performance work has been sunk into running 64-bit guests.)
At the end of the day, discovering you're in a VM, in general, is always likely to be easy, just because of timing attacks. These pieces of code that folks write to detect that you're in a VM are sort of modern-day equivalents of the little assembly programs that were used for CPU identification before the CPUID instruction came along; these terribly clever little DOS programs would try to infer the size of the write buffer, time a few instructions, etc., and come up with a "fingerprint" of the CPU. These programs are serious fun to write, and have some educational value. I haven't seen any legitimate, practical uses of the VM detection programs thus far, though. I.e., congratulations, you now know you're on a VMware Workstation 4.5 VM. What are you going to do about it?
posted by Keith Adams at 1:52 PM
0 Comments:
Post a Comment
<< Home