Question

I’m trying to detect whether I am running on a virtual environment (vmware, virtualbox, etc)
On Windows I’ve use several ASM but I can’t use them in Linux, mainly because the code might be compiled and run on either 32 or 64 bit Linux.

The following code works on both Windows 32 and 64 and was tested on VMWare, virtualbox and other virtual machines:

#include <stdio.h> 

int idtCheck () 
{ 
    unsigned char m[2]; 
    __asm sidt m; 
    printf("IDTR: %2.2x %2.2x\n", m[0], m[1]); 
    return (m[1]>0xd0) ? 1 : 0; 
} 

int gdtCheck() 
{ 
    unsigned char m[2]; 
    __asm sgdt m; 
    printf("GDTR: %2.2x %2.2x\n", m[0], m[1]);
    return (m[1]>0xd0) ? 1 : 0; 
} 

int ldtCheck() 
{ 
    unsigned char m[2]; 
    __asm sldt m; 
    printf("LDTR: %2.2x %2.2x\n", m[0], m[1]); 
    return (m[0] != 0x00 && m[1] != 0x00) ? 1 : 0; 
} 

int main(int argc, char * argv[]) 
{ 
    idtCheck(); 
    gdtCheck(); 

    if (ldtCheck()) 
        printf("Virtual Machine detected.\n"); 
    else 
        printf("Native machine detected.\n"); 

    return 0; 
}

now, GCC complains about the __asm on all the functions. I tried with asm(), asm and other forms that I used in the past but none work. Any ideas?

Answer 1

Well, I haven’t disassembled the machine code in there, but here’s a version using GCC inline assembler:

int redpill()
{
        unsigned char idt_addr[(sizeof(long)==8)?10:6];
        __asm__("SIDT (%[ptr])"
                        : "=m" (idt_addr)
                        : [ptr] "r" (&idt_addr));
        // examine high order byte
        return idt_addr[(sizeof(long)==8)?9:5] > 0xd0;
}

This should ‘work’ even for 64-bit, but I’ve not tested it there.

HOWEVER! This isn’t guaranteed to give the result you want, at all. First, it won’t work with hardware virtualization, as you can’t see the true IDT. Second, it relies on an implementation detail of VMWare and Virtual PC, which could probably be changed quite easily. It might even kick off false alarms if your OS decides to put its IDT at a high address. So I don’t recommend this approach at all.

For virtual machines using the VMX hardware support, probably your best bet would be to do something which should be fast in hardware but require a trap in a virtual machine, and check the timing. Something like CPUID would be a good bet; benchmark it in a VM and on real hardware (compared against a dummy loop that does an ADD or something to deal with differing clock rates), and see which profile the test machine more closely matches. Since each CPUID will have to exit the VM to ask the host kernel what capabilities it wants to present, it will take a LOT longer than on real hardware.

For other kinds of virtual machines, you could do a similar timing check simply by loading a control register or debug register – the VM will have to trap it, or replace it with emulated code. If you’re on something like VMware, it might replace the trap with some emulated code – in this case, you might be able to identify it by timing modifying the code containing the control register or debug register operation. This will force the VM to invalidate its cached code, necessitating an expensive trap to the VM, which will show up on your benchmark.

Note that both of these approaches will require help from the OS kernel – it is going to be very hard to determine if you’re in a VM if you don’t have control of the emulated kernel at least. And if the VM is really sophisticated, it might fake timing as well, at which point things get really difficult – but this tends to kill performance, and result in clock drift (easy to identify if you can connect to the internet and query a time server somewhere!), so most commercial VMs don’t do it.