Mises à jour OTA pour Linux embarqué, partie 1 – Principes fondamentaux et implémentation

Le besoin de mises à jour

Une fois qu'un produit Linux embarqué quitte le laboratoire et entre dans le monde réel, la question de savoir comment mettre à jour l'appareil deviendra importante à considérer.

Les mises à jour ne sont pas toujours nécessaires, mais il est difficile de penser à un logiciel sans bogues découverts à un moment donné. Même si votre logiciel est parfait, si l'appareil communique sur des réseaux ou sur Internet avec des bibliothèques open source, des mises à jour de sécurité peuvent devenir une nécessité.

Prenons l'exemple de CVE-2104-01650 (Heartbleed). Cette vulnérabilité a affecté la bibliothèque de cryptographie OpenSSL et par extension les deux tiers des sites Web sur le net. Même maintenant, trois ans plus tard, de nombreux appareils Linux embarqués exécutent une version non protégée d'OpenSSL, largement ouverte aux attaques.

Bloquer les mises à jour de fichiers

Lorsque vous parlez de mise à jour de Linux, vous pouvez voir des systèmes de mise à jour « bloc » et « fichier » mentionnés. Cela fait référence à la mise à jour d'une partition entière à la fois en écrivant directement sur le périphérique de bloc ou en mettant à jour des fichiers individuels pour effectuer la mise à jour. Vous connaissez peut-être les systèmes de mise à jour de fichiers depuis Desktop ou Server Linux (« sudo apt-get upgrade » par exemple).

Dans Embedded Linux, les mises à niveau basées sur des blocs sont la voie à suivre en raison de leur atomicité et du fait qu'un système de fichiers entier est normalement la sortie d'un système de construction Linux embarqué. Nous nous attendons à ce que l'espace de stockage sur chaque périphérique intégré soit constant pour un produit particulier, nous créons donc la même partition de taille à chaque fois. Ce type de mise à jour va de pair avec une sorte d'image de secours ou de récupération.

Récupération en cas de panne

Nous ne voulons jamais que l'appareil soit laissé dans un état inutilisable (si, par exemple, une panne de courant se produit). Nous pouvons résoudre ce problème en veillant à ce qu'il soit toujours possible de "se replier" sur une autre partition en cas de problème dans le processus de mise à jour.

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

Ci-dessus, vous pouvez voir deux implémentations possibles d'un mode de repli en cas de panne de courant. Sur le côté gauche, le Bootloader démarre une partition de secours, qui démarre ensuite dans une partition principale. Sur le côté droit, le Bootloader démarre l'une des deux partitions basées sur un commutateur.

Le chargeur de démarrage doit implémenter une méthode pour déterminer si un démarrage a réussi, et si ce n'est pas le cas, il doit retourner à la partition de secours (diagramme de gauche) ou à la partition de travail précédente (diagramme de droite).

La méthode de sauvetage (à gauche) permet de fournir plus d'espace à la partition principale, tandis que la méthode dual-rootfs (à droite) nécessite que l'espace soit réparti plus ou moins également entre les deux partitions. Si l'espace n'est pas un problème, il est recommandé d'utiliser la méthode dual-rootfs, uniquement parce que cela entraînera moins de temps d'arrêt. La mise à jour via la méthode de secours nécessite deux redémarrages, un dans la partition de secours, puis un autre dans la partition principale. La méthode dual-rootfs ne nécessite qu'un seul redémarrage car la mise à jour peut être effectuée à tout moment.

Ce que vous ne pouvez pas mettre à jour en toute sécurité dans ces systèmes, c'est le chargeur de démarrage (ou même la partition de secours). Si vous souhaitez également pouvoir mettre à jour le chargeur de démarrage, vous aurez besoin de deux partitions de chargeur de démarrage distinctes et d'une sorte de contrôleur de gestion de carte pour implémenter la logique de basculement entre les deux.

Figure 2. Récupération en cas de panne – Board Management Controller (Source :ByteSnap)

Il s'agit bien sûr d'une solution compliquée, nécessitant un microcontrôleur supplémentaire, un nouvel ensemble de micrologiciels et une conception matérielle plus compliquée (elle est utilisée dans certains appareils, ceux qui contiennent un contrôleur IPMI (Intelligent Platform Management Interface) distinct, par exemple) . Par conséquent, vous devriez viser à créer un chargeur de démarrage fonctionnel, de petite portée et qui n'a donc pas besoin d'être mis à jour.

Variables d'environnement U-Boot

U-boot implémente un « environnement » non volatile dans lequel les variables peuvent être stockées. Ceux-ci sont même accessibles depuis Linux (de diverses manières, selon la façon dont l'environnement est stocké, comme détaillé sur elinux.org.

C'est la manière la plus évidente de mettre en œuvre le « commutateur » décrit ci-dessus. Il peut également être utilisé pour stocker des informations sur les succès ou les échecs de démarrage précédents, de sorte qu'en cas d'échec du démarrage, le commutateur puisse être inversé et une partition de travail restaurée.

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