Type Zero Hypervisor the New Frontier in Embedded Virtualization The hypervisor s full control over the hardware platform and ability to virtualize hardware platforms are beneficial in environments that face high security threats and demand high reliability. By Will Keegan and Arun Subbarao, LynuxWorks, Inc. Virtualization is a thriving technology proven to be successful in enterprise IT such as data centers and cloud computing. However, technology vendors have only scratched the surface on providing virtualization-based solutions, leaving untapped opportunities in industries beyond IT, specifically in the security-critical and safetycritical markets. A major tech producing industry that has yet to fully seize the expansive opportunities of virtualization is the embedded computing world, which serves a wide set of markets from defense systems to biomedical devices. This slower adoption is due to the underlying technology of virtualization the hypervisor. Up until now, hypervisors were primarily designed to serve the popular demands of enterprise IT, focused to run in IT server and desktop environments. As a result, these enterprise IT hypervisors do not support the strict properties commonly needed in embedded designs such as low power, small size, and determinism. However, as security in these embedded devices becomes a significant concern, the possibly of using virtualization to achieve security in embedded devices is gaining momentum in the embedded market. This article identifies unique security and reliability capabilities hypervisors have to offer to the embedded community and how the new Type Zero Hypervisor is able to deliver these capabilities with its unique architecture. Hypervisors for IT Infrastructure The hypervisor is software that creates an abstraction layer between hardware and operating systems, 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 virtual hardware platforms that emulate the underlying hardware (Figure 1). These emulated platforms then allow operating systems, 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, and can also be transferred to other hypervisor enabled machines. Today, hypervisors are most commonly deployed on IT servers and PCs to take advantage of multi-guest OS operation, which reduces the cost of maintaining multiple platforms and combines the capabilities offered by multiple flavors of OSs on a single platform. Hypervisors used in IT fit into two commonly designated architectures, type 2 and type 1: Type 2 hypervisors run as applications on top of a 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. Type 1, also referred to as bare metal, is a single software hypervisor package that runs directly on hardware. The software packages in today s IT type 1 hypervisors include a hypervisor integrated, or paired, with a special purpose host operating system and additional applications to support features needed by the enterprise IT market. Existing type 2 and type 1 hypervisors are unsuited for use in embedded systems because they include a significant amount of unnecessary functionality that can greatly impact the size, security, and performance of an embedded system design. Figure 1 - Hypervisor Embedded Hypervisors Going 24 Engineers Guide to Embedded Linux and Android 2013
Beyond IT Hypervisors, if designed correctly, can offer benefits for embedded devices, and provide capabilities that are not offered by today s enterprise hypervisors. The hypervisor s full control over the hardware platform and ability to virtualize hardware platforms can be used to build advanced solutions to solve major problems in environments that face a high security threat and demand high reliability. Some of the major security and reliability use cases offered by hypervisors are listed below: maintaining separation between the security domains (Figure 2). Independent Measurement - In safety-critical environments, systems are commonly built with redundant components and system health monitors to detect the event of a component failure and recover operation with redundant components. Hypervisors can create independent computing environments that allow mission-critical functions to run without the interference of co-existing applications or complex dependencies of Security Domain Isolation - The hypervisor s full control over the hardware platform has the ability to isolate access to hardware resources to create separate computing environments for guest OSs that prohibit unauthorized information flow between security domains. Security domain isolation is extremely useful in tactical defense systems deployed on size, weight, and power (SWaP) restricted platforms, such as Humvees Figure 4 - Hypervisor Reference Monitor Figure 2 - Hypervisor Security Domain Isolation Figure 3- Hypervisor Independent Measurement and aircraft, that currently require multiple computing platforms to process separate levels of classified data. With a hypervisor a single computing platform can be used to process multiple levels of classified data while 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-tolerant designs. Reference Monitoring - Both safety-critical and security-critical system computing nodes rely on data channel interfaces for either local storage or intersystem communication. A compromise in the integrity or authenticity of data transferred over communication channels can compromise the security and availability of the entire system. 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 un-tampered and always authorized to maintain operation. These hypervisor security and reliability use cases face two major technical challenges: 1) Having a security foundation that hosts independent computing domains and controls information flow between guest OSs, critical www.eecatalog.com/embeddedlinux 25
Figure 5 - Hypervisor Size Comparison Chart functions, and system resources. 2) Availability of a hypervisor that addresses the needs of embedded platforms. These challenges by themselves are hard to satisfy with today s existing solutions. Trying to satisfy both requires a new design. The Type Zero hypervisor architecture, designed by LynuxWorks from the ground-up to operate in safetycritical and security-critical environments while meeting the stringent demands of embedded computing platforms, fully satisfies the requirements of these and many other use cases. Introducing Type Zero Type Zero is a new bare-metal architecture, designed by LynuxWorks, that differentiates from type 1 by removing the all un-needed functionality from the security sensitive hypervisor mode yet virtualizes guest operating systems in a tiny stand-alone package. By shedding the need of support by a full operating system, the Type Zero hypervisor drastically reduces the size and computational overhead imposed on target embedded systems. 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 underlying host or helper OS. Small size is one of many hypervisor design aspects needed by embedded systems. In order for hypervisors to operate in embedded mission critical systems, major architectural design considerations must be addressed to ensure key embedded, security, and reliability requirements are recognized and accommodated. The following properties are identified as key hypervisor architecture requirements for embedded virtualization systems for use in safety-critical and security-critical environments: Minimal Size - Embedded systems are commonly faced with limiting storage and memory restrictions. Embedded solutions utilizing virtualization technology must consider both the footprint of the guest OS and the foot print of the supporting hypervisor. Typical embedded hypervisors consume less than 512 KB of storage and less than 4MB of system RAM. In contrast, today s available type 1 hypervisors require storage footprints from hundreds of megabytes to several gigabytes before adding guest OS images, and consume several hundreds of megabytes to nearly a gigabyte of RAM. The base storage and memory footprint of type 1 hypervisors range from tens to thousands times larger than the demands of traditional embedded OSs which may well exceed the size restrictions on an embedded platform. Maximum Efficiency - Efficiency is very important for embedded solutions that have demanding throughput specifications or must operate in power-conscious devices with very limited processing capabilities. In order to maximize efficiency, hypervisors must only contain the functionality that is necessary and sufficient to serve the guest OS & its applications. Type 1 hypervisors, for example, depend on the underlying 26 Engineers Guide to Embedded Linux and Android 2013
support of a closed operating system, which may consume unnecessary CPU cycles outside the control of the embedded system architect. Determinism - Embedded systems often rely on the ability to guarantee the time of execution for all system operations. Having control over the timeliness of system operations allows architects to construct solutions that ensure the proper behavior of mission-critical functions and overall system availability. The biggest impact hypervisors have on determinism is the scheduler used to assign guest OSs CPU processing cycles. In order to perform any function that requires deterministic behavior in a virtualized environment, architects must have full control over the hypervisor scheduler to guarantee that critical functions are scheduled to execute on time, and to ensure that other low priority operations do not interfere with critical processes. Type 1 hypervisors utilize a dynamic CPU scheduler that determines the order of execution of guest OSs on CPU based on guest OS throughput demand. Dynamic CPU schedulers take control of execution from the system architect and pass it to the guest applications, which invariably get exploited by rogue applications for DDoS attacks. Security - Security is the most important property of a hypervisor running in high threat environments. The hypervisor is privileged software responsible for orchestrating the simultaneous execution of guest OSs while protecting each guest OS s integrity, confidentiality, and availability. All code running in the hypervisor has a direct impact the on overall security, reliability, and determinism of a hypervisor-enabled platform. Any unauthorized access or control over the hypervisor can be devastating for embedded solutions targeted for operation in safety or security-critical environments. The best way to strengthen the security of a hypervisor, or any system, is to limit the access 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. This creates a situation which makes it very difficult to verify that the code in these components do not possess an exploitable flaw to gain unauthorized access to the hypervisor. Reliability - Reliability is the most important property for safety-critical systems. Many factors contribute to the reliability of a hypervisor, including, design complexity, determinism, and foundational security. Type 1 hypervisors are heavily tested to maintain operation, but the reliance on a full operating system does introduce 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. Flexibility - Any foundational technology used in embedded systems requires flexibility for architects to mold the technology to fit their specific system designs. Although hypervisors are mainly marketed for their ability to host multiple OSs, the hypervisor s control over the physical hardware can provide capabilities that go beyond emulating computer platforms. Type 1 hypervisors provide a limiting user model that conforms to enterprise IT use cases. LynuxWorks LynxSecure Type Zero hypervisor exemplifies these architectural principles to ensure that key embedded mission-critical requirements can be realized using virtualization, as discussed in detail in the next section. LynxSecure - Type Zero Hypervisor Architecture The design goal of the LynxSecure Type Zero hypervisor architecture is to provide a secure and reliable foundation for virtualization platforms to serve a broad array of computing environments from embedded to enterprise systems. This objective of providing a secure foundation with the features to serve an expansive market poses a common paradox found in architecture design. A secure and reliable foundation demands a small and simple code base, but offering broad functionality increases complexity which can compromise size and security. Lynx- Secure s Type Zero architecture solves this problem of by establishing a foundational core needed by all virtualization markets while providing an external configuration framework that allows for many unique virtualization solutions to be constructed, without imposing unnecessary code bloat in the hypervisor core. LynxSecure - Type Zero Hypervisor Core The core foundation of the Type Zero hypervisor establishes a baseline set of functionality to support a virtualization framework that will enable system architects to build virtualization solutions for any market. The key to supporting this framework is selecting the minimal set of components needed maintain a secure, reliable, and efficient foundation for all forms Type Zero hypervisor deployments. The following set of functional components is implemented to comprise the LynxSecure Type Zero hypervisor core foundation (Figure 6): Real-time Virtual CPU (RTvCPU) Scheduler - The realtime virtual CPU scheduler orchestrates the execution of general guest OSs, real-time guest OS, and bare-metal applications) on the hardware CPU cores. The real-time scheduler gives system architects the flexibility to control execution scheduling on multiple, dedicated, or shared CPU cores with clock-tick precision to host realtime OSs and applications. The virtual CPU scheduler utilizes Intel VT-x to allow guest OSs to run directly on the CPU cores, reducing significant software complexity www.eecatalog.com/embeddedlinux 27
Figure 6 - LynxSecure Type Zero Hypervisor Core and computational overhead. Without VT-x, hypervisors require additional software support to emulate the CPU for proper guest OS execution. Memory Manager - The memory manager allocates the memory for each guest OS and is responsible for protecting the integrity and confidentiality of the information stored and processed by each of the co-existing guests. Protecting the integrity and confidentiality of each guest OS is extremely important for solutions that require security domain separation between guest OSs. The memory manager also controls shared memory structures for intercommunication between guest OSs, bare-metal applications, virtual devices, para-virtual devices, and physical devices. The memory manager s role in fully protecting guest OS memory from unauthorized access is broken into two categories: protecting unauthorized access to guest OS memory from coexisting guest OSs, and protecting guest OS memory from external I/O devices. The memory manager is able to protect against unauthorized access requests originated from guest OSs, however the memory manager must rely on Intel s hardware VT-d to explicitly control the boundaries of memory read and write requests originating from external devices. In addition to VT-d, the memory manager benefits from Intel s recent extended page table (EPT) hardware feature. Using EPT, guest OSs are able to directly manage their local memory page tables, no longer requiring assistance from the hypervisor which removes a significant bottleneck in guest OS memory access performance. Hypercall API - The Hypercall API is a privileged hypervisor interface utilized by the virtualization framework to provide guest OSs and bare-metal applications a facility for inter-guest communication, guest OS management, audit, and maintenance management. Interrupt Handler - The interrupt handler manages interrupt signal routing for efficient asymmetric communication channels 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 the Intel TXT feature set during the startup initialization process. Prior to loading the hypervisor, the hardware trusted platform module (TPM) is controlled via Intel s TXT instruction set to validate the Type Zero hypervisor is not compromised and is ready to enter full operational state. 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. LynxSecure s Type Zero hypervisor core design satisfies the size, efficiency, determinism, security, and reliability requirements of embedded mission-critical systems, while leaving the need for flexibility up to the higher level virtualization framework. By selecting a minimum set of functionality and utilizing Intel s hardware assistance, 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. 28 Engineers Guide to Embedded Linux and Android 2013
Summary Virtualization is a powerful technology that is changing the way organizations of all shapes and sizes do business through the greatly offered cost saving and security benefits. Up until now, however, virtualization has been confined to IT server and PC environments leaving a world of untapped opportunity for technology producers to explore. With the help from advancements in hardware assisted virtualization features from chip vendors like Intel, combined with the vision from embedded RTOS company, LynuxWorks, the Type Zero hypervisor emerges to give the embedded community the tools they need to deliver the benefits of virtualization beyond the realm of enterprise IT, into new industries with the most demanding security and reliability requirements. Arun Subbarao is Vice President of Engineering at LynuxWorks, responsible for the development of security, virtualization and operatingsystem products, as well as consulting services. He has 20 years of experience in the software industry working on security, virtualization, operating systems and networking technologies. In this role, he spearheaded the development of the award-winning LynxSecure separation kernel and hypervisor product as well as software innovation in the areas of security, safety and virtualization. He has also been a panelist and presenter at several industry conferences. He holds a BS in Computer Science from India, MS in Computer Science from SUNY Albany and an MBA from Santa Clara University. Will Keegan is a technical specialist at LynuxWorks, Inc., where he upholds a strategic role in supporting sales, marketing, and engineering. He has over 7 years of experience working in enterprise IT, safety-critical, and security-critical industries. He previously served as a product engineer for OIS where he worked on the development and marketing of various high assurance cryptographic network and embedded middleware products. Will also served as a network engineer for USAA, building and maintaining world class data centers. He graduated from the University of Texas at Austin in 2005, earning a B.S. in Computer Science. www.eecatalog.com/embeddedlinux 29