Techniques recommandées pour mettre à jour Linux embarqué en toute sécurité

Question

Les périphériques Linux intégrés nécessitent souvent un mécanisme pour mettre à jour les applications et les fichiers système. Par exemple, un instrument de laboratoire (sans réseau) doté d'un port USB peut obtenir des mises à jour logicielles à partir d'une clé USB.

Il serait simple d’exécuter un script pour copier des fichiers en place sur la mémoire flash interne du périphérique. Cependant, le périphérique risque de perdre de la puissance au milieu de la mise à jour et de se transformer en brique.

La situation des fichiers d’application est un peu plus facile car il est possible de dupliquer le répertoire de l’application, de mettre à jour une copie et d’échanger rapidement les anciens et les nouveaux répertoires, ce qui minimise la fenêtre d’échec.

Les choses sont plus claires pour les fichiers du noyau et du système car elles sont réparties dans le système de fichiers.

Nous avons utilisé des liens physiques et des liens physiques dans le système de fichiers pour identifier les fichiers critiques. Nous utilisons des hachages sur les fichiers et les archives pour vérifier leur intégrité. Nous avons envisagé d’utiliser un ramfs d’urgence dans le noyau pour fournir une solution de secours si le démarrage du système de fichiers mis à jour échoue.

Quelles sont vos approches pour répondre à cette exigence?

Answer 1

J'irais avec la même approche qu'avec les fichiers d'application: Recherchez les fichiers critiques et complétez votre propre partition, créez un lien avec eux et dupliquez la partition. Dans tous vos init, vous devez d’abord vérifier si les liens affichent tous la même partition, sinon, les réinitialiser (vers la partition contenant les fichiers avec la date la plus récente d’un fichier donné). Si vous souhaitez mettre à jour, copiez simplement tout sur la nouvelle partition et si tout va bien (crcs ok), passez en boucle sur les fichiers et définissez pour chacun le lien entre les systèmes de fichiers.

De cette façon, vos fichiers critiques doivent toujours être dans un état sain.

Scénarios:

1. La mise à jour échoue lors de la copie de fichiers sur une nouvelle partition

   Pas de problème car les liens montrent toujours ceux qui fonctionnaient auparavant.

2. la mise à jour échoue lors de la liaison

   Pas de problème car tous les nouveaux fichiers sont valides et déjà copiés (sinon l'étape de relier n'aurait pas à démarrer), la configuration est correcte

Answer 2

Si vous devez assurer la fiabilité, vous pouvez avoir deux partitions flash (ou même des puces), une avec la configuration actuelle et la seconde. Utilisez ensuite un chien de garde matériel qui réinitialisera l’unité et commutera la partition flash de démarrage active sur le "dernier bon produit connu". configuration.

Answer 3

Avoir au moins deux partitions. Je suggère 4

• démarrer

• autre démarrage

• sauvegarde des données du programme

• programme données volatiles

Utilisez le démarrage de secours grub pour un démarrage alternatif si le démarrage échoue.

Ainsi, si la mise à jour échoue, la solution alternative fonctionne.

NE JAMAIS mettre à jour le chargeur de démarrage.

Si la partition de données est grillée, reformatez-la et copiez-la sur la partition de données de sauvegarde.

Maintenant, vous ne pouvez pas échouer à moins que le disque flash ne meure. Si vous utilisez du matériel COTS et que le disque principal est Compact Flash, vous pouvez disposer d’une sauvegarde physiquement isolée, par exemple d’une petite clé USB.

Answer 4

IMHO, toute mise à jour non atomique peut casser le système ou rendre la vérification de la cohérence assez difficile. Je conviens que la mise à jour du chargeur de démarrage doit être évitée car elle n’est pas à l’état de secours. Généralement, un fabricant souhaite une mise à jour du micrologiciel x.x.x vers la version y.y.y, sans se soucier de savoir si le noyau et / ou un seul fichier a été mis à jour. La mise à jour de fichiers uniques peut devenir un cauchemar pour le service, car il est très difficile de comprendre ce qui fonctionne sur le matériel du client. Peut-être combinez-vous une approche à double copie (application redondante) avec une approche à copie unique. Je pense que cela n'aide pas beaucoup, car l'intégrité du système est assurée par le composant faible de la chaîne. Si une mise à jour du système de fichiers racine échoue, il n’est pas important que l’application soit dupliquée.

Une approche en double copie peut garantir une mise à jour sans mise hors service, si vous en avez besoin. Mais cela nécessite beaucoup de ressources, car tous les composants doivent être dupliqués. Personnellement, j’utilise une approche de secours dans laquelle un petit rootfs en RAM est démarré si l’application principale échoue ou si la dernière mise à jour a échoué. Ce système de secours, démarré automatiquement par le chargeur de démarrage en cas de problème, mettez le système à jour à l'aide d'un stylo USB (si une mise à jour locale est requise).

Je n’ai jamais trouvé de projet OSS sur ces problèmes et j’en ai lancé un nouveau récemment, sur la base de mon expérience antérieure. Plusieurs produits l’utilisent et mes clients en sont satisfaits.

Peut-être que vous pouvez y jeter un coup d'œil. Vous pouvez trouver des sources pour "swupdate". (nom du projet) à l'adresse github.com/sbabic/swupdate .

Stefano

Answer 5

Je pense que ce que vous essayez de réaliser ici est l’attricité du processus de mise à jour. L'atomicité est essentielle pour les périphériques intégrés. L'une des raisons mises en avant est la perte de puissance. mais il pourrait y en avoir d'autres comme des problèmes de matériel / réseau. Voici une définition de l'atomicité dans le contexte des mises à jour:

• Une mise à jour est toujours soit complètement terminée, soit pas du tout
• Aucun composant logiciel à part le programme de mise à jour ne voit une mise à jour à moitié installée

Pour Linux embarqué, vous pouvez mettre à jour plusieurs composants logiciels et choisir différents modèles. il existe un article à ce sujet ici: https: // mender .io / user / pages / 04.resources / _white-papers / Software% 20Updates.pdf