Embedded Hypervisor - Implementation

Implementation

To meet the requirements typical of most embedded applications, an embedded hypervisor must provide multiple VMs, each of which is essentially indistinguishable from the underlying hardware to which the virtualised software needs access. This ensures that the embedded code that runs on the real machine will run on the virtual machine and vice versa. The size and efficiency of the implementation is also an issue for an embedded hypervisor, as it needs to maintain as closely as possible the native speed, real-time response and determinism and power efficiency of the underlying hardware platform.

Implementations for embedded systems applications have been most commonly based on the use of a microkernel or small separation kernel, with virtualization built-in as an integral capability. This was introduced with PikeOS in 2005. Examples of these approaches have been produced by companies such as Open Kernel Labs (microkernel) and LynuxWorks (small separation kernel). VirtualLogix appears to take the position that an approach based on a dedicated Virtual Machine Monitor (VMM) would be even smaller and more efficient. This issue is the subject of some ongoing debate; see references, &. However, the main point at issue is the same on all sides of the discussion – the speed and size of the implementation (for a given level of functionality) are of major importance. For example: " . . . hypervisors for embedded use must be real-time capable, as well as resource-miserly."

The small code size generated by these approaches is of such great importance since system resources such as memory are typically highly constrained in embedded applications, compared to enterprise systems. Thus embedded hypervisors usually have a memory footprint from several tens to several hundred kilobytes, depending on the efficiency of the implementation and the level of functionality provided. An implementation requiring several megabytes of memory (or more) is generally not acceptable.

The small size of the hypervisor also provides the basis for a minimal trusted computing base (TCB). This TCB is the only part of the entire system code which is allowed to run in privileged mode, thus enhancing the inherent security of the system. The amount of trusted user-mode code can be kept to an absolute minimum with this approach. This is in contrast to type 2 hypervisors, which are commonly designed to be used with a guest OS underneath any other software.

This approach also means that the TCB can be made highly secure & reliable. Standard software-engineering techniques, such as code inspections and systematic testing, can be used to reduce the number of bugs in such a small code base to a tiny fraction of the defects that must be expected for a hypervisor and guest OS combination that may be 100,000–300,000 lines in total.

One of the most important functions required in an embedded hypervisor is a secure message-passing mechanism, which is needed to support real-time communication between processes. In the embedded environment, a system will typically have a number of closely coupled tasks, some of which may require secure isolation from each other. In a virtualized environment, the embedded hypervisor will support and enforce this isolation between multiple VMs. These VMs will therefore require access to a mechanism that provides low-latency communication between the tasks.

An inter-process communication (IPC) mechanism can be used to provide these functions, as well as invoking all system services, and implemented in a manner which ensures that the desired level of VM isolation is maintained. Also, due to its significant impact on system performance, such an IPC mechanism should be highly optimised for minimal latency.

Lastly, an embedded hypervisor needs to be in complete control of system resources, including memory accesses, to ensure that software cannot break out of the VM. So an embedded hypervisor requires the target CPU to provide memory management support (typically using an MMU). However, unlike the enterprise space, a number of processors aimed at embedded applications do not provide such support, so selection of a suitable target architecture able to support a Type 1 hypervisor may be an issue.