The hypervisor strictly separates the virtual machines and their OSs from the hardware In/Outs, Fig.3. Any request of a virtual machine for hardware access has to be approved by the hypervisor. This equally applies to trusted automotive OSs and to partially trusted OSs. If several virtual machines share hardware, they have to ask permission to do so at the shared services. Even if the request is granted, it will be the hypervisor which then accesses the source OS and provide the requested data – not the virtual machine itself. This architecture elegantly avoids problems like data races, which could result from Linux storing data on a memory while other virtual machines accesses it. Untrusted external requests have to pass through the firewall of the security policy if they request data. Only after approval can an untrusted OS/application request data via the shared services.
Fig.3: Secure In/Outs, shared services and a firewall make it possible to run trusted and untrusted systems on one hardware
The clearly defined security policy of the firewall works both ways, though. It does provide security but is also provides an opportunity for the big Android developer community to come up with innovative automotive apps. While it would be wise to open this door to a certain extent only, the security policy is an element of making the architecture future-proof as the rules of security can be redefined if needed.
Holistic HMI based on hypervisor technology
Handling heterogeneous