Basics and lifecycle of a VM - Part #0

vm

(Guess, there's a solution I'm not seeing.) #1

Basics and lifecycle of a VM - Part #0

Edit
  • Added navigation links
  • some restructuring in the link section

Disclaimer

This article is based on extensive research and I am not an expert in this field. The only intention I’ve got was “to understand how virtualization is working and share it” (a pretty naive target). Please tell me any mistake you discover. I will correct it as quick as possible.

How does a Virtual Machine works? Well, an OS is running in a separate program (e.g. Virtual-Box, Hyper-V) which makes this OS “think” it runs on a real PC, but in reality it has no power over my PC at all. This all can be done because magicians working at Intel, AMD and this company which develops VirtualBox.

This is the standard explanation which is kinda right, but… nah, how does this stuff works in reality? So, lets get the basic high level view:

When you booting up a guest OS as VM on your machine, a part of your kernel starts executing special virtualization instructions on your CPU. This kernel module is called a Hypervisor or a Virtual Machine Monitor (VMM) which, you guessed it, monitors what your VM does.

There are two ways to design a VMM.

  1. The host virtualization type. Here your install a software on an already existing OS (the host). This software installs it’s hypervisor driver and runs the VMs with it.
    Software examples: VirtualBox, Vmware.
 –––––––––––––––––––––––     –––––––––––––––––––––––
|                       |   |                       |
|       GUEST OS        |   |      GUEST OS         |
|                       |   |                       |
 –––––––––––––––––––––––     –––––––––––––––––––––––
|                       |   |                       |
|     KERNEL GUEST OS   |   |   KERNEL GUEST OS     |           ...
 –––––––––––––––––––––––     –––––––––––––––––––––––   –––––––––––––––––––––
            |___________________________|________________________|
                                 |
 ––––––––––––––––––––––––––––––––|––––––––––––––––––––––––––  
|                                |                          |
|         HOST OS                |        HOST OS           |
 –––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
|                       |        |         |                |
|   KERNEL HOST         |   VMM MODULE     |  KERNEL HOST   |
|                       |        |         |                |
 –––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
|                                |                          |
|                          HARDWARE                         |
|                                                           |

  1. The bare metal hypervisor. This one is a hypervisor running directly on the hardware (started by the BIOS). On top of this all the guests are running with their own kernels. To manage the guests there is a more privileged VM running with which you can also control the hypervisor.
    Software examples: Xen, KVM.
 –––––––––––––––––––––––     –––––––––––––––––––––––
|                       |   |                       |
|       GUEST OS        |   |      GUEST OS         |
|                       |   |                       |
 –––––––––––––––––––––––     –––––––––––––––––––––––
|                       |   |                       |
|     KERNEL GUEST OS   |   |   KERNEL GUEST OS     |           ...
 –––––––––––––––––––––––     –––––––––––––––––––––––   –––––––––––––––––––––
            |__________________ ________|________________________|
                               |               |
                               |               |
                               |               | < MANAGES GUESTS
                               |  –––––––––––––––––––––––––––
                               | |                           |
                               | |    MANAGEMENT OS          |
                               | |                           |
                               |  –––––––––––––––––––––––––––
                               |                    |
                               |                    |
                               |                    |
 –––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
|                              |                            |
|                         HYPERVISOR (e.g. XEN)             |
|                              |                            |
 –––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
|                              |                            |
|                          HARDWARE                         |
|                                                           |

This is still a pretty high level view on the whole topic. So let’s go deeper.

Your CPU got a hell lot of instructions which can be used by software like your kernel. Basic ones which read values from a register or more complex ones like AES encryption routines. And beside those, also a set of virtualization instructions (VMX operations).

To start your VM with your guest OS the VMM will set up a rule set, executes a VMXON instruction on the CPU and enters the VM.
“Enter the VM” basically means that the processor starts executing the code of the guest OS (usually the BIOS). The processor is aware that a VM is executing code and not the actual host kernel (this processor state is called: VMX non-root operation mode).
If the guest tries to run specific CPU instructions which are not allowed, the processor will “exit” the VMX non-root mode and give back control to the VMM. The VMM can look at the instruction the guest has tried to execute, executes the instruction on behalf of the guest OS (or doesn’t) and uses a VMRESUME to enter the VM again (a.k.a sets the processor state into VMX non-root mode).
This game will go on and on until you decide to shut down the VM.

set up ––––> VMXON ––––––> VMLAUNCH/–––––––> VM has –––––– ––––––––> VMOFF
rule set                   VMRESUME         control       |
                          ^                               |
                          |                               |
                          |                         Tries to exec.
                          |                         root operation
                          |                               |
                      VMM exec.  <–––– VM–exit <––––––––––
                     instructions

As you see the guest OS is running most the time natively on your CPU. Occasionally interrupted by VM-exits and VM-entries.
Those transitions between the VM and the VMM are relatively costly in terms of CPU-cycles. When it comes to a VM-exit the processor has to

1. save the CPU state of the guest system (copy registers etc.),
2. store information about the reason for the VM-Exit,
3. restore the CPU state of the VMM,
4. the VMM will handle the instructions the guest OS wasn’t allowed to execute
5. save the result for the guest,
6. save its own CPU state and return to the VM (VMRESUME).

At this point we already can see why using a VM is safer than just running a normal OS. In case you’ve got some malware on your guest OS running, it will only be able to execute harmless CPU instructions. All the important ones, which could affect our host systems memory and execution flow, get executed by the VMM.

Because a VMM just have to handle specific instructions of the VM, the code is way less complex than of an OS kernel. Which means:
less codesmaller attack surfaceharder to find vulnerabilities.

This process is similar to User-Mode <> Kernel-Mode traps on not virtualized operation systems. Although in this case we create another layer under the guest OS kernel and therefore another possibility to control processes on the upper layers.

This was it for now. In the next part we talk about the rule sets of the VM. It should get much clearer than why the VMM has actually that much control.

In case you want to program a basic hypervisor yourself, you can follow the first of those links down there.



<-- Introduction
The VMCS - Part #1 -->

Do it yourself

But I want to read about hacky stuff!


Introduction: Hardware Virtualization - Part #4294967295
(Burning away in an Explosion) #2

Great Article! I never thought that much about VM’s and how secure they’re. Also I never knew that the code of a VM is directly executed on the CPU (which in my case sounds pretty vurnable despite it’s controlled by the VMM). Looking forward to read more about that :wink:


(Guess, there's a solution I'm not seeing.) #3

Well, obviously, every code has to run at some point on a CPU. But before hardware virtualization was there hypervisors did changed some instructions before executing them on the CPU (which can be seen as “guest code never runs directly on the CPU”).
This is called Binary Translation and because every instruction needs to be checked by the hypervisor before execution it was pretty ineffective.