À propos des mises à jour OVA

Important

Il s’agit de la documentation Azure Sphere (héritée). Azure Sphere (hérité) prend sa retraite le 27 septembre 2027 et les utilisateurs doivent migrer vers Azure Sphere (intégré) pour l’instant. Utilisez le sélecteur de version situé au-dessus du TOC pour afficher la documentation Azure Sphere (intégrée).

Les mises à jour constituent une partie importante du modèle de sécurité Azure Sphere, car elles incarnent la propriété de la sécurité renouvelable. S’assurer que les mises à jour ont lieu régulièrement permet de maintenir vos appareils conformes aux 7 propriétés . Les appareils Azure Sphere vérifient les mises à jour lorsqu’ils se connectent d’abord à Internet après avoir activé ou après l’appui du bouton Réinitialiser. Par la suite, les vérifications se produisent à intervalles réguliers (actuellement 20 heures).

Il existe trois types de mises à jour : mises à jour préalables requises, mises à jour du système d’exploitation et mises à jour de déploiement. Les mises à jour préalables sont utilisées pour s’assurer que les composants dont dépend le processus de mise à jour lui-même ( actuellement le magasin de clés approuvé (TKS) et le magasin de certificats – sont à jour. Le TKS est utilisé pour authentifier les images à télécharger et installer, tandis que le magasin de certificats valide les connexions Internet. Une mise à jour du système d’exploitation cible le logiciel fourni par Microsoft sur l’appareil, notamment le système d’exploitation normal que vos applications s’exécutent, mais également un microprogramme de niveau inférieur, tel que le sous-système Pluton et le Moniteur de sécurité. Les mises à jour de déploiement ciblent vos propres logiciels : vos applications de haut niveau et en temps réel et les images de configuration de carte (le cas échéant). Les mises à jour préalables et du système d’exploitation sont gérées par Azure Sphere ; Les mises à jour d’application sont coordonnées par Azure Sphere en fonction des déploiements créés par votre organisation.

Pour que tout appareil reçoive des mises à jour préalables ou du système d’exploitation :

• Il doit être connecté à Internet.
• Les exigences de mise en réseau doivent être correctement configurées.

Pour que n’importe quel appareil met à jour ses images de configuration d’application et de carte :

• Elle ne doit pas avoir la fonctionnalité de développement d’applications.
• Elle doit être revendiquée par un locataire.
• Il doit appartenir à un groupe d’appareils.
• Le groupe d’appareils auquel il appartient doit être ciblé par un déploiement.
• Le déploiement doit contenir des images d’application (et éventuellement une image de configuration de carte) créées par ou pour le compte de votre organisation.
• Le groupe d’appareils doit avoir la stratégie de mise à jour UpdateAll. Vous pouvez désactiver les mises à jour d’application pour un groupe d’appareils particulier avec la commande azsphere device-group update.

Pour tous les appareils d’un groupe d’appareils donné, les déploiements ciblant ce groupe d’appareils sont considérés comme la source de vérité pour l’imagerie de ces appareils. Toutes les images sur l’appareil qui n’existent pas dans le déploiement seront supprimées de l’appareil. L’une des exceptions, à partir du système d’exploitation Azure Sphere 21.04, est que les images de configuration de carte ne sont pas supprimées, sauf si elles sont remplacées par une nouvelle image de configuration de carte.

La vérification des mises à jour de l’appareil se produit en trois phases correspondant aux trois types de mises à jour :

• Dans la première phase, Azure Sphere obtient un manifeste répertoriant les versions actuelles du magasin de certificats et de savoirs traditionnels. Si le magasin de certificats et les savoirs traditionnels sur l’appareil sont à jour, la mise à jour se poursuit avec la deuxième phase. Si ce n’est pas le cas, les images actuelles sont téléchargées et installées.
• Dans la deuxième phase, Azure Sphere obtient un manifeste répertoriant les versions actuelles des différentes images de composants du système d’exploitation. Si des images sur l’appareil sont obsolètes, les images actuelles sont téléchargées avec les images de restauration qui peuvent être utilisées pour restaurer l’appareil à un état correct connu si le processus de mise à jour échoue. Les images de système d’exploitation et de restauration sont téléchargées et stockées dans une zone intermédiaire sur l’appareil, puis les images du système d’exploitation sont installées et l’appareil est redémarré.
• Dans la troisième phase, Azure Sphere vérifie les mises à jour de déploiement si le groupe d’appareils les accepte. Comme pour la mise à jour du système d’exploitation, les images de restauration pour les applications sont également intermédiaires en fonction des besoins. Les images d’application et de restauration sont téléchargées et stockées dans la zone intermédiaire, puis les images d’application sont installées.

Restauration des mises à jour

Chaque partie du processus de mise à jour inclut une option de restauration. Dans la mise à jour préalable, l’image de restauration est simplement une sauvegarde de l’état de pré-mise à jour. Si la mise à jour échoue, l’état de pré-mise à jour est restauré.

La restauration à tout niveau force la restauration à tous les niveaux supérieurs : si une image de microprogramme ne parvient pas à démarrer, les partitions de microprogramme et d’application sont restaurées.

Pour la mise à jour du système d’exploitation, une défaillance de vérification de signature ou des difficultés d’exécution peut déclencher une restauration. En cas d’échec de vérification de signature, une tentative est effectuée pour corriger l’image ; si cela échoue, une restauration complète est déclenchée. Dans une restauration complète, les images de restauration intermédiaire sont installées pour le système d’exploitation et les applications.

Les mises à jour et les déploiements du système d’exploitation ont des cycles de publication indépendants. Il est donc possible que plusieurs déploiements se produisent entre les mises à jour du système d’exploitation. Dans ce cas, il est important de noter que les cibles de restauration pour le déploiement ne sont pas le déploiement le plus récent, mais plutôt le déploiement au moment de la dernière mise à jour du système d’exploitation. Cela garantit que le système d’exploitation et l’application fonctionnent ensemble à l’état restauré.

Mises à jour interrompues

Si une mise à jour est interrompue, par exemple par une panne de courant ou une perte de connectivité, il existe quatre scénarios possibles pour chaque type de mise à jour :

• Si un ensemble complet d’images a été correctement téléchargé et mis en scène, mais pas encore installé, l’installation se termine lors de la restauration de l’alimentation.
• Si certaines images n’ont pas été téléchargées et intermédiaires, la mise à jour continue de télécharger les images manquantes, puis passe à l’installation.
• Si une mise à jour est interrompue pendant l’installation une fois le téléchargement terminé, l’installation redémarre au démarrage.
• Si aucune image n’a été entièrement téléchargée, le processus de mise à jour démarre à nouveau lors de la restauration de l’alimentation, car il n’y aura rien de prêt à être installé.

Mises à jour dans les scénarios de mise hors tension

Azure Sphere prend en charge des scénarios à faible alimentation qui permettent aux appareils d’être mis hors tension pendant des périodes prolongées afin de conserver la durée de vie de la batterie. Dans de tels scénarios, il est important que l’appareil soit autorisé à rechercher régulièrement les mises à jour. L’exemple d’application Power Down montre comment réduire correctement la consommation d’alimentation tout en garantissant que l’appareil reste régulièrement éveillé pour rechercher les mises à jour du système d’exploitation et de l’application.

Mises à jour différées

Pour empêcher les tâches critiques d’être interrompues par les mises à jour, les applications de haut niveau peuvent incorporer une mise à jour différée. Cette fonctionnalité permet à l’application d’effectuer ses tâches critiques, puis de se préparer à l’arrêt pour permettre à la mise à jour de continuer. L’exemple DeferredUpdate montre comment implémenter une telle mise à jour différée.