PORTING OPERATING SYSTEMS TO RUN IN XEN VIRTUAL MACHINES

Semiconductor manufacturers are creating new System on Chips that allow embedded system developers to design consolidated architectures to reduce size, weight, power, and cost. However, combining software functions onto a single computing resource creates safety and security concerns due to reduced fault containment and increased coupling between software components. Safety and security-conscious industries use various software separation solutions to isolate software functions logically in order to achieve a comparable level of decoupling and fault containment that distributed/federated systems enjoy as a by-product of their system architecture. This paper will assess the suitability of common separation solutions for use in embedded systems and explain our preference for Xen, an open source Type I hypervisor. This paper will also examine reasons for porting operating systems to run in virtual machines, also known as paravirtualization, and evaluate how certain properties of operating systems can impact this task. Finally, we will conclude with lessons learned from our efforts paravirtualizing a number of operating systems. INTRODUCTION A System on Chip (SoC) is a powerful and versatile microchip that incorporates previously separate electronic components into a single integrated circuit. SoCs typically include several processing cores, often with multiple clusters of heterogeneous processors, along with dedicated I/O controllers, memory blocks, timers, voltage/power regulators, memory bus controllers, and various other peripherals. The available processing power, availability of I/O, and level of integration makes SoCs an ideal target platform onto which numerous software functions (SWFs) can be consolidated, enabling an overall reduction of size, weight, power, and cost – a key goal for many ground vehicle systems. However, combining software functions on a common computing platform creates safety and security concerns. In non-consolidated systems (also known as distributed or federated), each discrete microprocessor provides a natural zone of fault containment as a by-product of the hardware architecture. Distributed and federated architectures also impose loose coupling between software functions executing on different microprocessors since interactions between them must be facilitated by some manner of external communication. These benefits of fault containment and enforced loose coupling can be lost when software Proceedings of the 2017 Ground Vehicle Systems Engineering and Technology Symposium (GVSETS) Porting Operating Systems to Run in Xen Virtual Machines, Roach. Page 2 of 19 SWF-1 SWF-2 SWF-N HW functions are consolidated onto a common SoC, which is a concern for industries where safety and security are of paramount importance, such as aviation and defense. In this paper, we review the history of separation solutions and the need for them in modern systems. Next, we assess software methods used in various industries to logically isolate, or partition, software functions in order to achieve increased fault containment and loose coupling, enumerating the benefits and limitations of each method. We make the case for using virtualization provided by a Type I hypervisor as a separation solution well suited for most embedded systems with explicit safety or security requirements. We conclude the section explaining our preference for the Xen Project hypervisor as a separation solution for embedded projects. The next section of the paper focuses on the operating system (OS) running in a virtual machine (VM) created by the hypervisor. We list typical reasons for porting an operating system to run in a virtual machine, also known as paravirtualizing. Then we discuss properties of potential operating systems and how they may be impacted by virtualization. We end that section with a description of three licensing models – permissive, copyleft, and proprietary – and their implications in order to highlight how licensing can affect the decision to paravirtualize an operating system. In the final section of this paper we describe our experiences and share lessons learned from paravirtualizing the following operating systems: the Xilinx standalone library, Micrium μC/OS-III, Real Time Engineers FreeRTOS, and Wind River VxWorks 7.0. While our experiences are with paravirtualizing to a specific virtual environment, VMs created by Xen, these lessons learned can be generalized and applied to paravirtualization efforts for other hypervisors. THE NEED FOR SEPARATION IN MODERN SYSTEMS Moore’s Law, the doubling of components on an integrated circuit every two years, coupled with market forces ultimately drives the need for separation in modern systems. As chips become more powerful, system developers are presented with the challenge of effectively using them. The processing requirements for a single software function do not follow the same exponential growth that processor performance enjoys. It is natural to conclude that system developers would want to consolidate existing SWFs in the system onto a single chip in order to avoid wasting any available processing power. It is also natural to conclude that developers would also want to take advantage of any remaining processing power to add new software functions to support new features to provide market advantage over competitors. The days of running a single SWF on a processor are over; it is not economical nor sustainable for the vast majority of business cases. As a single hardware resource becomes responsible for hosting multiple SWFs, separation solutions become necessary to restrict unfettered growth in complexity and to mitigate the impacts of concurrent execution of those software functions. Without separation solutions, the number of possible interactions between different pairs of software functions grows geometrically with the number of functions consolidated, dramatically increasing the effort to analyze and describe the interactions and side effects. Separation solutions are useful for providing fault containment by preventing erroneous or malicious behavior in one software function, or application, from affecting another. Early literature [1] identifies the need for spatial separation for fault containment, Figure 1: Separation of SWFs Proceedings of the 2017 Ground Vehicle Systems Engineering and Technology Symposium (GVSETS) Porting Operating Systems to Run in Xen Virtual Machines, Roach. Page 3 of 19 which is commonly achieved by restricting the memory locations a SWF can access, thus protecting the data and instructions of the other SWFs in a consolidated system. ARINC 651 also identifies the need for temporal separation, later expanded upon in ARINC 653, where a SWF in one partition cannot affect the execution time or time to access a resource of a SWF in another partition [2]. This goal has become more difficult to achieve with increases in hardware complexity. Separation solutions are also useful for enforcing greater decoupling between software components. Coupling between software components leads to various issues with development, integration, maintenance, and future migrations. This is because coupling leads to complex dependencies between software components, often implicit or unknown, such that a change to, or addition of, a software component often has a wide-reaching and unexpected ripple effect throughout the system. Separation solutions can be used to enforce strong decoupling where any dependencies between software functions are made explicit, making it easier to understand and eliminate unintended or unexpected interactions. Strong decoupling also allows greater freedom to develop software functions in parallel with a higher confidence that the different pieces will not interfere with one another when integrated together. These properties allow development and integration of SWFs to different safety and security criticalities. This can be a big cost savings as lower criticality SWFs do not have to be developed with the same design assurances as the higher criticality SWFs. Strong decoupling also reduces the effort of re-using existing software and the risk that adding new software functions will destabilize the system, resulting in an overall reduction of non-recurring engineering costs. Table 1: Benefits of Separation Summary of Separation Benefits Simplifies management of multiple SWF on a hardware target  Increases utilization of hardware resources Improves containment