I need a VM Hypervisor that will not leak to the guest that its in a VM. The guest should believe its on a full physical machine.
Xen, by definition, is virtualized. It assumes a specific guest code for the operating system kernel. It does not try to hide the presence of virtualization, it actually advertises it plainly. This is not the VM you are looking for.
A fully invisible hypervisor is theoretically feasible, but not cheap. The problem is with timing. An hypervisor works by being able to intercept some "sensitive operations", notably related to memory access, and alter their behaviour. The alteration is done with software, which can effectively remain hidden by blocking some memory accesses, emulating an absence of RAM instead. However, such an interception takes a bit of time: handling of an intercepted memory access will use some extra clock cycles over what a non-intercepted call on "raw hardware" would do. Since code can access a clock with clock-cycle precision (not accuracy) through the
rdtsc opcode, interception can be detected. Unless the
rdtsc opcode is also intercepted, to make it "slower".
In effect, our invisible hypervisor can remain invisible only by "slowing down" the virtual machine, so that it gets enough hidden "extra cycles" for its interceptions. So the guest OS must:
- either have access to no external time source (and, if the guest OS has some network, it can access external time sources);
- or believe that the hardware is clocked at a lower rate than what the physical hardware really runs at.
As an extreme case, consider emulators. Emulators for older, 1980s-era systems can have clock-cycle accuracy, i.e. make the emulation so perfect that the code running in it is not capable of detecting that it does not run on the genuine hardware. But they can do that only by throwing a lot of computational power at it; the overhead is tremendous (we are talking about a 10x or 20x loss of computing power here). Moreover, emulating timing effects for an Atari ST is a relatively simple task because there is no cache in such a machine.
The Blue Pill is a demonstration of such a so-called "invisible hypervisor", and it generated some hot debate (as they say, "with more heat than light"), mostly because there is no equality between skills at assembly system programming, and capacity to explain things to other people with pedagogy and serenity. Nevertheless, the "blue pill" should be detectable, although finding actual code which does it, published on the Web, might be challenging.
An interesting point raised by the blue pill developer is that hypervisors are supposed to become mainstream and "normal", so that the presence of an hypervisor should not, in the long run, indicate that virtualization is occurring. It is conceivable, and even probable, that future operating systems will always activate an hypervisor upon boot time, so detecting that virtualization is in place would no longer indicate possible foul play. We have not reached that point yet, though.
It's not doable 100% in x86. There are some instructions that are not virtualizable, thus if you know what to check for, you can always determine if you're running virtualized or bare metal.
Here's some sources to read up on:
http://en.wikipedia.org/wiki/Popek_and_Goldberg_virtualization_requirements is the best starting point on this topic.
Another good one is http://www.usenix.org/events/sec2000/full_papers/robin/robin.pdf
What you want is basically not feasible, in practice. See the following detailed analysis from the research literature:
- Compatibility is Not Transparency: VMM Detection Myths and Realities. Tal Garfinkel, Keith Adams, Andrew Warfield, Jason Franklin. 11th Workshop on Hot Topics in Operating Systems (HOTOS-X), 2007.
There are any number of ways that a malicious guest can detect that it is running in a VM: timing, discrepancies in the semantics of certain obscure CPU instructions, discrepancies in handling of drivers and peripherals, discrepancies in the size of various caches (which causes detectable effects on performance), and many more. See the paper for a detailed analysis. They go into more depth than any answer here -- or than there is space to cover here.
This is just a type of VM that hides its self from the guest, and it just so happens that it can be used to hide an attacker's activities. You can use this software however you want, you don't have to be an attacker. You can use nmap and ping to debug network problems. A hammer can be used to put in a nail or to break a window.
KVM uses "standard" hardware, but if you know what you are looking for you can still tell.
(Also obviously if you install the Guest OS tools it will become apparent regardless of what you use)
What you're trying to hide is anything that would mention the VM in the processes, files, registry, memory, hardware, or processor instructions.
If you're able to do all that (depending on how important this project actually is) you're then going to have to hide the communication method (which I know on VMWare uses a hardcoded value for).
What in particular are you trying to solve with this solution?
- Tricking users into thinking it's a real machine
- Malware Analysis etc.
- Something else entirely