Device Virtualization in a Partitioned System: the OVERSEE Approach

Device Virtualization in a Partitioned System: the OVERSEE Approach M. Masmano, S. Peiró,J. Sánchez , J. Simó,A. Crespo Instituto de Automatica e Informatica Industrial Universidad Politecnica de Valencia, Spain fmmasmano,speiro,jsanchez,jsimo,[email protected] Abstract This paper presents a solution for device virtualization on a hypervisor driven partitioned system. The approach is in the scope of the OVERSEE project, which is the Open Secure Vehicular Plat- form. This software platform is intended to act as a single access point to vehicle networks. Such system will support different types of partitions, from real time constrained to non-trusted user partitions running general purpose operating systems. On this scenario, the partitions compete for access to hardware resources, specially for the system peripherals. Mostly oriented to non real-time partitions, this paper focuses on the design of a mechanism for device virtualization based on the Linux standard Virtio. As on real time approaches, the architecture is based on the use of an I/O server, a partition which has direct access to devices and Figure 1: Oversee architecture overview. handles the requests from other partitions to access peripherals. OVERSEE, for short) is intended to serve as a single access point to vehicle networks. It will pro- 1 Introduction vide a protected, standarized in-vehicle runtime environment and on-board access and communi- Partitioned software architectures can represent cation point. Applications for this platform in- the future of secure systems. They have evolved clude, between others, positioning systems, stolen to fulfil security and avionics requirements where vehicle tracking, traffic information, web browsing, predictability is extremely important. The sepa- etc. Ultimately, OVERSEE aims to create an open ration kernel proposed in [1] established a combi- software platform for which everyone can develop nation of hardware and software to allow multiple applications and download them. Of course, this functions to be performed on a common set of phys- platform must ensure that the applications cannot ical resources without interference. It is precisely harm each other and, especially, internal in-vehicle XtratuM the selected kernel to serve as the base ex- software applications. The heterogeneous nature of ecution environment for the OVERSEE partitioned the applications being executed under OVERSEE system. makes XtratuM system partitioning the best way The Open Vehicular Secure Platform [2] (or to isolate and protect applications from each other. 1 Finally, for this system, the chosen target hardware The design of XtratuM has tried to apply the phi- is the Intel Atom architecture, which is the Intel ar- losophy of the ARINC-653 standard [3] (despite chitecture for embedded systems. not being ARINC-653 compliant). This standard XtratuM ensures temporal and spatial isolation is used to achieve strong isolation between running of the applications that run over it. This applica- guests, so it has rigid policies about resource man- tions may vary from bare-C applications to entire agement. operating systems as, for example, Linux. Each On the time domain, XtratuM allocates CPU to of this applications is refered to as a partition or partitions following a plan which is defined at con- guest. On this paper, we will pay special atten- figuration time, i.e., it uses a cyclic scheduler. Dy- tion to Linux guests. The use of Linux as a guest namic schedulers are avoided when systems under to run general purpose applications is very interest- control are critical real-time. This ensures a pre- ing; thanks to the developement efforts made by the dictable behaviour as well as scheduler robustness open source community, Linux offers a vast variety against system temporary overloads. On the other of device drivers, as well as many other software hand, this scheme narrows maximum bandwidth of mechanisms (i.e. a TCP/IP stack), which reduce non real-time guests, which may need more relaxed implementation burden of software projects. scheduling policies. As explanied on section4, im- With the expansion of hypervisor technology, plementation of virtual devices have to take into Linux has begun to host extensions for system vir- account this fact in order to optimize throughput. tualization. Linux kernel supports at least 8 dis- Besides CPU management, XtratuM isolates tinct virtualization systems, being Xen [4], KVM spatially the partitions by defining a set of accessi- [6] or Lguest [5] among them, without taking into ble physical memory areas for each one. Also, phys- account the relatively new XtratuM hypervisor. ical memory areas can be defined as shared, thus With such large variety of virtualization systems, being accessible by several guests. This is precisely a new standard has appeared to fulfil the needs the chosen mechanism for driver virtualization. of device virtualization, which until now had to XtratuM uses para-virtualization, so hardware be implemented by each hypervisor. This stan- access is wrapped by means of hypercalls. There- dard is known as Virtio [8]: \a series of efficient fore, guests have to be modified so that they do well-mantained Linux drivers which can be adapted not directly access hardware but they call the hy- for various hypervisor implementations". As will percalls. Along with the virtualization technolo- be explained on section , the special features of gies, Linux kernel has evolved to offer built-in para- XtratuM needs Virtio to be modified in a differ- virtualization mechanisms. This has greatly simpli- ent way than other virtualization solutions. fied the task of porting Linux to XtratuM architec- The remaining of this document is structured as ture while enhancing forward compatibility. follows. Section2 introduces the XtratuM hypervisor and the Linux virtualization over it. Section3 2.1 Virtual devices presents the approach of the Virtio specification to provide device virtualization. Section4 describes Intel x86 architecture offers a separate address the requirements imposed by Virtio and how to space for accessing peripherals. This address space fulfill them under the XtratuM hypervisor. Sec- is composed by ports and can be mapped so that tion 4.1 presents describes the implementation of they appear in the physical memory address space. the Virtio support on the Linux guests running on Partitions can be given permissions to use some of the XtratuM hypervisor. these ports in order to have direct access to some peripheral. When talking about system input and output 2 XtratuM and Linux Virtu- (I/O), there are two paradigms for device driver access. The first approach is to leave device man- alization agement to the hypervisor. However, this is not a good approach as, for each device, a driver would XtratuM is a bare-metal hypervisor with extended have to be implemented at hypervisor level and, capabilities for highly critical real-time systems. also, XtratuM complexity would grow too much. 2 Thus, only a few simple drivers (console, UART) I/O partition, is in charge of offering a suitable have been implemented inside XtratuM. The sec- device abstraction closely resembling a typical ond approach is to leave device driver implemen- hardware device. tation to partitions themselves. This approach is more flexible as we can use device drivers already 2. The Virtio device drivers 3.2 used by the Linux implemented, like those included in the Linux ker- guest partitions are in charge of managing and nel. For this method to work, guests are given per- accessing the Virtio devices offered by the I/O missions to access some I/O ports on the configu- partition. ration step. 3. The Virtio transport mechanism 4.2, is in By leaving devices to partition control, new prob- charge of providing an efficient mechanism for lems arise, related to device management. If a de- connecting both the Virtio devices and drivers. vice on the system is dedicated so that it is mapped to at most one partition, there is no problem. Nev- ertheless, when there is the need for sharing devices 3.1 Virtio Devices between several guests, special management has to The Virtio device model is designed with PCI de- be applied. Operating system device drivers con- vices virtualization in mind, that is Virtio devices trol mutual exclusion of the threads accessing the are very similar in several aspects to PCI devices. same device, so that input/output transactions are This similarity can be further explained by exam- atomic, thus ensuring a correct operation. How- ining the typical operations performed on devices: ever, there are no mutual exclusion mechanisms on XtratuM, as this would break partition isolation 1. Device configuration: is performed on a (partitions may control the way other partitions are ”configuration memory space" associated to a executed). Virtio device that contains: IRQ, Status, De- A proper solution to the device virtualization vice features and Data descriptors information, problem is to create a separate secure I/O partition as it would be found on a PCI device. with exclusive access to devices. This partition vir- tualizes these devices for each of the user partitions. 2. Device activity notification: is performed With these model, the virtual devices on the user using the extended IRQ (Interrupts ReQuests) partition side will send requests to the I/O partition mechanism provided by the hypervisor, used for accessing real devices. Underneath the virtual by the Virtio device to requests attention to devices, a software layer will provide the necessary the guest. mechanisms for transporting the requests, as the 3. Device operations: common device opera- partitions are spatially isolated. Figures1 and3 tions as device data transfers are performed depict the model with different detail level. on buffers allocated by the guest and provided to the device (I/O Partition) which resembles 3 Virtio programming of DMA data transfers. The Virtio standard for Virtual device I/O [7] pro- 3.2 Virtio Drivers vides an stable and efficient mechanism for device virtualization.

Load more