Running Multiple Operating Systems: Hypervisors

How do you run multiple operating systems on the same processor? You use virtualization and you run a hypervisor underneath all the so-called “guest” operating systems. So what is virtualization?

Virtualization started with VM/370 developed in 1972 at IBM (the current version is still in use). Here is how it works. Although it wasn’t called that back then, VM/370 was a hypervisor. The 360 architecture had two modes of operations, user-mode and supervisor-mode. In supervisor-mode the mainframe could do anything, execute any instruction, access protected memory or peripheral devices. In user-mode, only certain instructions were allowed and direct access to devices etc was prohibited. If the program attempted to use one of the prohibited instructions then the hardware would prevent it and trap into the operating system to shut the program down. There was a single instruction, SVC, that would switch from user-mode to supervisor-mode in a very controlled way so that user programs could make calls for operating system services such as file access (or reading punched cards!)

So how did the VM/370 run other operating systems? The basic idea is very simple: it ran them in user-mode. At first it sounds crazy, the moment the guest operating system tried to use one of instructions that it needed to use as an operating system but which it is prevented from doing because it is in user-mode, then the hardware will trap and VM/370 gets given control. And that is the point, VM/370 can work out what the guest operating system was trying to do and then do it. If the guest operating system tries to read a protected CPU register, for example, VM/370 can work out what the guest operating system should see (which might be totally different from the actual contents of that register) and supply it. In some sense, VM/370 is running a simulation of the guest operating systems. If one tries to do some I/O then VM/370 can do equivalent I/O (read a block off a magnetic tape perhaps) put the data in the appropriate memory locations and then return control to the guest operating system, which was running identical binary to what would run on the bare hardware.

If the guest operating system “knew” it was running in a virtual environment, it could actually make calls to the hypervisor. The 360 architecture had an instruction DIAGNOSE that was not used in either user programs or operating systems; it performed hardware diagnostics and was only used in specialized maintenance programs. Perfect, if the guest operating system executed a DIAGNOSE instruction then it acted as a sort of procedure call to VM/360 so guest operating systems could request resources etc.

It turns out the Intel x86 architecture wasn’t quite as clean as the 360 for virtualization. Although a user program cannot write specialized hardware registers without trapping, it can read them. Which means that just running in (the equivalent of) user-mode a guest operating system will see the “wrong” values, the actual values not the ones that “should” be there if the guest operating system were the real operating system. So virtualization systems like VMware have to scan the code and re-write it to look for this sort of thing (and it can make other transformations which improve guest operating system performance).

Over time the split between guest operating system and hypervisor has moved on. Most guest operating systems will no longer run on the “bare metal” and instead make calls directly to the hypervisor for services like I/O and the hypervisor is assumed to be present. The hypervisor thus makes it easy for different guest operating systems to share resources such as networks and file systems.

It is obvious that security is important in an environment like this. A big job of the hypervisor is to keep those guest operating systems separate so they cannot access each other’s data or, indeed, even detect the other systems. But if somehow you can take control of the hypervisor and run arbitrary code, or can access one guest operating systems resources from another, then you can subvert all the guest operating systems, steal all their secret data and more. To do this at the highest levels of reliability requires hardware support so that even a software bug in the hypervisor will not compromise the integrity of the system.

Virtualization technology using silicon capabilities, for example ARM TrustZone, can address these security challenges by enabling strong isolation and containment of guest operating environments. Hypervisor functioning at the highest privilege level in a system and partitioning memory and devices can ensure that misbehaving applications, either un-intentional or malicious, cannot disrupt or corrupt other areas of the system.

Mentor has a webinar Enabling Multi-OS Embedded Systems with Hypervisor Technology presented by Felix Baum. It is at 10am Pacific on November 12th, next Tuesday. Felix is in charge of virtualization, multi-OS and multi-core technologies for Mentor and has been in the embedded space for 20 years, originally as a hands-on developer.

Full details, including a link to register, are here.

More articles by Paul McLellan…