Article de : Mohamed BELOUARGA

L'ajout d'une fonctionnalité, la correction d'un bug ou la résolution d'une faille de sécurité font tous partie du cycle de vie d'un logiciel, d'une bibliothèque ou d'un micrologiciel. Cependant, pour les architectes et les développeurs, la réalisation de ces tâches s'accompagne toujours d'inconvénients techniques et d'un risque de conséquences indésirables (nouveaux bugs, retours en arrière, etc.)

Jusqu'à présent, le secteur, et en particulier celui des systèmes embarqués, continue d'envoyer ses techniciens sur place pour effectuer les mises à jour de ses produits. Ces procédures prennent beaucoup de temps, nécessitent une logistique importante, sont coûteuses et sont donc souvent négligées, ce qui suscite une grande insatisfaction chez les clients et les utilisateurs.   

Les mises à jour à distance, également appelées mises à jour OTA (Over The Air), sont mieux adaptées aux besoins futurs de la plupart des entreprises industrielles, des fabricants et de leurs futurs produits.    

Dans le domaine du Linux embarqué, des mises à jour OTA sont disponibles

Cet article traite des mises à jour à distance pour les systèmes Linux embarqués.

Les mises à jour OTA permettent d'apporter des modifications logicielles à un système sans avoir à intervenir physiquement sur celui-ci. Ces mises à jour peuvent être effectuées à l'aide de plusieurs solutions open source, mais leur mise en œuvre n'est pas toujours simple.

Lorsque les fabricants examinent les différentes options de mise à jour, la première solution qu'ils envisagent est la mise à jour par paquets. Cette solution est la moins adaptée aux systèmes embarqués pour plusieurs raisons :

• Si la mise à jour ne se déroule pas comme prévu, vous ne pourrez pas effectuer d'opération de restauration.
• Chaque composant doit être géré en fonction de ses dépendances
• Conflits de versions : sur un système de bureau, on peut se permettre d'avoir deux versions d'une même bibliothèque, mais ce n'est pas le cas sur un système où la mémoire est limitée.
• La validation d'une mise à jour est une tâche très complexe. D'autant plus que plus le nombre de mises à jour augmente, plus le processus devient compliqué et coûteux. Il est nécessaire de planifier le passage de la version 1 à la version 2, de la version 2 à la version 3, mais aussi de la version 1 à la version 3, etc.

👉 Parmi les exemples, on peut citer Mender, Ostree, RAUC…

Il existe toutefois d'autres solutions permettant d'éviter tous ces inconvénients, telles que SWUpdate, Mender, OsTree, RAUC, etc.

Chaque solution a sa propre façon de gérer les mises à jour ; dans cet article, nous n'aborderons que SWUpdate, de Stefano Babic.

#Swupdate s'apparente davantage à un cadre de développement qu'à d'autres solutions de bout en bout

Contrairement à la solution de bout en bout Mender, qui s'accompagne de ses propres exigences, contraintes et limites, SWUpdate permet de créer une version personnalisée de Mender, en ajoutant ou en supprimant des fonctionnalités. Cela permet de mettre au point une solution de mise à jour parfaitement adaptée aux besoins du client.

L'inconvénient est que le fichier de mise à jour peut être volumineux, ce qui augmentera les coûts de connexion. Cependant, ce problème peut également être évité en utilisant un système de fichiers racine compressé lors de la mise à jour, ou en recourant à une mise à jour delta. Nous y reviendrons plus tard.

Définition d'une stratégie de mise à jour

Avant de mettre en œuvre une solution de mise à jour, il convient de définir une stratégie de mise à jour. Cette stratégie s'inscrit dans le cycle de vie d'un produit et est très difficile à modifier.

Voici quelques exemples de stratégies de mise à jour : 

Mode double copie

• Le mode double copie consiste à dupliquer des éléments, ce qui implique de disposer de : deux systèmes de fichiers racine, deux noyaux, deux DT (arborescences de périphériques), deux environnements de chargeur d'amorçage, etc.

La procédure de mise à jour se déroule comme suit. Pendant que le produit fonctionne avec rootfs1 et kernel1, swupdate met à jour rootfs2 ou kernel2, puis redémarre sur rootfs2 et kernel2.

Si la mise à jour aboutit, le produit reste inchangé. Mais si ce n'est pas le cas (si rootfs2 est endommagé ou si kernel2 plante), U-Boot effectue une opération de restauration vers rootfs1 et kernel1.

Stratégie de sauvetage unique

• La stratégie de secours simple occupe moins d'espace que le mode double copie, car elle utilise un système de fichiers racine et un noyau de secours.

Le noyau de secours ne contient que les pilotes indispensables, et le système de fichiers racine de secours ne contient que les bibliothèques indispensables et swupdate. Les autres systèmes de fichiers racine et noyaux correspondent au micrologiciel de production.

Lorsqu'une mise à jour est prête, l'image redémarre sur l'image de secours, à partir de laquelle le système de fichiers racine et le noyau sont mis à jour. Une fois la mise à jour effectuée, l'image redémarre avec le noyau et le système de fichiers racine de production.

Quoi qu'il en soit, si la mise à jour échoue, le noyau de secours et le système de fichiers racine servent de solution de secours.

Comme nous l'avons déjà mentionné, SWUpdate étant un framework, tout est possible avec lui. Ses seules limites sont celles de l'imagination de ses utilisateurs.

Interface du chargeur d'amorçage

SWUpdate doit fonctionner en conjonction avec le chargeur d'amorçage, ce qui signifie que lorsque l'appareil ou le produit doit modifier le système de fichiers racine, le chargeur d'amorçage modifie la ligne de commande transmise au noyau. Cette interaction est donc essentielle au bon fonctionnement du système de mise à jour.

Maintenant que nous avons vu les stratégies de mise à jour et l'interface du bootloader, voyons les différents outils proposés par SWUpdate pour envoyer une mise à jour. 

Mode Mangouste

L'interface pourrait ressembler à ceci :

La mise à jour SWUpdate en mode Mangoose intègre un serveur web qui nous permet d'envoyer le fichier de mise à jour via une interface web.

Une fois SWUpdate correctement configuré, cette interface permet à l'utilisateur d'envoyer un fichier de mise à jour (.swu) à la cible. Elle affiche également des informations telles que l'état de la mise à jour et les journaux.

Mode suricate

En mode Surricata, SWUpdate interroge un serveur distant pour vérifier la présence de mises à jour, les télécharge et les installe, puis rend compte des résultats.

Principalement utilisé pour les parcs de cartes importants, le mode Surricata centralise et supervise les commandes du système de mise à jour. Côté serveur, nous pouvons utiliser Eclipse hawkBit pour surveiller l'état d'un parc de cartes.

À l'heure actuelle, seul Eclipse hawkBit est pris en charge, mais grâce au caractère open source de ces solutions, il est possible d'ajouter un serveur personnalisé qui servira de solution de contournement.

Intégrer SWupdate à vos processus opérationnels

En tant que framework, SWUpdate offre aux utilisateurs un large éventail de fonctionnalités et d'outils supplémentaires. Par exemple, si un utilisateur souhaite envoyer une mise à jour .swu via une autre application, il peut transmettre le fichier au démon SWUpdate à l'aide de l'outil SWUpdate-client. De plus, grâce à SWUpdate-progress, cette même application peut récupérer les données relatives à la progression de la mise à jour, ce qui permet une surveillance externe.

Il existe de nombreuses autres fonctionnalités, et toutes sont très bien documentées. 

Gestionnaires

Si vous avez un besoin particulier, par exemple pour installer une mise à jour spécifique ou mettre à jour un microcontrôleur connecté à la cible, SWUpdate vous permet d'ajouter votre propre gestionnaire.

Mises à jour signées

La sécurité reste une priorité pour SWUpdate. La possibilité d'utiliser le protocole HTTPS avec le mode surricata en est déjà la preuve, mais nous pouvons également signer les fichiers .swu. SWUpdate sera alors en mesure de vérifier que les mises à jour reçues proviennent d'une source autorisée (clé privée/clé publique).  

Résoudre le problème de la taille et de la bande passante

👉 Mises à jour condensées

Dans la plupart des cas, le coût de la bande passante représente la partie la plus onéreuse d'une procédure de mise à jour. La mise à jour d'un système de fichiers racine (rootfs) sur un grand nombre de cibles nécessite également une bande passante importante. Pour résoudre ce problème et réduire les coûts, SWUpdate vous permet d'utiliser des systèmes de fichiers racine compressés.

👉 Actualités Delta

Le coût de la bande passante reste élevé même après compression, c'est pourquoi SWUpdate propose une autre solution basée sur les deltas.

Cette solution sera abordée dans un prochain article.

En conclusion, SWUpdate est un framework complet capable de répondre à de nombreuses situations spécifiques. Lorsqu'il est correctement configuré, SWUpdate permet de réduire vos coûts de mise à jour tout en simplifiant considérablement la mise à jour des systèmes Linux pour tous.

Si vous souhaitez en savoir plus sur SWUpdate et sur la manière dont cet outil peut aider votre entreprise, vous pouvez contacter : 

Fabien LAHOUDERE, responsable de la division Linux chez T&S
Martin COUSSERANS, directeur commercial

Contactez-nous