7

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.

Apparently VirtualBox fails at this, along with Virtual PC and VMWare. Before I dive into monsters like Xen, is there any hyperviosr that can do this?

Improve this question
1
  • 2
    What is the security reason?
    – yfeldblum
    Commented Jan 12, 2012 at 2:37

5 Answers 5

Reset to default
14

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.

Improve this answer
3
  • "The Blue Pill is a demonstration of such a so-called "invisible hypervisor"" - actually, it is not invisible or undetectable.
    – D.W.
    Commented Feb 7, 2012 at 20:50
  • @D.W.: ... hence my use of the "so-called" slightly derogatory expression, and the double-quotes around "invisible hypervisor"; both are indicative of some distance between the expressed concept, and the narrator's opinion of said concept. The "Blue Pill" was meant not to be detected by detectors which existed at that time, but does not preclude the potential existence of newer detectors which are designed with the said Blue Pill in mind.
    – Tom Leek
    Commented Feb 7, 2012 at 21:33
  • @TomLeek +1 "mostly because there is no equality between skills at assembly system programming, and capacity to explain things to other people with pedagogy and serenity"
    – alx9r
    Commented Feb 2, 2013 at 17:52
2

What you want is basically not feasible, in practice. See the following detailed analysis from the research literature:

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.

Improve this answer
1

It sounds like you are looking for a hypervisor rookit, the blue pill is a good example of this type of rookit.

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.

Improve this answer
7
  • I don't think the OP is looking for malware, although this particular sort seems like it might accomplish what he's seeking.
    – Iszi
    Commented Jan 11, 2012 at 18:55
  • +1 -- whatever you classify it as, that's a proper example of code and a proper answer. It's also an academic piece of code that is open for review and was created for demonstration.
    – Jeff Ferland ♦
    Commented Jan 11, 2012 at 19:06
  • 1
    How will a rootkit possibly solve this problem? I'm looking for concrete software or a concrete group of software, not a academic idea
    – TheLQ
    Commented Jan 11, 2012 at 19:16
  • @Iszi Who said anything about malware? Doesn't that depend on how you use the software?
    – rook
    Commented Jan 11, 2012 at 19:41
  • @TheLQ I don't follow. Perhaps you should read my update.
    – rook
    Commented Jan 11, 2012 at 19:43
1

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
Improve this answer
1

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

Improve this answer
5
  • Your reasoning has a gap in it. So-called "non-virtualizible instructions" can be handled (emulated) by a VM. It is not correct to say that the existence of so-called "non-virtualizable instructions" implies that "if you know what to check for, you can always determine if you're running virtualized or bare metal". Therefore, your answer is not correct, and non-virtualizable instructions are not necessarily a barrier to building a transparent VM (in principle). (There are other barriers, though. Your conclusion is right; but the explanation and logic is flawed.)
    – D.W.
    Commented Feb 7, 2012 at 20:53
  • So you're saying that non-virtualizable instructions are virtualizable? Isn't this exactly what these papers debunk? Do you have any credible research for your point?
    – Marcin
    Commented Feb 7, 2012 at 23:07
  • 1
    Modern processors provide built-in support for virtualization, so this issue does not arise. Older x86 processors did have so-called "non-virtualizable instructions", but it is still possible to build a virtual machine that emulates those instructions using other methods, such as binary rewriting. "Non-virtualizable" (in the Popek and Goldberg sense) really means "not virtualizable by classic trap-and-emulate virtualization". As the Wikipedia article you cite explains, architectures with "non-virtualizable instructions" can still be fully virtualized; you just have to use different techniques.
    – D.W.
    Commented Feb 7, 2012 at 23:26
  • Do you have any credible research for your point?
    – Marcin
    Commented Feb 9, 2012 at 19:12
  • 1
    Oh, good grief, @Marcin. Go back and re-read the Wikipedia article that you cite in your answer; it summarizes the situation. I even gave you pointers to the parts to read. (Hint: read the part starting "Some architectures, like the non-hardware assisted x86, ...".) What more do you want?
    – D.W.
    Commented Feb 10, 2012 at 6:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .