ELCE11: Sandboxing for automotive Linux

On the second day of the Embedded Linux Conference Europe (ELCE), Iisko Lappalainen from MontaVista Software presented a method for running secondary Linux environments inside a "host" Linux OS with strict sandboxing and security requirements. The example use-case was running Android inside a GENIVI-based Linux in-vehicle infotainment (IVI) system, though other combinations are possible. The setup would permit a car-maker to ship a system with full access to an Android application ecosystem, while maintaining isolation from the underlying OS.

As GENIVI's Matt Jones explained in an earlier session, the GENIVI middleware stack is isolated from the vehicle's safety-critical systems like engine control and anti-lock braking; running on separate hardware on electrically isolated circuits. But there are still important functions in an IVI system that, if interrupted, would greatly inconvenience the user. Navigation on the head unit, or proximity sensors on the bumpers, for example — neither one should hang or crash just because a child in the back is playing a buggy video game on a rear-seat entertainment screen. Buggy games aside, there is also always the prospect of intentionally malicious code.

That provides one use-case for running applications inside some sort of sandboxed environment. Lappalainen listed several others. First, it would provide a way to run applications written for multiple UI frameworks, in particular, frameworks not natively supported by the base IVI system. The example he presented was an HTML5-based web runtime, which was not a component planned for the MeeGo IVI user experience (UX), which GENIVI designated in 2010 as its reference platform. Canonical has subsequently announced its own GENIVI-compliant IVI remix, which also does not address a web runtime; MeeGo's successor Tizen, however, does have a web runtime.

The Android environment in particular offers its own advantages as the sandboxed OS, Lappalainen said. The existing ecosystem is enormous, both in terms of applications and trained developers. Android's "app store" model also explicitly supports multiple, branded app stores, which would allow OEMs to provide their own software product channel directly in the IVI system. Finally, if done right, sandboxing should allow the OEM to enforce a tight security model on the applications inside — perhaps providing a more isolated environment for untrusted, user-installed applications, while factory-installed applications are allowed to run natively.

The containerized approach

The sandboxing approach taken by MontaVista utilizes Linux Containers (LXC) to isolate the sandboxed environment, and SELinux to supply a security layer. LXC containers provide a form of virtualization by isolating the sandboxed processes in a separate control group — thus allowing the host OS to limit resource usage and isolate file access — and by maintaining separate process ID and network namespaces. Separate namespaces not only hide the host OS from each container, but isolate each container from the others.

Lappalainen referred to this approach as "virtualization," but that term can mean different things to different people. Specifically, LXC containers provide OS-level virtualization akin to OpenVZ or Virtuozzo. A system running inside an LXC container can have its own view of the filesystem and a separate group of processes — with entirely different user-space code — but it still uses the same kernel as the "host" (for lack of a better term) OS. This is a distinct difference from hardware-level virtualization, which supports running any flavor of guest OS on top of the host OS. On the other hand, OS-level virtualization is generally faster because there is no overhead associated with running a virtual machine layer.

But OS-level virtualization also introduces a hurdle to running one Linux-based OS inside of another if the two OSes differ significantly in kernel features, not just userspace. That is certainly the case with Android, which replaces several stock kernel features and adds several other features. In MontaVista's Android-on-GENIVI project, the host kernel is patched with Android-specific features.

Lappalainen listed the Android kernel's IPC binder, low-memory killer, logger device, and asynchronous shared-memory system (ashmem) in particular on his slides; in the talk however he simply described the kernel as including the "Android patches." He also mentioned that these kernel functions needed to be adapted to work only within the context of the Android container. In particular, Android replaces the standard Linux out-of-memory (OOM) killer with its own variety. One would only want the low-memory killer to watch for low memory conditions within the Android container, and then to only kill one of the Android container's processes.

The guest-OS containers are configured so that their processes run at lower priority than the host OS's. There are also various mechanisms used to process IO, graphics, and other resources for the collection of containers. The "event dispatcher" tracks the window coordinates of each application, for example, so it can route input events to the proper container or to the host OS. Graphics output is handled by capturing the Android container's frame buffer, and sending it to a "layer manager" that overlays it on the display together with video output from the other applications. Audio is less tricky to coordinate, he said, because it can be down-mixed into one output by the audio server. This is already what ALSA and PulseAudio do when multiple applications play sound simultaneously.

Power management is handled entirely by the host OS, which Lappalainen said required changes to the Android wakelock code. On multi-core systems, he added, the container-management code can also be used to bind containers to specific processors, which provides another method of ensuring that they cannot bring down the host OS even in the event of a serious fault.

Lappalainen did not go into much detail on the role that SELinux plays in providing further isolation for the LXC containers. It is certainly possible that SELinux could simply be set up to duplicate the filesystem isolation and other sandboxing mechanisms provided by LXC, acting as a separate, back-up "wrapper" around the containers. But SELinux might also plug security holes in LXC. For example, LXC does not provide user namespaces, which means that a malicious root user could escape from its container and execute code as the root user on the host OS.

Code and product

Lappalainen outlined various use-cases for the LXC/SELinux containerization approach, noting that it could also be beneficial in other embedded Linux projects because it can isolate untrusted applications, but without the performance hit of running them in an emulator. MontaVista's implementation of this configuration is its Automotive Technology Platform (ATP), a commercial IVI product.

The company announced ATP's Android-and-HTML5 support feature in an October 10 press release, which positions ATP as a competitor to open projects like MeeGo/Tizen and Ubuntu IVI — in particular, one that has a leg up on the competition thanks to the vast array of already-written Android and HTML5 applications. IVI was not a major topic at ELCE; Jones' talk was the only other session dedicated to IVI, and it dealt as much with the plans and in-house experiments of his employer Jaguar Land Rover (JLR) as it did with GENIVI.

An illuminating snippet from that talk, however, was that it will be 2014 at the earliest before any Linux-based IVI systems are available in JLR vehicles. That is an exceptionally long time in kernel and distribution time-scales. A few other car-makers are reported to be closer, notably BMW, but have not announced a deployment schedule.

In fact, ever since the announcement of the MeeGo IVI platform, it seems that the IVI software industry has changed drastically faster than the car industry with which the rival platforms are vying to go into business. There were rumors that GM would adopt Android as the next-generation base for its OnStar system, only to have the company join GENIVI instead. MeeGo brought on several major car-makers as partners (including Toyota) in early 2011, then MeeGo morphed into Tizen without warning.

That much change can make it difficult to handicap the players. However, the big obstacle for ATP is likely to be asking car-makers to undertake supporting Android and a GENIVI Linux distribution. Even apart from the handset-and-tablet-centric stance that Google takes with the product, it sounds like a challenging customer support undertaking. In 2011, GENIVI quietly began shifting its language away from talk of a MeeGo "reference implementation" and towards "GENIVI compliance," which blesses multiple distributions. That could be because GENIVI had early warning of the migration from MeeGo to Tizen; regardless of whether or not GENIVI formally adopts Tizen as its reference platform, Tizen will match ATP's HTML5 support, which could make the web-runtime selling-point moot.

In short, though the work that has gone into virtualizing "guest" Linux OSes in MontaVista's ATP is interesting, it seems odd to position it as an IVI-specific technology. There are certainly plenty of users of other form factors that would love the chance to run thousands of Android applications inside a secure sandbox — starting with smartphone and desktop Linux distributions. Whether ATP, Android itself, or some other solution entirely is adopted by GENIVI or the car-makers remains to be seen, but it does seem likely that a hybrid like ATP will be fighting an uphill battle.

[The author would like to thank the Linux Foundation for assisting with his travel to the Embedded Linux Conference Europe 2011.]