3 ms·

But you don't have control of the supervisor if the attacking process is confined to the VM, do you? You certainly don't have access to the VM's supervisor mod

But you don't have control of the supervisor if the attacking process is confined to the VM, do you? You certainly don't have access to the VM's supervisor mode, since its "chip" wouldn't have this sort of physical vulnerability.

Avernar 10y ago
Depends on the type of VM. A VM emulating the same type of processor just runs the client code direct on the processor. What stops the client code from messing with the reat of the system, which includes the VM supervisor code, is the processor's protection circuitry. If client code does the exploit to kick the processor into supervisor or hypervisor mode it will be running client code in that elevated mode. Priveliged instructions would no longer trap to the VM's supervisor or host OS. Now if the VM is emulating the client's individual instructions, which is the usual for running code for a different type of CPU, then it's a different story. Under pure emulation it wouldn't work. The exploit would have to know what the host CPU architecture was, get the emulator code to trip the extra gate. As you said, all that would do is put the VM supervisor code into the CPU's supervisor mode which it probably is already in if the VM is running bare metal without a host OS. But if the VM use JIT conversion of the instructions for speed then the exploit becomes possible again.