Virtual Open Systems Scientific Publications
The 13th IEEE International Symposium on Industrial Embedded Systems (SIES 2018), Graz, Austria.
Contributed slides presentation
The slides presented at this conference are made publicly available.
Shared memory, mixed-critical virtualization, Network, Virtualization, VOSYSmonitor, VOSYSVirtualNet.
This work was supported by the dRedBoX project. This project has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No. 687632. This work reflects only the authors' view and the European Commission is not responsible for any use that may be made of the information it contains.
Integrating multiple subsystems with different levels of criticality is a well established concept in the automotive domain. To ensure proper temporal and spatial isolation, a highly privileged software component is installed to orchestrate the subsystems. VOSYSmonitor is such a solution, it enables the co-execution of two operating systems on a single System on Chip - A rich operating system, such as Linux, along with a safety critical operating system, fully isolated from each other using ARM TrustZone. But if we take a closer look at specific automotive scenarios (e.g., "displaying warning signs"), reveals that an interaction of the two operating systems might be desirable. In this paper we address this challenge. We present the implementation of a low-latency inter-world network channel. It is built around already existing primitives in both worlds, only implementing the physical layer of the network channel. This ensures a low complexity, meaning only minor modifications have to be made to both operating systems. To prove the feasibility of our design, we built a full prototype that enables a network communication between the two operating systems, while ensuring a proper encapsulation of the safety critical operating system. To validate low reaction times, the design is evaluated with respect to network latency. To complement the measurements, we also performed a number of bandwidth measurements. Finally, we thoroughly discuss potential threat scenarios arising from the network link and how they can be addressed with appropriate countermeasures.
The Automotive domain is currently undergoing a paradigm shift. Manufacturers alter their system architectures from having a single processing unit for individual subsystems, towards the integration of multiple subsystems with a full spectrum of different safety requirements. In-Vehicle Infotainment systems for example, reside on the very low end of this criticality spectrum and the car control unit resides on the very high end. All are integrated on a single Electronic Control Unit (ECU), by capitalizing on the performance of powerful heterogeneous multi core platforms. But, these automotive mixed-criticality systems  pose new challenges on the system software -. To accommodate the increased complexity, automotive manufacturers leverage alternative software architectures to execute several software stacks concurrently. In this context, a highly privileged orchestrating entity provides full spatial and temporal isolation of the different software components. virtualization plays a key role in this trend, but off-the-shelf virtualization solutions (e.g. Xen , KVM , Hyper-V , etc.) are more trimmed towards performance rather than the maximum level of isolation (cf. -). Therefore, they do not provide the level of temporal and spatial isolation required by the automotive domain. Also, with regards to certification (e.g. ISO 26262 ) these conventional solutions are lacking behind for the above reasons. Instead, automotive manufacturers use highly specialized certified kernels - to fulfill the demanded safety requirements. These solutions are very similar in their design (e.g., leveraging hardware processor extensions such as ARM TrustZone ,  or ARM VE ), but have more predictable timing characteristics, than their off-the-shelf counter parts. Running on top of these privileged components, the General Purpose Operating System (GPOS) Linux found a widespread adoption due to its versatility and ability to produce a rich user interface for the In-Vehicle Infotainment (IVI) system. It is accompanied by a Special-Purpose Operating System (SPOS), which handles mission-critical tasks (e.g., displaying speed, engine torque and/or warning signs). In this context, both components serve a dedicated purpose, without the perceived need of interaction. However, a closer look at specific scenarios, reveals that an interaction between systems is required. Then, the strict spatial isolation - initially one of the key requirements of the said system architecture - must be thinned. In this context, establishing a network link between the components raises two questions. First, can the latency requirements from the critical application, be fulfilled? Second, can the integrity of the critical application be upheld, while efficiently exchanging information with the non-critical system? In this paper these open research questions are addressed. We present the design of an architecture that enables a low-latency network link between SPOS and GPOS, taking safety and security requirements into account. Its feasibility is demonstrated with a full prototype implementation called VOSYSVirtualNet. The prototype is based on a highly privileged firmware called VOSYSmonitor , that runs in the monitor mode of modern ARM-based System-on-Chips (SoCs). The communicating endpoints of VOSYSVirtualNet are a Linux running in the non-secure world and a FreeRTOS running in the secure world. We verify the low-latency with a number of benchmarks and put the results into context by comparing them against a reference system. Finally, the security concerns are addressed by referring to the safety and security aspects that are included in the design of VOSYSVirtualNet. The rest of the paper is structured as follows. Section II provides preliminaries and background information. The architecture of VOSYSVirtualNet is presented in Section III and evaluated in Section IV. Then, security implications of our design are discussed in Section V, while related work is presented in Section VI. Finally, we conclude and present future work in Section VII and Section VIII, respectively.
Access the full content of this publication
Login or register to access full information