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.