4

I recently started learning about xen and became more interested in visualization. I read a few whitepapers, did a search here, but couldn't find an answer. My guess is someone will link me to some helpful documents.

Say I'm using a domU in xen (or a virtual machine on whatever platform).

How does the computer prevent the virtualized machine from executing arbitrary instructions?

Since the dom0 or host machine has to execute the instructions the domU needs...shouldn't it be easy?

How can you possibly validate that something is sandboxed? and (one more time in different words) what are the steps taken to sandbox these?

curiousguy
  • 5,028
  • 3
  • 25
  • 27
  • possible duplicate of [How secure are virtual machines really? False sense of security?](http://security.stackexchange.com/questions/3056/how-secure-are-virtual-machines-really-false-sense-of-security) –  Aug 22 '12 at 10:17
  • 1
    I don't think it was a duplicate. I'm asking more about the mechanisms used to ensure security, not IF there is security. Either way. Case is closed now. –  Aug 22 '12 at 13:12

3 Answers3

5

The implementation of the virtual machine is a kernel for the kernel.

In a typical operating system, there is application code (aka "userland") and kernel code. They use the same set of instructions; however, the CPU knows, at any time, whether it is executing application or kernel code. When application code tries to execute some opcodes which access the hardware (the in and out opcodes for x86), the CPU traps: it temporarily jumps to kernel code (the address of that code is registered in a specific table). The kernel code decides what to do with the access (grant it, modify it, kill the application process...). If the kernel code decides to grant the access, or the kernel blocks it but pretends to have performed it, then application code can believe that it could access the hardware directly.

Similarly, when application code reads or writes data in memory, it uses an abstraction of memory: a virtual address space which is mapped to physical memory (or not...) through the MMU. The MMU uses tables that the kernel fills (and, of course, the kernel takes care not to make these tables part of the address space visible from the application code). This way, the application is in a magical world where it is alone in a big address space, whereas in reality there are several concurrently executed applications, which cannot see each other.

A virtual machine uses the same structure, one level up. When the kernel accesses the hardware or the MMU, it actually is under scrutiny of the virtual machine implementation (the hypervisor) which traps unwanted accesses.

Particulars vary quite a lot. The main distinction is whether the kernel is aware that it runs in a virtual machine or not. With Xen, the kernel is aware; it knows that it is under control of a superior deity (the hypervisor) and does not try to tap into the hardware directly; instead, it asks nicely through a dedicated interface. With VirtualBox, the kernel is not aware; the guest operating system believes that it runs on true hardware, and the VM works hard to maintain the illusion.

Other differences can be made on the means by which virtualization is enforced (i.e. how the hypervisor can trap kernel code). Recent x86 processors offer some specific support with dedicated opcodes. Older x86 processors, in 32-bit mode, can use the various remnants of older protection mechanisms (segment registers and the four "rings", mostly)(these have been removed from 64-bit mode, which is why 64-bit VM must use AMD-V/VT-x). Other techniques include emulating each virtualized opcode (for the whole of the emulated machine, or parts of it), possibly with more-or-less dynamic translation (aka JIT compilation), aas QEMU does in cross-CPU situations.

There is a whole paraphernalia of terms on the subject (virtualization, paravirtualization, emulation, simulation, hypervisor...) which is not completely consensual, and often quite byzantine. Some readers who cling to some specific doctrines of terminology have probably been somewhat irritated by the loose way I use the terms.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • This was really helpful. I guess I didn't understand the process that happens when a virtual machine attempts to execute an instruction. Thanks a lot. :-) –  Aug 22 '12 at 13:10
3

Conceptually, a virtual machine is an emulator. Have you ever seen the Nintendo emulators, where you stick an old Nintendo game in and it emulates the Nintendo console? It works like this: the emulator repeatedly reads an instruction from the game, then emulates the effect of executing that instruction (simulating the Nintendo hardware, but using software running on your computer), and so on.

A virtual machine is just like that, except instead of emulating the Nintendo hardware, it emulates Intel x86 hardware. A virtual machine reads an instruction from the guest, emulates its effect (inside the sandbox), and then goes on to the next instruction. Since emulation is done by software, the software can be written to check that the effects of the instruction stay within the sandbox.

Conceptually, that's how a virtual machine works. In practice, virtual machines don't work anything like that; emulation is very slow, so virtual machines use various methods to make the process run really fast. Many modern processors include hardware support for virtualization to make a virtual machine run as fast as possible. But you can think of it as a big, honkin', magically speedy CPU emulator, and that'll give you the right intuition.

So, conceptually, that's how a virtual machine can ensure that the guest cannot escape from the sandbox. The virtual machine can check the effect of every instruction to make sure it won't escape, and execute the instruction only if everything is OK.

For more on this subject, I recommend reading the following questions on this site:

Community
  • 1
D.W.
  • 98,420
  • 30
  • 267
  • 572
  • 2
    Your description of VMs is a little outdated. These days the VM's guest code runs native on the physical CPU, rather than being emulated. It works a little bit like a JIT compiler - a block of code is read, wrapped and translated to ensure sandboxing, then executed directly on the CPU. Modern CPUs help facilitate this by offering [virtualization extensions](http://en.wikipedia.org/wiki/X86_virtualization#Hardware_assist). – Polynomial Aug 22 '12 at 07:31
  • @Polynomial, I know all that. My description is not dated at all. Read my answer again. I emphasized that *conceptually* this is how they work -- but "in practice, virtual machines don't work anything like that" (that's a direct quote!). Most VMs today work using hardware support for virtualization, which enables most of the code to run natively -- but again, conceptually, it's just an emulator with tricks to make it run really fast. As far as JIT: in the days before hardware support for virtualization, most VMs used to work like a JIT compiler, but that is no longer the case today. – D.W. Aug 23 '12 at 06:47
  • Sorry, my brain seems to have skipped over the bit where you mentioned hardware emulation. Was just trying to clarify so people weren't confused, but clearly unnecessary – Polynomial Aug 23 '12 at 07:27
2

That would depend on the type of virtualization, with hardware virtualization (Xen, ESX, Hyper-V) there is, like D.W. says, no problem.

However with kernel virtualization (LXC, openVZ) there is still a risk of breaking out of the jail. With openVZ there haven't been any recent reported exploits to break out to the host machine, but with LXC there have.

From a security standpoint I recommend using hardware virtualization rather than kernel virtualization.

Lucas Kauffman
  • 54,169
  • 17
  • 112
  • 196