Virtualization offers great benefits for embedded designs, such as consolidating multiple systems into a single platform or separating applications of different security levels. However, the use of virtualization in high-security and high-reliability applications like mil/aero has been hindered by the limitations of mainstream Type 1 and Type 2 hypervisors. These hypervisors are often too large or complex due to their underlying host or supporting operating system (OS), or too limited in configurability for embedded system designs. A new “Type Zero” hypervisor from LynuxWorks, named LynxSecure*, addresses these issues with a unique lightweight architecture designed specifically for embedded systems.
This new architecture features a minimized hypervisor that omits the need for a supporting OS and provides a toolset to give embedded architects granular control over system resources. The minimal design focuses on reducing the system attack surface and achieving high-reliability for mission-critical environments. What’s more, this new architecture leverages the features of 3rd Generation Intel® Core™ processors with Intel® Virtualization Technology (Intel® VT), allowing multiple OSs as well as bare-metal applications to securely run in virtualized environments and achieve near-native CPU and I/O performance.
The Role of the Hypervisor
The hypervisor is supervisory software that creates an abstraction layer between hardware and OSs, serving as the underlying technology of computer virtualization. Hypervisors achieve this layer of abstraction by taking full control over the physical computing platform to create software-emulated hardware platforms (Figure 1). These emulated platforms then allow OSs, referred to as guest OSs, to run on the emulated platform instead of on the physical hardware. The emulated platforms can be replicated multiple times to support multiple guest OSs on the same machine.
Figure 1. The hypervisor isolates the hardware, allowing multiple OSs to run on one machine concurrently.
Virtualization has become increasingly relevant to embedded applications. With advancements in hypervisor configurability, as well as the growth in multi-core performance and hardware virtualization acceleration from processors like the 3rd generation Intel® Core™ processor family, embedded architects are able to build embedded systems that solve some of the most difficult computing problems, such as:
Security Domain Isolation – The hypervisor has the ability to isolate access to hardware resources to create separate computing environments. Applications that currently require multiple (or redundant) computing platforms to process separate levels of classified data can now be combined on a single platform (Figure 2).
Figure 2. Hypervisor security domain isolation showing two environments running on one platform, eliminating the need for extra hardware.
Independent Measurement – Hypervisors can create independent computing environments that allow mission-critical functions to run without the interference of co-existing applications or the complex dependencies of full operating systems. Using a hypervisor, a single computing node can run a system application in one virtual environment and an independent health monitor in a separate environment to measure the status of the application (Figure 3). In the event of an application error, the health monitor has the opportunity to locally reset the application or direct a failover procedure for quicker response time and smarter fault-tolerance designs.
Figure 3. Hypervisor independent measurement uses an independent health monitor to supervise and possibly reset any application faults in the Guest OS.
Reference Monitoring – Hypervisors can provide the ability to independently mediate access and monitor information flow between applications and data channel interfaces to insure all information flow is untampered with and authorized to maintain secure operation (Figure 4).
Figure 4. A hypervisor reference monitor oversees and mediates information flow and access.
The 3rd Generation Intel Core processors serve a major role in supporting hypervisors with hardware features that greatly enhance virtualization security, performance, and determinism. These features include:
Intel® Virtualization Technology (Intel® VT) for IA-32, Intel® 64, and Intel® Architecture (Intel® VT-x) – Provides the hypervisor support for guest OS execution and memory management to reduce hypervisor software complexity and increase performance and security.
Intel® Virtualization Technology (Intel® VT) for Directed I/O (Intel® VT-d) – Provides the hypervisor support for I/O device assignment to protect guest OS I/O data channels and improve I/O performance.
Intel® Trusted Execution Technology (Intel® TXT) – Assists the hypervisor in boot-up procedure, bringing systems into secure initial states.
We will cover these technologies in greater detail in the following sections.
Introducing Type Zero
Hypervisors fit into two commonly designated architectures: Type 2 and Type 1. Type 2 hypervisors run as applications on top of general purpose OSs such as Windows or Mac OS. Type 2 hypervisors are commonly deployed to run user programs designed for OSs on a machine running a different OS; for example, running Windows applications on a Mac. Due to their reliance on general purpose OSs, Type 2 hypervisors are rarely used in embedded systems.
A Type 1 hypervisor runs directly on hardware. Today’s Type 1 hypervisors are typically integrated with a special-purpose host OS and additional service applications. The complexity of the host OS can impact the size, security, and performance of the overall solution. Security is a particular concern because the host OS typically manages the guest OS’s memory, file systems, and communication devices.
The Type Zero hypervisor is a new concept that is even smaller than Type 1. Type Zero is a bare-metal architecture that removes the need for a support OS. By shedding the support OS, the Type Zero hypervisor drastically reduces the size and computational overhead imposed on virtualization platforms. Figure 5 shows a comparison in size between Type 2, Type 1, and Type Zero architectures, indicating that the majority of code size in the Type 2 and Type 1 hypervisors is attributed to the supporting host or helper OS. Note that the Type 2 and Type 1 sizes listed here reflect hypervisors designed for enterprise applications.
Figure 5. Hypervisor Size Comparison Chart: This diagram shows Type Zero having the smallest code size, ideal for embedded systems.
The main motivation behind the Type Zero hypervisor design is to provide a robust foundation for embedded virtualization in safety- and security-critical systems. The major architectural design requirements include:
Minimal Size – The LynxSecure Type Zero hypervisor consumes about 120 KB of storage and 4 MB of system RAM. In comparison, today’s mainstream Type 1 hypervisors can require storage footprints from hundreds of megabytes to several gigabytes before adding guest OS images and consume several hundreds to nearly a gigabyte of RAM. The base storage and memory footprint of these Type 1 hypervisors range from tens to thousands of times larger than the demands of traditional embedded OSs which may well exceed the size restrictions on an embedded platform.
Maximum Efficiency – The Type Zero hypervisor is designed to operate with transparent overhead, where the majority of hypervisor operations are delegated to hardware-assisted operations such as Intel VT or software support in guest OSs. Intel VT performs various virtualization tasks directly in hardware, reducing the footprint of the hypervisor and improving its performance and determinism. By delegating the majority of operations outside of the hypervisor, Type Zero gives embedded system architects the open ability to fine tune their performance goals. Type 1 hypervisors depend on the underlying support of a closed OS, which may consume unnecessary CPU cycles outside the control of the embedded system architect.
Security – The best ways to strengthen the security of a hypervisor, or any system, are to limit the access software components have over privileged resources and to reduce the complexity of the design. Type 1 hypervisors that rely on host OSs include complex, privileged components like device drivers and I/O stacks. It can be very difficult to verify that these components do not possess an exploitable flaw. In contrast, LynxSecure uses a simpler design that removes the need for a support OS. In addition, LynxSecure leverages Intel VT, which performs various virtualization tasks directly in hardware, reducing the software complexity of the hypervisor and in turn reduces the system attack surface.
Reliability – Many factors contribute to the reliability of a hypervisor, including design complexity. To further reduce complexity, the LynxSecure Type Zero hypervisor runs as a stateless executable with minimal dynamic functionality, providing a simple, robust, and stable foundation. While Type 1 hypervisors are heavily tested to maintain operation, the reliance on an OS introduces significant risk through complexities in core components such as: dynamic process scheduling, full process model, dynamic memory management, file systems, I/O stacks, and third party device drivers. Any flaw in these components can cause system failure.
To better understand how these key embedded mission-critical requirements are met, the following section walks through LynuxWorks’ LynxSecure Type Zero hypervisor architecture.
LynxSecure – Type Zero Hypervisor Architecture
The LynxSecure Type Zero hypervisor architecture is divided into two parts: a privileged core hypervisor foundation and an unprivileged virtualization framework. The core foundation of the LynxSecure Type Zero hypervisor comprises a minimal set of components needed to securely and reliably virtualize guest computing environments. This foundation includes (Figure 6):
Figure 6. LynxSecure Type Zero hypervisor core contains key elements all designed for efficient operation in embedded systems while working closely with Intel VT hardware provisions.
Real-time Virtual CPU (RTvCPU) Scheduler – The real-time virtual CPU scheduler orchestrates the execution of general guest OSs, real-time guest OSs, and bare-metal applications on multiple, dedicated, or shared CPU cores. The real-time scheduler gives system architects precise control over the number of CPU cycles each guest executes to host hard real-time applications. The virtual CPU scheduler utilizes Intel VT-x, which provides hardware assist to significantly accelerate transfer of CPU control between the hypervisor and the guest OSs.
Memory Manager – The memory manager allocates the memory for each guest OS, protecting each guest OS’s memory from unauthorized access and controls communications between guest OSs. The memory manager benefits from the extended page table (EPT) feature of Intel VT-x, which assists in memory virtualization. Using EPT, guest OSs are able to directly manage their local memory page tables, no longer requiring assistance from the hypervisor. This removes a significant bottleneck in guest OS memory access performance.
The memory manager also uses Intel VT-d to securely control external I/O device read and write requests to guest OS memory. Intel VT-d enhances I/O security and availability because data intended for a specific device or guest OS is protected from unauthorized access by any other hardware or guest OS. Intel VT-d also adds hardware accelerators to the chipset that enables the hypervisor to assign specific I/O devices to specific guest OSs, creating direct memory access (DMA) channels for high-speed communication between guest OSs and I/O-hungry devices like network and storage controllers. In the past, a hypervisor had to intervene in every I/O transaction, significantly increasing I/O computational overhead.
Hypercall API – The Hypercall API is a privileged interface that provides guest OSs and bare-metal applications a facility for intercommunication, guest OS management, audit, and maintenance management.
Interrupt Handler – The interrupt handler manages interrupt signal routing between guest OSs, bare-metal applications, virtual devices, para-virtual devices, and physical devices.
Exception Handler – The exception handler manages illegal or privileged guest OS operations to ensure all system operations do not subvert the availability, integrity, and confidentiality protections provided by the hypervisor.
Security Monitor – The security monitor is responsible for bringing the hypervisor into a secure state and continuously monitors security critical hardware resources to maintain a secure operational state. The security monitor relies on Intel TXT during the startup initialization process. Intel TXT is a hardware security solution that protects against attacks by validating the behavior of key components. Prior to loading the hypervisor, Intel TXT checks the consistency in behaviors and launch-time configurations against a verified benchmark called a “known good” sequence stored within the hardware trusted platform module (TPM). Intel TXT also performs this check before launching guest OSs. In both cases, the system can quickly assess and alert against any attempts to alter or tamper with a launch-time environment.
System Audit – The system audit component is an advanced service for recording major security, safety, or user-defined system events that can be passed up to guest OSs or bare-metal applications to build robust fault detection, threat detection, and system recovery sub-systems.
The hypervisor core foundation is complemented by an unprivileged virtualization framework (Figure 7). The framework gives embedded architects granular control over system resources and management tools to handle guest OS boot-up procedures, intercommunication, device assignment, and remote administration. (The details of this framework are beyond the scope of this article, contact email@example.com for details.)
Figure 7. LynxSecure Type Zero virtualization framework consists of more than just the hypervisor itself as shown in this figure.
Meeting today’s embedded design demands
LynxSecure’s Type Zero hypervisor core design satisfies the size, efficiency, security, and reliability requirements of embedded mission-critical systems. By selecting a minimum set of functionality and utilizing Intel’s hardware assistance in Intel VT and Intel TXT, the size and complexity of the core components are drastically reduced to assure vital security and reliability logic is correct, while the software computational overhead is minimized to improve latency for a stronger deterministic behavior. The end result is a platform that is uniquely suited for embedded security-critical and high-reliability designs.