But what are the challenges?
In the case of a Cockpit, the consolidated Operating Systems (OS) have different constraints. For example, the Digital Cluster requires the display to react in a limited amount of time, while an infotainment system requires it to execute a large set of applications (Web browser, Air conditioning, Radio and Video, Android or iPhone applications). Basically, the Cluster is safety critical and is required to be predictable while the Infotainment needs to be open and secure.
Hypervisor makes sure that the constraints of execution of critical Operating Systems are respected. For instance, a Digital Cluster must display some critical information in a limited time and do this whatever the activity is running on the other system. Here, the handling of resources is a key aspect and we will see at how Hypervisor handles them below. Consolidating systems also typically requires the setup of communication links between Virtual Machines (VM) to share hardware peripherals. Therefore, a key requirement is to provide a safe, flexible and controlled communication means.
Today, automotive SoCs are embedding more and more hardware parts dedicated to automotive safety. Thus, the hypervisor must ensure that low-criticality systems, generally connected to external networks, don’t jeopardize the integrity of these security systems.
Automotive Grade Hypervisor:
Traditional Hypervisors allocate resources to operate (Cpus, memory) dynamically. The benefit is their flexibility, but the drawback is that allocation may fail, which might compromise the safety of the system if they fail what was created by a critical VM.
Securing predictability is a key goal of the HARMAN Hypervisor. Hypervisor provisions Virtual Machine and Hypervisor resources (memory, IO devices, second stage page table) at boot time. This guarantees that Hypervisor and Virtual Machines don’t fail to allocate a resource at a later time.
The resources partitioning is defined in device trees. Hypervisor verifies that peripherals or memory cannot be assigned to multiple guests. There are some ways to share hardware and memory, but this must be made explicit in the configuration. In addition, a configuration checker can be run to verify that it is consistent with the resource partitioning specification.
Spatial Isolation:
Hypervisor enforces the resources partitioning, so by default a Guest Operating System cannot access memory and peripherals assigned to another “like” system. Virtual Machine Isolation is achieved by using both Second Stage MMU and System MMU (or equivalent).
Second stage MMU prevents a Guest Operating System to access the memory of another “like” system.
Interactions between a Guest Operating system and the TEE (trusted zone) are intercepted by the Hypervisor, a plugin that allows a system designer to implement various policies including a forwarding and/or filtering policy.
Temporal Isolation:
CPUs can be allocated in a very flexible way. Virtual Machines can be configured to have a set of fixed or floating CPUs. In any case, Hypervisor preserves the real-time behavior of real-time guest OSes by imposing a bounded and very minimal overhead on their execution. In addition the Hypervisor’s scheduling policies guarantee that high priority real-time guest OSes always take precedence over non-real-time guest OSes.
Inter-VM communication:
Although Hypervisor is all about isolation, providing means of inter-VM communication is a must. So fancy features like shared memory and cross-interrupts are provided. Nevertheless, the mechanism of communication shall never jeopardize safety of the product. Hypervisor provides a selection of features aimed at controlling malicious use of inter-VM communication mechanisms. Examples include:
Observability of the system:
Error detection is a key requirement for both security and safety. Hypervisor provides a mechanism to detect fault such as one with hardware and non-respecting of real-time constraints. After detection, these faults can be sent to a controller Virtual Machine which may implement a degraded policy. For example, it might decide to stop the low priority VMs.
More generally, this controlling VM might access other VMs by using introspection Hypervisor API (allowing to read or write memory and register context of a VM). These introspection APIs may be used for implementing an Intrusion Detection System.
Policed Inter-VM communication, Spatial and temporal isolation, resource predictability, system observability are all key concepts for satisfying the requirements of the automotive market. Harman Hypervisor implements those concepts to ensure the safety and security of the digital cockpit.
The HARMAN Device Virtualization is based on Type-1 virtualization by design. This enables the required VM isolation and the strongest possible safety & security levels, while guaranteeing optimal system performance for virtualized automotive domains, such as a Digital Cockpit.
HARMAN’s unique solution is both OS-agnostic and SoC-agnostic, providing auto OEMs freedom of choice and control when it comes to selecting suppliers/architectures. De facto, these intrinsic product properties increase their bargaining power and significantly reduce the total cost of ownership. The HARMAN Device Virtualization solution is one of the only Automotive-grade (and ASIL-certified) Type-1 Hypervisor deployed in large volumes around the globe at leading Automotive OEMs.
