With cars increasingly becoming networked IT entities, security is becoming an indispensable issue for car electronics developers. This also applies for the infotainment domain as the connector between vehicle and the outside world. In the second part of this article, different models are discussed how to protect the software.

Sandbox

Open source operating systems such as MeeGo or Ubuntu are well regarded for their adherence to the latest and greatest multimedia standards and availability of third party applications. However, we cannot necessarily depend on the multimedia OS to control all aspects of next-generation consolidated infotainment systems. General-purpose operating systems cannot boot fast enough, cannot guarantee real-time response for protocols such as CAN, and are not reliable and secure enough for safety-critical functions such as rear-view camera and integrated clusters. Therefore we need a system architecture in which multimedia operating systems and their applications can peacefully coexist with real-time, high assurance applications, hosted on a real-time, safety-rated operating system.

One potential solution is to have multiple processors dedicated to the differing tasks. However, this results in the same issues as today's multiple ECUs, lowering the speed of communication between applications and increasing boundary complexity.

The need to contain these functions on a single processor is very real, enabling optimisation of cost, processing cycles, data availability, and complexity. We need sandboxes for these mixed-criticality workloads. One can think of each sandbox as an isolated persona.

The following four approaches to multiple personas have been commercialised in one form or another:

Multi-boot

Webtop

Type-2 hypervisor

Type-1 hypervisor

Multi-boot

The multi-boot concept was attempted on a handful of laptops and netbooks over the past few years. In a dual boot laptop scenario, a secondary operating system, typically a scaled down Linux, can be launched in lieu of the main platform operating system. The scaled down system is typically only used for web browsing, and the primary goal is to enable the user to be browsing within a handful of seconds from cold boot. The secondary operating system resides in separate storage and is never running at the same time as the primary platform operating system. In some cases, the lightweight environment executes on a secondary microprocessor (e.g. an ARM SoC independent