Mises à jour OTA Linux embarqué – Partie 1 : Fondamentaux et implémentation

Le besoin de mises à jour

Une fois qu'un produit Linux embarqué quitte le laboratoire pour le terrain, déterminer comment il recevra les mises à jour devient une décision de conception critique.

Même une application en apparence sans faille n'est pas à l'abri du changement : la réalité est que le logiciel accumule inévitablement des bogues et, pour les appareils connectés au réseau ou à Internet, les correctifs de sécurité sont souvent inévitables. Même un firmware théoriquement parfait doit accommoder les vulnérabilités dans les bibliothèques tierces.

Considérez la vulnérabilité Heartbleed (CVE-2014-0160) qui a exposé la bibliothèque cryptographique OpenSSL. La faille a affecté environ deux tiers de tous les sites web et, à ce jour, d'innombrables appareils Linux embarqués embarquent encore une version OpenSSL non corrigée, les laissant exposés à l'exploitation.

Mises à jour basées blocs vs basées fichiers

Les mécanismes de mise à jour pour Linux peuvent être classés en approches basées blocs et basées fichiers. Les mises à jour blocs écrasent une partition ou un périphérique bloc entier en une opération atomique, tandis que les mises à jour fichiers remplacent des fichiers ou paquets individuels — similaire à « apt-get upgrade » sur distributions desktop ou serveur.

Pour Linux embarqué, les mises à jour basées blocs sont préférées car le système de fichiers entier est typiquement produit par un unique pipeline de build et l'empreinte de stockage d'un produit est fixe. Mettre à jour une partition entière en une seule étape simplifie aussi le rollback : une copie de l'image précédente peut être conservée jusqu'à ce que la nouvelle soit vérifiée.

Assurer la récupération après une mise à jour échouée

Aucun appareil ne doit être laissé dans un état inutilisable, surtout si une perte de puissance ou une défaillance d'écriture survient en plein flash. L'atténuation habituelle est de maintenir une partition secondaire qui peut prendre le relais si l'image primaire échoue à démarrer.

Figure 1. Récupération en cas d'échec – options de repli (Source : ByteSnap)

Deux patterns courants existent :

• Stratégie partition de secours — Le chargeur de démarrage démarre une petite image de secours qui peut lancer le firmware principal après la mise à jour. Cela permet à la partition principale d'occuper la majeure partie de l'espace de stockage, mais nécessite deux redémarrages (dans la secours, puis dans le principal).
• Stratégie dual-rootfs — Deux systèmes de fichiers racine complets sont maintenus côte à côte. Le chargeur de démarrage bascule entre eux au démarrage. Quand une mise à jour est appliquée, l'image inactive est écrasée, et un seul redémarrage est nécessaire. Cette approche divise par deux l'espace disponible par image, mais offre une récupération plus rapide et zéro temps d'arrêt.

Si le stockage est abondant, la méthode dual-rootfs est généralement recommandée pour sa simplicité et sa performance. L'approche secours est utile quand l'image principale est grande et l'espace de rechange pour un rootfs dupliqué est limité.

Notez que les chargeurs de démarrage sont typiquement immuables dans cette configuration. Pour mettre à jour un chargeur de démarrage, il faudrait une partition de chargeur additionnelle et un contrôleur de gestion de carte (BMC) capable d'orchestrer la bascule — une solution qui augmente la complexité matérielle et le coût.

Figure 2. Récupération en cas d'échec – Board Management Controller (Source : ByteSnap)

Puisque le BMC ajoute matériel et firmware supplémentaires, la plupart des concepteurs préfèrent rendre le chargeur de démarrage aussi petit et fiable que possible pour qu'il n'ait jamais besoin de mise à jour OTA.

Exploiter les variables d'environnement U-Boot

U-Boot stocke un environnement non-volatile qui peut être interrogé depuis Linux et manipulé pendant le démarrage. Ces variables sont idéales pour encoder la partition active, suivre les succès de démarrage, et orchestrer la logique de bascule.

Patterns typiques incluent :

• Définir un drapeau avant de basculer vers la nouvelle image.
• Incrémenter une variable « compteur de démarrage » à chaque démarrage réussi.
• Réinitialiser le drapeau après qu'un seuil de démarrages réussis est atteint.

En stockant cet état dans U-Boot, le chargeur de démarrage peut automatiquement revenir à l'image précédente si la nouvelle échoue à démarrer un nombre configurable de fois.

Figure 3. Variables d'environnement U-Boot (Source : ByteSnap)