# Breaking Virtualization Software by switching the cpu to Virtual 8086 mode

Jonathan Brossard

<figure><img src="image_1.png" /></figure>

## To cite this version:

Jonathan Brossard. Breaking Virtualization Software by switching the cpu to Virtual 8086 mode. Hack In the Box Malaysia, HITB, Oct 2010, Kuala Lumpur (Malaysia), Malaysia. hal-05242058

HAL Id: hal-05242058

https://hal.science/hal-05242058v1

Submitted on 5 Sep 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Breaking Virtualization Software by switching the cpu to Virtual
8086 mode

Jonathan Brossard - jonathan.brossard@toucan-system.com

Security Research Engineer & CEO, Toucan System, France

"A mind is like a parachute. It doesn't work if it is not open." – Frank Zappa

**Abstract.** In the last 5 years, virtualization software have been massively adopted by companies as a mean to reduce costs, achieve instant scalability, and possibly better their security through isolation. Recent numbers[1] indicate that 78 percent of companies have their production servers virtualized, and 20 percent of them actually only rely on virtualized servers. At the same time, security auditing of such software poses unique challenges, in particular when it comes to dynamic testing. In this paper, we describe a methodology for the security assessment of virtualization software based on switching the CPU mode to virtual 8086 mode in order to get access to the (possibly virtualized) hardware, that aims at being both generic (applicable to both x86 and x64 architectures) and extremely large in terms of code coverage. We have implemented this technology under the form of a dynamic testing tool which has proved to be very efficient in finding bugs in virtualization software.

**Keywords:** Virtualization, virtual 8086 mode, dynamic testing, x64 fuzzing.

# 1 Introduction

A recent study[1] shows that 78 percent of companies have adopted virtualization for their production servers. 98 percent of them declared using VMware, 17 percent virtualization software from Microsoft, and 10 percent Xen (Citrix).

From an attacker's perspective, this makes virtualization software extremely attractive. First of all because this makes virtualization software more popular than, say, Apache webservers, and secondly because getting a (virtualized) shell on the same physical computer than a given target typically only requires paying a few euros a month to a shared hosting company. Mutualized hosting and outsourced cloud computing solutions have therefor become utterly attractive to attackers.

We will first give a few definitions regarding virtualization that will help the reader unfamiliar with virtualization software get some fundamentals. Readers already familiar with virtualization software can safely skip this section. We will then outline why auditing virtualization software using standard techniques is very unlikely to give any result in practice, introduce the methodology we developed, and finally discuss results we obtained on actual virtualization software and limitations of our technique.
1.1 Virtualization : a few definitions

Virtualization is the name given to the simulation with higher level components, of lower level compo-
nents. Virtualization of applications (as opposed to full Operating Systems) is out of the scope of this
paper.

A virtual machine, commonly simply referred to as a “VM”, is “an efficient, isolated duplicate of a real
machine”.[2]

The operating system running on real hardware is called a “host”, while the ones running on virtualized
hardware are called “guests”. Virtualization software can be divided under different categories depend-
ing on their designs.

If the virtualization software requires the guests operating systems to be modified in order to run prop-
erly<fnref n="1" />, then the type of virtualization is called paravirtualization (as opposed to “full virtualization”), as
shown in figure 1.

<figure><img src="image_3.png" /><figcaption>Fig. 1. Paravirtualization.</figcaption></figure>

It is also common to distinguish between two types of virtualization software based on whether they
require a host OS at all. Virtualization software running on “bare metal”<fnref n="2" />, that is, those not requiring
any OS are called “type I” virtualization software. In this case, the OS is the Virtualization software
itself. “Type II”<fnref n="3" /> virtualization software, to the opposite, require a proper operation system to be in-
stalled and run much like any other application on top of it, as a process inside this host OS.

A special sub case can furthermore be distinguished when the hypervizor takes advantage of CPU vir-
tualization extensions (known as AMD-V or Intel VT-x technologies). In this later hardware assisted
case, the hypervisor is said to run in “ring -1” as shown in figure 4.

Finally, several operating systems<fnref n="4" /> also offer a lesser form of virtualization which is referred to as “iso-
lation”. In this later case, the kernel is common to all the instances of the virtual machines running on
the same physical machine, so that only the user land part of the operating system is different from

<footnote n="1">¹ eg: Xen, UML, Qemu with kquemu, and to a lesser level, VMWare Workstation with VMWare Tools.</footnote>

<footnote n="2">² eg: Citrix Xen, Microsoft's Hyper-V or VMWare ESX.</footnote>

<footnote n="3">³ eg: Qemu, Oracle's Virtualbox, VMWare Workstation, Apple's Parallels.</footnote>

<footnote n="4">⁴ eg: Linux-Vservers, Solaris Zones, BSD jails, OpenVZ under GNU/Linux.</footnote>
<figure><img src="image_4.png" /><figcaption>Fig. 2. Type I virtualization.</figcaption></figure>

<figure><img src="image_5.png" /><figcaption>Fig. 3. Type II virtualization.</figcaption></figure>
<figure><img src="image_6.png" /><figcaption>Fig. 4. Hypervisor using CPU virtualization extensions.</figcaption></figure>

VM to VM. The obvious drawback of this technique is that it is not possible to run different kernels with isolation: all the VMs will be running the same kernel, necessarily the one of the host.

## 1.2 Attack surface analysis and previous work

When attacking virtualization software, one can think of different scenarios with different vectors and impacts. We will now try to summarize briefly the attack surface by illustrating previous research performed on this field.

First of all, if a virtualization software is installed on a given host and an attacker managed to somehow get access to the host itself, he can try to exploit a vulnerability on this software to potentially elevate his privileges on the computer. This attack is somehow the lesser form of attacks against virtual machines since the conditions (having a shell on the host itself) are typically not met in real life. An example of such a vulnerability is the “VMware Tools HGFS Local Privilege Escalation Vulnerability” disclosed by iDefense[3].

In the same vein, it is imaginable that an attacker who managed to get a shell on a guest VM could exploit a vulnerability in the virtualization software to escalate privileges on the guest VM itself. Such an attack has been detailed by Tavis Ormandy and Julien Tinnes against VMware[4], which by the way is quite remarkable from a technical perspective.

Now, since virtualization software only typically are of interest when they run multiple VMs, we can also think of other attacks that are more specific to virtualization software.

For instance, an attacker may, from inside a given guest, try to attack another guest on the same physical machine. An example of this is the VMware vulnerability[5] which abused the “clipboard transfer” feature of Vmware workstation. Or he may exploit a vulnerability from a guest machine that will crash not only its own guest, but also the host machine, and therefore any other guest present on the same computer, resulting in a general Denial of Service of both the host and all of the guests. Examples of
<figure><img src="image_7.png" /><figcaption>Fig. 5. Isolation.</figcaption></figure>

such attacks are vulnerabilities[6][7], which abused specially crafted ioctls() to perform a global DoS.

Finally, the Graal of VMs exploitation is to escape from a guest machine to obtain a shell on the host computer itself, hence completely breaking the virtualization security paradigm. Such attacks have been exposed by Rafal Wojtczuk[8] at the Blackhat US 2008 conference, and more trivially in iDe-fense's VMware “Workstation Shared Folders Directory Traversal Vulnerability”[9].

Now that we have a better understanding of the vulnerabilities potentially affecting virtualization software, we can move to the techniques usually used to discover them.
## 2 Interacting with hardware: the need for new techniques

On one hand, some of the vulnerabilities described in the previous section take advantage of features specific to one virtualization software, and can hardly be generalized. This is for instance the case of those abusing “hypercalls”, additional system calls or instructions which act as communication channels through which a guest communicates with the hypervisor. On the other hand, most of the attack surface is shared by all the virtualization software. For instance, all of them will somehow offer virtualized hardware (virtual hard disks to the least, possibly virtualized displays, keyboards, sound cards, etc).

So how does one test virtualized hardware? From a software perspective, it should (hopefully) not differ too much from real hardware, otherwise most of the guest operating system would need to be rewritten in order to interact with it. For the sake of illustration, we will focus on testing virtual hard disks, but the following reasoning can be safely applied to most hardware and peripherals<fnref n="5" />

Testing a hard disk for security bugs typically involves reading and writing to the disk. A naive approach to perform those operations would be using the `read()` and `write()` system calls provided by the kernel to user land applications. Under GNU/Linux for instance, those system calls are defined in the `"unistd.h"` header file, and have the following prototypes:

```c
ssize_t read(int fd, void *buf, size_t count);
ssize_t write(int fd, const void *buf, size_t count);
```

The problem with this trivial approach is that the search space for a dynamic testing tool is virtually infinite, the size of the read (respectively write) operation being virtually infinite<fnref n="6" />. Idem regarding the content of the buffer being written when performing a write operation.

A better idea would be to use dedicated machine opcodes to interact with the hardware more directly rather than being proxied through many layers of kernel code (hardware drivers in particular), hence reducing the search space. Under GNU/Linux, this is achievable through the use of the following functions:

```
outb, outw, outl, outsb, outsw, outsl, inb, inw, inl, insb,
insw, insl,outb_p, outw_p, outl_p, inb_p, inw_p, inl_p
```

Those functions are used to perform low level input/output operations using `ioports`, as explained in the corresponding Linux manual page:

This family of functions is used to do low-level port input and output. The `out*` functions do port output, the `in*` functions do port input; the `b-suffix` functions are byte-width and the `w-suffix` functions word-width; the `_p-suffix` functions pause until the I/O completes. They are primarily designed for internal kernel use, but can be used from user space.

<footnote n="5">⁵ cf. the “Limitations” section of this paper for a detailed analysis of this assertion.</footnote>

<footnote n="6">⁶ It would actually probably be bounded by extremely large hardware limitations such as the capacity of the hard disk or the capacity of CPU registers used to address memory in practice. The point is that such a search space is not exhaustible in practice.</footnote>
The main problem with this approach is testing all of the combinations of ioport numbers and sequences
possibly resulting in a read (respectively write) operation to the hard disk. Once again, the search space
is infinite<fnref n="7" />

Finally, common hardware fuzzing techniques include the use of the ioctl() system call to perform read and write operation on device drivers. The prototype for this system call, defined in the "sys/ioctl.h" header file is the following:

int ioctl(int d, int request, ...);

The first argument is the device driver that will be used to perform the operation. The second one specifies the type of operation to be performed : either read or write, and specifies if the desired request requires an additional argument. In this later case, a third argument is passed to the kernel, which is... of arbitrary length. Hence, once again, an infinite search space.

To summarize what we covered in this section, the standard API offered by the kernel doesn't allow an auditor to perform an exhaustive testing of hardware devices using standard techniques. Hence the need for a better suited methodology that we will now detail.

3 Dynamic testing using the virtual 8086 mode

In a nutshell, the main idea behind our dynamic testing methodology is to reduce the search space as much as possible. To do so, we will reduce the inputs to 16 bits CPU registers, and switch the CPU mode to 8086 mode.

3.1 Introducing the virtual 8086 mode

The virtual 8086 mode is a CPU mode introduced by Intel with the 80386 CPU back in 1985. Following the Intel manuals[11][12], Intel processors have three main modes : protected mode is the native mode of the CPU. It's core features are segmentation, pagination and multitasking. It uses 32 (respectively 64 under x64) bits addressing. Real mode is the mode the CPU uses when switched on before giving control to the BIOS, which will load a master boot record, then a kernel, and switch to protected mode. It is not capable of multitasking, uses 20b memory addressing thanks to two 16b registers (a segment and an offset). It uses segmentation but no pagination. The CPU normally doesn't normally get back to real mode until the next reboot. Finally System Management Mode (SMM) was introduced as a special mode to handle platform specific tasks, in particular power management and system security. Switching to this latest mode to abuse security features has first been proved practical by Loic Duflot[13], and then got some attention from the community[14][15].

The Virtual 8086 mode (often called VM86 mode) has been introduced to run legacy 16b real mode software (such as MS DOS applications) under a 32b Operating system running in protected mode. It features 20b addressing compatible with real mode, segmentation, but also - unlike real mode applications-paging. Some CPUs feature a Virtual 8086 Enhancement Mode which can be identified by the "vme" flag in the CPU capabilities<fnref n="8" />. x64 CPUs running in 32b protected mode are also capable of switching to 8086 mode, but this mode is not available anymore when running in 64b long mode.

To sum it up, virtual 8086 let us run 16b applications in a mode compatible with old school MS
DOS programming. The feature relevant to our research is that back in the days of MS DOS, pro-
grammers had direct access to the hardware by calling interrupt handlers set up either by the BIOS
during BIOS POST, or by the OS itself (the infamous interrupt 0x21 under MS DOS for instance) in

<footnote n="7">⁷ The curious reader may nonetheless refer to our prior research[10] for actual examples of ioports() programming.</footnote>

<footnote n="8">⁸ by displaying content of the /proc/cpuinfo file under GNU/Linux for instance.</footnote>
the first page of the physical memory in a zone called “Interrupt vector table” (IVT), which can be seen as a jump table of 256 entries (one per interrupt, corresponding to 256 possible interrupt handlers).

Calling hardware interrupts under real mode or virtual 8086 mode involves passing parameters in 16b CPU registers, AX being the desired functions, and BX, CX, DX (or less often a combination of BP, SI, DI) being used as additional arguments if necessary. To summarize our example of virtual disk testing, read and write operations were handled by interruption 0x13. As the reader will agree, the level of control on the hardware is much lower than with the system calls introduced in the previous sections. For instance, reading a sector (512 bytes) from disk to memory was performed by specifying from which track, sector and head the read should be performed, specifying the appropriate function in ax (0x42 for a read from disk) and then calling interruption 0x13, as detailed in figure 6.

<figure><img src="image_8.png" /><figcaption>Fig. 6. Reading one sector from disk using interruption 0x13.</figcaption></figure>

From an auditor's perspective, being able to call such interrupt handlers means raw access to the hardware, and is therefore likely to be interesting. If we have a closer look at the complexity of testing a given interrupt exhaustively, testing all possible combinations of 4 CPU registers (ax, bx, cx, dx) is equivalent to perform : [0; 65535] ^ 4 or about 1.8 * 10 ^ 19 calls to the corresponding interrupt handler. This is still a fairly large number, but at least, it is finite, unlike with the previously described techniques. Let us now see how the CPU can be forced to switch from a given mode to an other in order to verify if we can actually have a chance to perform a switch to our desired virtual 8086 mode.

## 3.2 Switching CPU modes

In theory, switching between modes is possible, according to the Intel manuals[12]. Switching from protected mode to virtual 8086 mode (and back) involves setting (respectively removing) the VM flag in the cr0 control register. In the same way, setting or removing the PE flag from the cr0 register allows to switch from Protected mode to real mode. Switching to System Management Mode is not a standard feature (it involves generating a SMI as described in [13]) and is out of topic in this paper. Any write operation to the control registers requires ring0 privileges. This information is summarized in figure 7.

In practice, Operating systems often switch from protected mode to real mode when shutting down or more commonly when rebooting so that the kernel finds the CPU in the state it is expecting to. Under GNU/Linux, the shellcode presented in figure 8 and taken from linux-2.6.31/arch/x86/kernel/reboot.c performs this operation.
Now, if this operation is possible from ring0 on a non-virtualized computer, let's see how it applies to the architecture of a guest virtual machine.
<figure><img src="image_9.png" /><figcaption>Fig. 7. CPU mode switching in Intel compatible CPUs.</figcaption></figure>

```c
static const unsigned char real_mode_switch [] =
{
    0x66, 0x0f, 0x20, 0xc0,          /* movl %cr0,%eax */
    0x66, 0x83, 0xe0, 0x11,          /* andl $0x00000011,%eax */
    0x66, 0x0d, 0x00, 0x00, 0x00, 0x60,  /* orl $0x60000000,%eax */
    0x66, 0x0f, 0x22, 0xc0,          /* movl %eax,%cr0 */
    0x66, 0x0f, 0x22, 0xd8,          /* movl %eax,%cr3 */
    0x66, 0x0f, 0x20, 0xc3,          /* movl %cr0,%ebx */
    0x66, 0x81, 0xe3, 0x00, 0x00, 0x00, 0x60,  /* andl $0x60000000,%ebx */
    0x74, 0x02,              /* jz f */
    0x0f, 0x09,              /* wbinvd */
    0x24, 0x10,              /* f: andb $0x10,al */
    0x66, 0x0f, 0x22, 0xc0      /* movl %eax,%cr0 */
};
```

<caption>Fig. 8. Switch from protected to real mode shellcode under the GNU/linux kernel.</caption>
### 3.3 Switching to Virtual 8086 mode from inside a virtual machine

When using virtualization software, the hypervisor runs under protected mode (in a mode varying from ring3 to ring1 or ring0, or even the hardware assisted "ring -1" with the virtualization extension offered by some Intel and AMD CPUs). All of the guests actually run in a protected mode task. Additionally, the guest OS typically starts from an emulated 8086 mode (16b) so its 16b bootloader can work properly, and then switches at early kernel stage to protected mode too (32b).

From our perspective, this means that we will not be able to switch to a proper real mode, nor to a proper virtual 8086 mode, in particular because privileged access to the control registers (cr0 to cr4) are completely emulated inside a virtual machine.

Nonetheless, the astute reader will have noticed that running 16b applications (typically MS DOS applications) under a virtual machine, even under a guest OS running under 32b protected mode is perfectly possible. The truth is, we don't need a proper switch to virtual 8086 mode to perform this. Most Operating systems offer a way to run 16b applications under protected mode by emulating a switch to Virtual 8086 Mode.

Under Windows Operating systems, this is achieved thanks to the binary ntvdm.exe, the « Windows 16b Virtual Machine ». The user should be familiar with 16b shells such as the one represented in figure 9.

<figure><img src="image_10.png" /><figcaption>Fig. 9. Exemple of a 16b command line using the Windows 16b virtual machine.</figcaption></figure>

Under Linux, the kernel provides an emulation of real mode in the for of two system calls :

```
#define __NR_vm86old          113
#define __NR_vm86             166
```

The first system call is deprecated and actually turns out to call the second one in recent kernels. Both system calls expect very similar inputs as defined in the sys/vm86.h header file :
```c
int vm86old(struct vm86\_struct *info);
int vm86(unsigned long fn, struct vm86plus_struct *v86);
```

The argument common to those two syscalls is the following structure:

```c
struct vm86_struct {
    struct vm86 regs;
    unsigned long flags;
    unsigned long screen bitmap;
    unsigned long cpu_type;
    struct revectored_struct int_revectored;
    struct revectored_struct int21_revectored;
};
```

The most important field in the structure is the vm86\_regs structure, which has the following layout, as defined in linux-2.6.31/arch/x86/include/asm/vm86.h:

```c
struct vm86 regs {
    long ebx;
    long ecx;
    long edx;
    long esi;
    long edi;
    long ebp;
    long eax;
    ...
    unsigned short es, _esh;
    unsigned short ds, _dsh;
    unsigned short fs, _fsh;
    unsigned short gs, _gsh;
}
```

This API allows us to perform arbitrary calls to emulated 16b interrupts by setting the registers to the desired values in the latest structure.

It is worth to notice that the switch to 8086 Virtual Mode is completely emulated by the kernel, and is not a proper access to the hardware. Nonetheless, for our testing purpose, this doesn't really matter<fnref n="9" />: how does one “emulate” the display of a pixel at line X and column Y ? Simply by displaying this pixel at line X and column Y ! At the end of the day, the number of kernel layers actually traversed is irrelevant as long as our arguments are actually passed to the hardware (but for performance). Having discovered this, we can now program using old style (MS-DOS like) programming by requesting arbitrary hardware interruptions. In essence, we just got a seemingly “bare metal” (possibly virtualized) hardware interface”, even tough, once again, our calls will be proxied through many kernel layers before reaching the hardware.

<footnote n="9">⁹ We will see in the next section that it is actually an asset for us when it comes to work with x64 CPUs in long 64x mode, which x64 CPUs do not support.</footnote>
## 3.4 Extention to x64 architectures

Under x64 architecture, the vm86 mode is no longer accessible when the CPU is running in 64b long mode (there is no such limitation when using it to run a 32b protected mode Operating System). It therefore seems impossible because of hardware limitations to extend our methodology to x64 architectures.

Paradoxically, keeping in mind that the switch to vm86 mode is completely emulated by the kernel, it is actually possible to modify a x64 kernel to add vm86 capabilities. Credit for this idea and implementation (initially done to run Dosemu under AMD 64b CPUs) goes to the http://v86-64.sourceforge.net/project.

This seemingly anecdotal feature actually allows us to now run our tool on the higher segment of hypervisors, most Type II hypervisors (namely Vmware ESX and Microsoft HyperV) being supported under x64 CPUs only.

# 4 Outro

Now that we have detailed the inner working of our dynamic testing tool, we will give a few example of vulnerabilities discovered by running our fuzzer under different virtualization software.

## 4.1 Experimental results

As mentioned in the introduction, different classes of attacks can be performed against virtual machine software. A crash in a simple guest machine should not be underestimated as it could lead to interesting attacks, for example to elevate privileges inside the guest OS itself.

All the bugs listed in this section apply to the current version of the virtualization software at the time of writing.

So far, we managed to trigger bugs in the hypervisor of Oracle's Virtualbox (figure 10 and 11). We also observed guests crashes and a minor bug in Microsoft Virtual PC (figure 12), Apple's parallels (figure 13), and more importantly in Microsoft HyperV running under the 64b version of Windows 2008 R2 (figure 14).

Only `qemu` has been so far resisting completely to our audits, which is a bit surprising since this software known for emulating all of the hardware (including the display for instance), its attack surface being maximal, we expected to get a high number of bugs. We must therefore salute the authors of this tool for the quality of their code.

It's worth noting that a complete evaluation of a virtualization technology takes several parallel instances (think "cloud") in order to have a correct vulnerability coverage and that dedicated technology, id est: the audit software is not publicly available. Therefore, the dynamics of the discovery of vulnerabilities in these product from our approach can be addressed from a VM vendor perspective by carefully auditing their product through security-oriented QA auditing.

## 4.2 Limitations

There are several limitations to our approach of dynamic testing of virtualization software. First of all, we are only auditing the virtualized hardware and hardware virtualization. This means in particular that we do not test at all hypercalls and more globally inter-vm communication, being it between a guest and the host, nor within the guests among themselves.
<figure><img src="image_11.png" /><figcaption>Fig. 10. Truncated error message after the crash of the Virtualbox's hypervisor.</figcaption></figure>

<figure><img src="image_12.png" /><figcaption>Fig. 11. Virtualbox hypervisor crash (screenshot).</figcaption></figure>
<figure><img src="image_13.png" /><figcaption>Fig. 12. Microsoft Virtual PC guest bug.</figcaption></figure>

---------- Guest processor state ----------
Inhibit Mask=0

CS=FF63 [0000FFFF 0000F30F] V=1
SS=FFD3 [0000FFFF 00CF9300] V=1
DS=0018 [0000FFFF 00CFF300] V=1
ES=0018 [0000FFFF 00CFF300] V=1
FS=FF9B [0000FFFF 00CF9300] V=1
GS=0018 [0000FFFF 00CF9300] V=1

EAX=000000A9 EBX=00005148 ECX=0000F686 EDX=0000000B
ESI=00002D72 EDI=000007E4 EBP=00002E99 ESP=00000FFA
EIP=0000FE96 EFLAGS=00023202

<caption>Fig. 13. Apple's Parallels truncated error message after a guest VM crash.</caption>
<figure><img src="image_14.png" /><figcaption>Fig. 14. Screenshot of Microsoft HyperV event logs.</figcaption></figure>

The second limitation comes from the fact that we only test hardware accessible through the Interrupt Vector Table, as typically discovered by the BIOS during BIOS POST. While this includes hard disks (including usb drives and keys), graphical displays, keyboards and many peripherals, some recent hardware (usually less critical, such as the one handled by Microsoft “plug and play” technology) is nowadays handled directly by the kernel of the Operating System after full boot is performed.

## 4.3 Conclusion

In the present paper, we presented a methodology for auditing virtual machine software with an unprecedented coverage. Our method takes advantage of old and sometimes misunderstood features of Intel compatible CPUs and revisited them to perform tasks that would otherwise be extremely complex to handle. In particular, we detailed how our methodology offers a far better code coverage than standard hardware testing techniques when it comes to virtualization software. If its search scope is still too big to be exhaustively explored in a reasonable time with a personal computer infrastructure, it has the non negligible benefit of being finite and doable in professional context. Taking into account that our dynamic testing tool can be run in more than one virtual machine under a single computer, a very large subset of the search space can actually be explored with realistic computer power.

To the best of our knowledge, this is the first attempt to design a tool specifically to audit specifically virtual machines software, taking into account their architecture and differences from real hardware. As a result, we managed to uncover multiple bugs in most virtualization software of the market, proving the benefit of such approach in practice.
## References

1. Forrester: Study on virtualization (2009)

2. Popek, G.J., Goldberg, R.P.: Formal requirements for virtualizable third generation architectures. In: Communications of the ACM. (1974)

3. iDefense: Vmware tools hgfs local privilege escalation vulnerability, cve-2007-5671 (2007)

4. Travis Ormandy, J.T.: Mishandled exception on page fault in vmware,cve-2009-2267 (2009)

5. Caspi, E.: Vmare workstation guest isolation weaknesses, cve-2007-0833 (2007)

6. seppi: Vmware workstation "vstor-ws60" driver local denial of service vulnerability, cve-2007-4591 (2007)

7. Unknown: Vmware workstation vstor2-ws60.sys unspecified local dos, cve-2007-4593 (2007)

8. Wojtczuk, R.: Subverting the xen hypervisor, Blackhat USA (2008)

9. iDefense: Workstation shared folders directory traversal vulnerability, cve-2008-0923 (2008)

10. Brossard, J.: Bypassing preboot authentication passwords by instrumenting the bios keyboard buffer, Defcon (2008)

11. Intel: Intel 64 and ia-32 architectures software developer's manual. In: Volume 1: Basic Architecture. (2008)

12. Intel: Intel 64 and ia-32 architectures software developer's manual. In: Volume 3A: System Programming Guide. (2008)

13. Duflo, L.: Security issues related to pentium system management mode, CanSecWest (2006)

14. BSDaemon, coideloko, D.: System management mode hack using smm for "other purposes". (Phrack magazine)

15. Wecherowski, F.: A real smm rootkit. (Phrack magazine)