Secured Industrial Embedded Linux

This presentation was given at Automotive Linux Submit in Tokyo.

AGL natively supports secure micro-services through its Application Framework binder/binding mechanism. A ready to go system may easily run tens or hundreds of micro-services. Consequently monitoring exchanges between binders/bindings is critical. Monitoring may need to be “realtime” to help debugging, or offline when tracking global performances and security issues.

This talk starts by presenting current AGL Application Framework monitoring capabilities to track basic inter-bindings communications. It then exposes how existing supervision service can be used to analyze end-to-end transactions when crossing multiple bindings. Finally it illustrates how AGL supervision can leverage Time Serie Database to collect data, allowing monitoring frameworks like Grafana to render a global vision of the system both in term of performance and cybersecurity.

Download slides [click here]

 

This presentation was given at Automotive Linux Submit in Tokyo.

In order to embrace the global automotive ecosystem, AGL micro-services architecture should support not only all Linux in a car, but also seamlessly retrieve data from small ECUs and securely send collected information to the cloud.

Because of existing application framework dependencies, as today, AGL bindings run only on Linux. In order to extend to global automotive ecosystem, AGL’s binders/bindings architecture needs to be reviewed. On one hand, remove Linux’s systemD dependencies and extend security model. On a second hand, support ‘alien’ transport protocols including non TCP/IP ones.

This talk presents the lesson learned from a POC to run a subset of current AGL binder onto a micro-controller with Zephyr. How to solve binder/binding dependencies, how to map the transport onto a non TCP/IP link, how to extend AGL security model, ...

Download slides [click here]

 

As today, AGL mostly leverages Wayland IVI-shell as inherited from Genivi. Worse than having technical limitations, the main issue of IVI-Shell is the persistent lack of interest from the Wayland community. As a result, the IVI-shell ailed to gain adoption from any generic software like browsers or well known social/media applications. Since the early days of Wayland, new options appear to better support compositors/wm.

On one hand, Gnome and KDE ship their own flavour of compositor/wm; nevertheless those solutions remain too monolithic and too desktop centric for the embedded world.

On the other hand Wlroots was designed upfront, not as a Wayland compositor/wm but as a foundation to create compositor. Furthermore, because it’s more recent, the authors were able to leverage the lesson learnt from older toolkit as Weston or WLC and created a far more advanced and flexible toolkit.

Download Slides [here]

Demo video [here]

 

Isolating components of different criticalities is a desirable feature of safety-critical systems used in the automotive industry. IoT.bzh and Kernkonzept therefore cooperated in creating a virtualization Proof-of-Concept that isolates selected components of AGL.

The purpose of this PoC is to split CAN signal processing into two virtual instances of AGL running under the control of the L4Re hypervisor.

The 1st virtual instance runs a minimal AGL realtime(preemptRT) profile and is responsible for CAN data acquisition. The 2nd virtual instance
runs a traditional AGL IVI profile and receives CAN decoded signals directly from AGL application framework through the hypervisor VIRTIO transport layer.

This talk starts by presenting the different components of the architecture used in the PoC. Then it explains how a hypervisor can be used to split AGL into multiple instances and the constrains such an architecture introduces. Finally it proposes some options and remaining work before such a solution gets production ready.

Download pdf slide [here]

A slideshow updated since the latest presentation in Karlsruhe in 2016 with a presentation of a full stack signaling stack using the Signal Composer service.

Click here

Archived Publications

A propos

L’objectif technique d'IoT.bzh consiste à assembler, en fonction des besoins attachés à des marchés verticaux spécifiques (Automobile, Télécoms, Médical, Nautisme, Domotique, Agriculture…), un ensemble de composants logiciels techniques provenant de sources variées pour en faire une distribution cohérente où tous les composants fonctionnent ensemble de manière harmonieuse.

Coordonnées

IoT.bzh

Halles St Louis,
    rue Docteur Bodelio
56100 Lorient
02 57 62 02 47