Christophe Blaess

Imaginons une situation qui, malheureusement, risque de devenir familière aux fabricants de produits connectés.

Mardi matin, 9 h 15. Vous apprenez qu’une vulnérabilité concernant une bibliothèque Open Source utilisée dans votre produit est désormais activement exploitée. (La définition d’activement exploitée, terme utilisé dans le CRA, Cyber Resilience Act, sera détaillée plus bas)

Votre produit est déjà commercialisé. Plusieurs dizaines, centaines voire milliers d’équipements sont installés chez vos clients. Certains sont accessibles par le réseau, d’autres se trouvent derrière une infrastructure protégée. Comment réagir ?

Pas de commentaires»

Une fois l’application métier développée, le container correspondant construit et déployé sur une carte (ou un groupe de cartes) de test, il est souvent nécessaire de passer à une étape moins réjouissante : le debug !

Analyser le comportement d’une application fonctionnant dans un container, s’exécutant lui-même dans une machine distante – qui est prévue pour empêcher toute intrusion pour des raisons de sécurité – est assez compliqué. Toutefois Eris Linux nous propose deux méthodes simples pour suivre l’exécution de notre code applicatif. (D’autres méthodes verront probablement le jour, cet article sera modifié en conséquence quand ce sera le cas).

Pas de commentaires»

Nous venons de publier une nouvelle version de Yocto Cooker (1.6.0) sur PyPi.

Pendant longtemps, Cooker partait du principe que le menu utilisait le repository Poky. Or, ce dépôt n’est plus utilisé pour les branches ultérieures à novembre 2025 (Whinlatter, Wrynose et la future Blacksail).

Il faut désormais s’appuyer sur plusieurs dépôts pour faire un build.

Pas de commentaires»

Nous avons vu dans les articles précédents de cette série :

• en quoi consiste la distribution embarquée industrielle Eris Linux,
• comment installer Eris sur une carte embarquée, en l’occurrence un Raspberry Pi 5,
• comment déployer des containers avec du code de démonstration,
• comment écrire et embarquer des applications dans des containers.

Les applications que l’on embarque sous forme de code « métier » ne sont que très rarement auto-suffisantes. Elles ont souvent besoin de communiquer avec le système sous-jacent pour consulter ou configurer des éléments du système (par exemple le paramétrage réseau, la configuration du watchdog, celle des LEDs etc.)

Pour cela Eris Linux offre une interface de programmation qui permet, depuis l’intérieur d’un container, de communiquer avec le système hôte. En réalité cette API (Application Programming Interface) est déclinée en deux implémentations. Une bibliothèque (liberis) qui peut être employée par les applications compilées (en C ou C++ par exemple) et un service REST accessible pour les langages interprétés (javascript, Python, etc.). Nous avons déjà aperçu des usages de liberis et du service REST pour l’API d’Eris Linux dans l’article précédent.

Pas de commentaires»

L’éco-système « The Yocto Project » est assez touffu. En effet, Yocto Project chapeaute plusieurs sous-projets pour lesquels il fournit des ressources de développement : Bitbake, Open Embedded, Poky, les layers des sponsors « platiniums » ainsi que l’hébergement de nombreux layers supportant diverses plateformes matérielles.

Depuis plus d’une décennie, la mise en route d’un projet Yocto passait par l’utilisation d’un starter pack contenant les outils de base et les recettes minimales pour produire une image. Cet environnement se nommait Poky.

Pas de commentaires»

Le Raspberry Pi 5 dispose d’une interface de debug spécifique basée sur un connecteur JST 1mm. Toutefois, il est souvent préférable lorsqu’on veut se connecter en utilisant une console série, d’utiliser le port d’extension habituel, avec ses broches 6 (GND), 8 (TX) et 10 (RX) comme les précédents modèles de Raspberry Pi.

Cela permet de faire facilement communiquer deux cartes entre elles (simplement en croisant TX et RX) ou d’utiliser une console de debug (par exemple sur un PC) avec un petit connecteur USB-Serie.

Pas de commentaires»