An example of isolation of critical components is the PIN-entry code used for authorizing a credit-card transaction. The PIN-entry subsystem must be demonstrably secure and protected from faults (or viruses) in the remainder of the system. The best way to enable such security is to minimize the trusted computing base (TCB) of the critical code; in other words, minimize the amount of code that can interfere with its operation. In particular, it must be strongly isolated from any rich OS and the GUI stacks it supports.

This can be achieved by running the PIN-entry code directly on the hypervisor (akin to running on "naked" hardware), as shown in Figure 3. This may keep the TCB of the PIN-entry code as small as 15 kLoC.

Figure 3. Critical code running directly on the hypervisor can be isolated from the rest of the system to minimize its TCB

Other variants of the isolation theme are protecting the code that implements digital rights management or sensitive proprietary code. It may also help to reduce certification cost: A particular subsystem (say a baseband stack in a mobile phone) can be certified independently of the rich OS environment, if the hypervisor guarantees strong isolation. As the rich OS environment , which supports the user-visible functionality, tends to change much more frequently than the software implementing the basic communication protocols, this can lead to significant cost savings.

Examples of remote control are firmware-over-the-air (FOTA) upgrades and remote disablement (eg. wiping sensitive contents from a stolen phone). While these can be implemented by other means, the indirection level provided by the hypervisor simplifies implementation (and therefore reduces cost) as well as reducing downtime for FOTA. If sufficient resources can be made temporarily available, the new version of a subsystem can boot up while the old one is still running (See Figure 4), enabling a very fast switchover.

Figure 4. FOTA implementation is simplified and downtime due to upgrades minimized with the help of a hypervisor

Requirements for hypervisors
From the above discussion of virtualization use cases, we can derive a number of requirements for hypervisors that can be used in a resource-constrained embedded system.

First, the hypervisor must support the processor architecture used in the embedded system. Unlike the enterprise space, where the x86 architecture is pervasive, many embedded systems use other kinds of processors. Specifically, the mobile wireless space is dominated by ARM cores; in other verticals the MIPS and Power architectures are prevalent.

The basic scenario of co-existing rich and real-time OS implies first off that the hypervisor must be real-time capable, meaning that it has bounded and short interrupt latencies.

Isolation between virtual machines is, by definition, provided by any hypervisor. However, while in enterprise systems strong isolation is the prime motivation for the use of virtualization, this is not so in embedded systems. All the various subsystems of an embedded system contribute to its overall functionality, and therefore require strong cooperation. This implies a need for low-overhead, low-latency, high-bandwidth communication channels between subsystems (i.e. virtual machines).

The hypervisor must also not consume significant resources, as this would drive up the BOM cost. Furthermore, the security use cases (PIN entry and IP protection) require that the system is highly resilient not only to software, but also hardware-based attacks. This means that all security-critical code (which includes the hypervisor) must be contained in on-chip memory. This puts very severe restrictions on the size of the hypervisor. Similar arguments can be made for the device-management use cases.

Can enterprise hypervisors do the job?
This issue is difficult to illustrate for proprietary systems whose source code is kept secret. Fortunately some of the most widely deployed hypervisors are open-source systems, and therefore provide an excellent base for comparison. In the enterprise space these are Xen and KVM, and in the embedded space OKL4, a member of the L4 microkernel family. While these three systems do not cover the whole design space, they are representative enough for our purpose. Xen actually straddles both spaces, as it has recently been adapted for embedded use. How do these systems fare with respect to the requirements we have identified above?

Let's start with KVM. The approach taken is that it turns the complete Linux kernel into the hypervisor, by activating the x86 hypervisor mode. Such a special execution mode does not exist on present ARM or MIPS processors, and KVM cannot be used on those, ruling it out of much of the embedded space (although hardware support for virtualization is bound to appear on such processors in the future).