XtratuM for LEON3: an Open Source Hypervisor for High Integrity Systems Miguel Masmano, Ismael Ripoll, Alfons Crespo, Salvador Peiró
To cite this version:
Miguel Masmano, Ismael Ripoll, Alfons Crespo, Salvador Peiró. XtratuM for LEON3: an Open Source Hypervisor for High Integrity Systems. ERTS2 2010, Embedded Real Time Software & Systems, May 2010, Toulouse, France. hal-02267841
HAL Id: hal-02267841 https://hal.archives-ouvertes.fr/hal-02267841 Submitted on 19 Aug 2019
HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. XtratuM for LEON3: an Open Source Hypervisor for High Integrity Systems
Miguel Masmano, Ismael Ripoll, Alfons Crespo and Salvador Peiro
Instituto de Informatica´ Industrial. Universidad Politecnica´ de Valencia. Camino de Vera s/n, 46022 Valencia, Spain {mmasmano, iripoll, acrespo, speiro}@ai2.upv.es
Abstract: The growing complexity of the payload foundation adopted for the so-called MILS architec- on-board satellite software experimented during the ture is a separation kernel. Also, the ARINC-653 [3] last years has raised the interest of the CNES and standard specifies the baseline operating environ- the ESA to explore the possibility of using a TSP- ment for application software used within Integrated based architecture as base of the payload software Modular Avionics (IMA), based on a partitioned ar- of its new generation satellites. Such a solution can chitecture. Although not explicitly stated in the stan- be implemented by using different approaches: virtu- dard, it was developed considering that the under- alization, µ-kernels, separation kernels. lying technology used to implement the partitions is XtratuM is an open-source hypervisor targeted the separation kernel. high-critical real-time systems which has been se- A virtual machine (VM) is a software implemen- lected by ESA to be ported to the LEON3 processor tation of an architecture that executes programs like in the frame of the Securely Partitioning Spacecraft a real machine. In addition, the low overhead, fairly Computing Resources project. This paper addresses closed to that of the native hardware, turns this solu- the current status of the XtratuM open-source hyper- tion into a candidate to build partitioned systems. visor for LEON3. In addition an early evaluation of it is also sketched. The European space sector, CNES firstly with the LVCUGEN project, and later, ESA with the Se- curely Partitioning Spacecraft Computing Resources Keywords: TSP, virtualization, hypervisor, high- project are currently assessing the feasibility and integrity systems, real-time. benefits of a TSP-based solution for payload on- board satellite software based on virtualization or re- 1 Introduction lated technologies (see for a description of the archi- tecture proposed by ESA [4]). Both, the advances in the processing power and The LVCUGEN project started by the end of the increment in resources achieved during the last 2008 with the aim of developing a highly reusable decade have raised two important consequences and configurable TSP-based architecture for on- in the payload on-board satellite software. On the board payload software. As base of this architec- one hand, it has permitted to turn the payload on- ture, the XtratuM hypervisor [5,6] was selected to board satellite software from simple data process- be adapted to the AT697 (LEON2) processor, which ing, mainly responsible for only formatting and trans- lacks of a MMU. This feature forced XtratuM to im- ferring the data to the ground into complex and au- plement inter-partition read-only protection instead tonomous data processing software. Despite of in- of the desired full-spatial isolation. creasing notoriously the development and mainte- nance cost. On the other hand, multiple applica- The Securely Partitioning Spacecraft Computing tions are able to run in a single processor, reducing Resources project started by the middle of 2009 to the quantity of hardware necessary to build a satel- build a TSP-based architecture for on-board payload lite, and as a consequence its final cost. To facili- software to be tested on the ESA’s Eagle-Eye simu- tate such a model, the execution time and memory lator. XtratuM was selected as the open source alter- space of each application must be protected from the native to be adapted to the GR-CPCI-XC4V (LEON3 rest of the applications present in the system. Par- processor) processor, with MMU. titioned software architecture have evolved to pro- This paper describes the experiences of adapt- vide such security. The separation kernel proposed ing XtratuM to the LEON3 processor. This processor, in [1] established a combination of hardware and unlike its predecessor, includes a MMU enabling, software to allow multiple functions to be performed thus, XtratuM to eventually implement full spatial iso- on a common set of physical resources without in- lation. Furthermore, it describes the XEF image for- terface. The MILS [2] initiative is a joint research ef- mat, a partition image format introduced in this ver- fort between academia, industry, and government to sion of XtratuM to improve the management of parti- develop and implement a high assurance, real-time tions during the deployment phase. An initial evalua- architecture for embedded systems. The technical tion of the most significant metrics is also provided. 2 XtratuM hypervisor – Health monitoring capabilities. – Two security levels: standard and system parti- XtratuM 1.x was initially conceived as an improved tions. replacement of RTLinux’s virtualization layer [7]. There was two design goal: avoid the legal problems 2.1 Architecture and design related with the patent that protected the exact virtu- alization mechanism used by RTLinux, and avoid its XtratuM has been implemented following a mono- technical limitations. XtratuM 1.x was designed as a lithic approach, running all its services in the proces- Linux Kernel Module. Once loaded (as a Linux mod- sor highest-privileged mode and in a single memory ule), it takes over the essential hardware devices (ba- space; all the services are directly reachable from sically interrupts and timers) to enable the concurrent any part of the hypervisor. execution of two or more OSes1, being one of them a real-time OS. The other hardware devices, as well as the boot sequence, were left to be managed by Linux. This approach let us speed up the implemen- tation of a first working prototype, however, it was not completely satisfactory: XtratuM and Linux still shared the same memory area, and both run in su- pervisor mode (Ring level 0). After this first experience, the second version (XtratuM 2.0) was redesigned to be independent of Linux. In the rest of this paper, the term XtratuM will refer to this second version or above. This version is being used in the project LVCUGEN [8], whose goal Fig. 1. XtratuM architecture. is to build a TSP-based solution for payload on-board software (for the aerospace industry), highly generic Figure 1 sketches the complete system architec- and reusable. The TSP-based architecture has been ture. identified as the best solution to ease and secure The main components of this architecture are: reuse, enabling a strong decoupling of the generic features to be developed, validated and maintained 1. Hypervisor: XtratuM is in charge of virtualization in mission specific data processing. services to partitions. It is executed in supervisor XtratuM is, according to the IBM categorisa- processor mode and virtualizes cpu, memory, in- tion [9], a type 1 (bare-metal) hypervisor that uses terrupts and some specific peripherals. The in- para-virtualization. The para-virtualized operations ternal XtratuM architecture includes: physical/vir- are as close to the native hardware as possible. tual memory management, scheduling (fixed Therefore, porting an operating system that already cyclic scheduler), interrupt management, clock works on the native system is a simple task: just and timers management, inter-partition commu- to replace some parts of the operating system HAL nication (ARINC 653-1 based communication (Hardware Abstraction Layer) with the corresponding model) and health monitoring. hypercalls2. 2. Partitions: a partition is an execution environ- XtratuM was designed to meet high integrity sys- ment managed by the hypervisor which uses the tem requirements. Its most relevant features are: virtualized services. Each partition consist of one or more concurrent processes (implemented by – Bare-metal hypervisor. the operating system of each partition), sharing – Implements para-virtualisation techniques. access to processor resources based on the re- – Designed for embedded systems: low footprint, quirements of the application. The partition code some devices can be directly managed by a des- can be: ignated partition. – Strong temporal isolation: fixed cyclic scheduler. – An application compiled to be executed on a bare – Strong spatial isolation: all partitions are exe- machine using directly the services of XtratuM. cuted in processor user mode, and do not share Note that XtratuM provides an execution environ- memory. ment that is not exactly like the original hardware – Fine grain hardware resource allocation via a but somewhat more “friendly” (console services, XML configuration file. easy to use timers, etc.) – Robust communication mechanisms (ARINC – An operating system (and RTOS and a general 653-1 based sampling and queueing ports). purpose one) and its applications. 1 RTLinux virtualiser only is able to run Linux and one real-time OS. 2 Hypercall is the name of the hypervisor services. It is based on the term system call which refers to the services of an operating system Partition code need to be virtualized to be ex- from sharing sections between partitions. For ex- ecuted on top of the hypervisor. Depending on the ample if two partitions run Linux, then two copies type of execution environment, the virtualization im- of the Linux code must be copied in memory. plications in each case can be summarised as:
– Bare applications: the application has to be virtu- Furthermore, during the evaluation of XtratuM alized by using the services provided by XtratuM. 2.2.x were raised several suggestions about the bi- The application is designed to run directly on the nary format used by the image of XtratuM and the hardware and it has to be aware of it. partitions: – Operating system application: when the applica- tion runs on top of a (real-time) operating sys- 1. A raw binary image could be corrupted without tem, it uses the services provided by the oper- being detected by the bootloader. ating system and does not need to be adapted. 2. An user payload embedded in the partition’s But the operating system has to deal with virtu- header is missed. This payload shall be used by alization (ported to be XtratuM aware). the partition’s supplier to insert tracking informa- Two different type of partitions can be defined: tion/versions/etc. system and user. A system partition is able to 3. The binary image was not processed in any change the execution state of a user partition (sus- way, techniques such as compression, digestion, pend / resume / halt / reset) or the whole system. cryptography could be beneficially applied.
2.2 LEON2 version limitations 3 XtratuM for LEON3 processor The current version of XtratuM for LEON2 processor has a series of limitations: the SPARC architecture does not provide any kind of virtualisation support. It The LEON3, successor of the LEON2 processor, is implements the classical two privilege levels: super- a synthesisable VHDL model of a 32-bit processor visor and user; in order to guarantee isolation, par- compliant with the SPARC-v8 architecture. Designed tition’s code has to be executed in user mode, only by Aeroflex Gaisler, it has been released under the XtratuM can be executed in supervisor mode. This GNU GPL licence. In addition to all the features requirement imposes limitations to those operating already presented on the LEON2 processor, this systems which require both modes. version of the processor includes support for SMP Additionally, the LEON2 processor lacks of a systems, and a Memory Management Unit (MMU) Memory Management Unit (MMU) which prevents (SPARC reference MMU with configurable TLB). XtratuM to implement: By using this MMU, XtratuM is able to: – Full spatial isolation. Nevertheless, a kind of partial spatial isolation is provided (through the – Implement full spatial isolation. No partition is LEON2’s memory write protection registers: a longer able to read from memory areas belong- partition cannot overwrite memory which be- ing to other partitions. longs to others, however, it is still able to read – Support inter-partition shared memory: two or from any memory address. In addition, the trap more partitions are able to share memory ar- raised by a partition when it is trying to write in eas (specified in the XML configuration), per- write-protected area is received several cycles mitting to design and implement more efficient later (unlike MMU traps which is synchronous), inter-partition communication mechanisms. And, being, thus, rather difficult to find out which was in addition, code sections could be shared by the offending instruction. And it is even still much partitions avoiding duplicity of code. more difficult to try to sort out the situation with- out killing the offending partition. – Shared memory between partitions. The use of The adaptation of XtratuM to this processor has shared memory could be used to implement consisted in virtualizing the MMU: each partition has efficient, zero-copy inter-partition communica- its own virtual memory map where the top area is re- tion mechanisms. Currently, XtratuM only imple- served for XtratuM. XtratuM itself is mapped on this ments queuing and sampling ports, both of them area with supervisor permissions. The rest is filled requiring two copies of data (sender → Xtra- according to the definition of the partition (XML con- tuM → receiver). The use of shared memory figuration file). In addition, a partition has the capabil- should enable the implementation of more effi- ity of defining new memory maps and updating them. cient inter-partition communication. Besides, the In addition, a set of new hypercalls is provided, lack of shared memory also prevents XtratuM enabling a partition to manage its memory maps. it has to define the new memory map by registering a set of pages from its own memory. Once registered, these pages become read-only, so subsequent up- dates must be validated by XtratuM.
3.2 Changes in the XtratuM core
Three fundamental changes have been performed in the XtratuM core:
– XtratuM implements a new module called virtual memory manager which is in charge of manag- ing the virtual maps, and is able to create/release Fig. 2. Memory map of two partitions. them and map/unmap physical pages. – As mentioned above, XtratuM implements three Figure 2 shows the two virtual memory maps new hypercalls: XM set page type() which per- build by XtratuM as a result of the following XML con- mits a partition to register new memory maps, figuration file: XM update page32() which allows a partition to
7 References 8 Glossary
[1] John Rushby. Design and verification of secure sys- CNES Centre National d’Etudes´ Spatiales tems. volume 15, pages 12–21, Pacific Grove, Cali- fornia, dec 1981. ESA European Space Agency [2] Jim Alves-Foss, Paul W. Oman, Carol Taylor, and IMA Integrated Modular Avionics Scott Harrison. The mils architecture for high- LZSS Lempel-Ziv-Storer-Szymanski assurance embedded systems. IJES, 2(3/4):239– MILS Multiple Independent Levels of Security and 247, 2006. Safety [3] Avionics Application Software Standard Interface MMU Memory Management Unit (ARINC-653), March 1996. Airlines Electronic Engi- TLB Table Look-aside Buffer neering Committee. TSP Time and Space Partitioning