Open Hypervisor - Home

Design Options

Virtualization technologies can be differentiated in many ways. Our objective is to discuss such issues. (sorted in no particular order)

Modular Structure

The L4 hypervisor has been said to be well structured but less useable. However, much used hypervisors are less structured (see interview with Chris Dalton). The existing hypervisors have strengths and weaknesses. What are the issues? How could they be solved?

Certification

Hypervisors could be certified. This is a difficult topic for open source hypervisors. If volunteers improve it, a typical certification will become invalid. But do we need certified hypervisors in the first place?

Drivers

Type 1 hypervisors may have a lack of device drivers. Is this a short run issue only?

With/Without Remote Attestation

Same as option "measured vs. not measured".

Clipboard vs. full isolation

Users may wish to have a clipboard. Even though tunneling compartments via email is a nuisance for the users they will find this alternative to the clipboard quickly (if the compartments are set-up to allow for this). Exchanging data between compartments may, however, reduce security.

Permanent attestation vs. Boot Time Attestation

Same as option "measured vs. not measured".

Secure vs. not secure GUI

There are two issues worth to be debated with regard to the graphical user interface of virtual systems.

  1. Sealed image and permanent status bar: If one aims at protecting assets against malware, such as Trojan horses, one may wish to provide the user with hard to forge information about the quality of the hypervisor used. This may mean to use a user-selected image, which will only be displayed if the hypervisor is in a proper state (see OpenTC Newsletter No.5). This may also mean to use a permanent status bar, indicating to the user what is going on, whether the hypervisor is fine, and what compartments are running. Users may wish that the status bar disappears, for instance, when giving a presentation or when viewing a video. One would have to make sure that the sealed image is not shown on a conference screen. Alternatively, one could have a new hardware button on the keyboard. By clicking on it, one could go securely from one virtual machine to the next. The options of sealed image, taskbar and hardware button have obvious trade-offs in terms of costs for implementation and learning on the one hand, and benefits, on the other.
  2. Small code base vs. windows: We anticipate some users will only want to have two or perhaps three compartments. They could use them one by one, in full screen mode (or what is left next to the novel task bar, see point 1). Other users will wish to have many compartments, and would like to view several of them next to each other, much like the application windows of today's operating systems. The latter could, in a fairly straightforward way, be implemented using graphical systems available with today's hypervisors, such as X Window. However, X Window is large and may contain security holes.

Open vs. proprietary

A hypervisor can be used to provide isolation. Users can, e.g., isolate confidential data from less sensitive data, general web surfing, new code, etc. Vulnerabilities of their main operating systems would then not exist in a separated one. However, a proprietary hypervisor might contain security holes, accidentally or on purpose. "On purpose" refers to the fact that software may contain holes to allow espionage. Such holes may exist to fight terrorism, crime, or be just there to spy for economic reasons. Without saying what sort of intentional or accidental holes exist today in hypervisors, operating systems and applications, when designing a hypervisor the issue emerges whether it should have such holes or not. We propose it should not have such holes, because any hole built in for good reasons can be exploited for bad reasons. To cut a long story short: If computing moves towards using a hypervisor, it should be provided with open source software, so that interested users can check whether it contains holes.

Measured vs. not measured

Hypervisors can be distributed like any other software, but they could also be distributed using a verification mechanism like the one provided with so-called Trusted Computing. We do not say that you will trust Trusted Computing. Still, the wide-spread TPM-chip, designed according to the Trusted Computing Group's specifications, can be used to verify whether a hypervisor, or an operating system, is in a proper state, or has been altered.

TC-based verification can be used to protect a user against malware, e.g., against malicious updates from a CD. However, such measurements require an infrastructure for being conducted, which comes at some costs. Also, measured hypervisors can be verified for correctness remotely, e.g. by an employer. Yes, we know, it has been discussed to use this feature for DRM, too.

Permanent attestation would verify the code while running. This is a usefull feature but is still a research challenge.

Type 1 vs. Type 2

Basically there are two ways to do virtualization. With "bare metal hypervisors" which run directly on the hardware, the individual operating systems run on top of them. This is called "type 1" virtualization, used by, e.g., XEN. Alternatively, one can also run an operating system much like an application in another operating system. This is called a "type 2" virtualization, used, e.g., with the VMWare Workstation. The alternatives have pros and cons. With type 1, one can achieve isolation in a quite straightforward way, but it may be difficult to manage devices. With type 2, the virtualized operating system can use the drivers provided by the underlying operating system.