Pierre-jean Texier, profile picture
Téléchargé parPierre-jean Texier
PDF, PPTX1,304 vues

Mises à jour logicielles en environnement Linux Embarqué, petit guide et tour d'horizon

Ce guide aborde la mise à jour des systèmes embarqués sous Linux en soulignant son importance, les défis spécifiques associés, et les différentes méthodes d'implémentation comme A/B ou mises à jour OTA. Il détaille également les exigences clés pour une mise à jour réussie, y compris la nécessité d'une opération atomique et d'un système de sauvegarde. Enfin, le document explore des outils et projets open-source, ainsi que des mécanismes de reprise après échec.

Intégrer la présentation

Télécharger en tant que PDF, PPTX
1 / 108
2 / 108
3 / 108
4 / 108
5 / 108
6 / 108
7 / 108
8 / 108
9 / 108
10 / 108
11 / 108
12 / 108
13 / 108
14 / 108
15 / 108
16 / 108
17 / 108
18 / 108
19 / 108
20 / 108
21 / 108
22 / 108
23 / 108
24 / 108
25 / 108
26 / 108
27 / 108
28 / 108
29 / 108
30 / 108
31 / 108
32 / 108
33 / 108
34 / 108
35 / 108
36 / 108
37 / 108
38 / 108
39 / 108
40 / 108
41 / 108
42 / 108
43 / 108
44 / 108
45 / 108
46 / 108
47 / 108
48 / 108
49 / 108
50 / 108
51 / 108
52 / 108
53 / 108
54 / 108
55 / 108
56 / 108
57 / 108
58 / 108
59 / 108
60 / 108
61 / 108
62 / 108
63 / 108
64 / 108
65 / 108
66 / 108
67 / 108
68 / 108
69 / 108
70 / 108
71 / 108
72 / 108
73 / 108
74 / 108
75 / 108
76 / 108
77 / 108
78 / 108
79 / 108
80 / 108
81 / 108
82 / 108
83 / 108
84 / 108
85 / 108
86 / 108
87 / 108
88 / 108
89 / 108
90 / 108
91 / 108
92 / 108
93 / 108
94 / 108
95 / 108
96 / 108
97 / 108
98 / 108
99 / 108
100 / 108
101 / 108
102 / 108
103 / 108
104 / 108
105 / 108
106 / 108
107 / 108
108 / 108
Linux Embarqué Mises à jour logicielles en environnement Linux Embarqué, petit guide et tour d’horizon Pierre-Jean Texier Samedi 17 Novembre Toulouse, CDL 2018
/me
Pierre-Jean Texier • Ingénieur Linux Embarqué Lafon Technologies • 28 ans • FOSS enthusiast • Contributions : U-Boot, Kernel Linux, Yocto/OE, ... • Co-auteur de ”Yocto for Raspberry Pi” et auteur dans GNU/Linux magazine et Open silicium (RIP) 1
Sommaire 1. Mise à jour des systèmes embarqués 2. Les différents projets Open-Source 3. RAUC, WaRP7 & Yocto/OE 4. Mender, WaRP7 & Yocto/OE 5. Démos 6. Conclusion 2
Mise à jour des systèmes embarqués
Pourquoi un système de mise à jour ? • Bugs Logiciels • Ajouts de fonctionnalités • Correctifs liés à la sécurité (CVE) 3
Pourquoi si spécial dans l’embarqué ? • Accessibilité • Disponibilité • Fiabilité du réseau électrique • Système sur batterie, • Perte de tension (secteur) • Connectivités réseaux (pour les mises à jour distantes) • GPRS, 3G, LTE, WiFi, ... • Faible bande passante • Microcontrôleur, Microprocesseur, FPGA, ... • Durée de vie sur site supérieure à 10 ans 4
Ok, mais quels composants ? 5
fitImage • zImage /dts-v1/; / { description = "CDL fitImage"; #address-cells = <1>; images { kernel { description = "zImage"; data = /incbin/("./zImage"); type = "kernel"; arch = "arm"; os = "linux"; compression = "none"; load = <0x80800000 >; entry = <0x80800000 >; hash-1 { algo = "sha256"; }; }; ... 6
fitImage • FDT fdt-1 { description = "Flattened Device Tree blob"; data = /incbin/("./imx7s-warp.dtb"); type = "flat_dt"; arch = "arm"; compression = "none"; ... }; }; • Firmware firmware -1 { description = "Firmware Cortex M4"; data = /incbin/("./main.bin"); type = "firmware"; arch = "arm"; compression = "none"; ... }; 7
fitImage • Configuration configurations { default = "conf-1"; conf-1 { description = "CDL Configuration"; kernel = "kernel"; fdt = "fdt-1"; firmware = "firmware -1"; signature { algo = "sha256,rsa4096"; key-name-hint = "cdl-key"; sign-images = "firmware", "fdt", "kernel"; }; }; }; • Chargement => load mmc 0:1 0x85000000 fitImage => bootm 0x85000000 8
Sur quelle base ? • Fichiers • A éviter, difficile de garantir l’atomicité (-) 9
Sur quelle base ? • Fichiers • A éviter, difficile de garantir l’atomicité (-) • Gestionnaire de paquets • RPM, deb, opkg • rpm -ivh my-wonderful-app.rpm ? (-) • Facile (+) mais difficile à maintenir -> gestion des dépendances (-) • Non Atomique et non applicable pour l’embarqué (-) 9
Sur quelle base ? • Fichiers • A éviter, difficile de garantir l’atomicité (-) • Gestionnaire de paquets • RPM, deb, opkg • rpm -ivh my-wonderful-app.rpm ? (-) • Facile (+) mais difficile à maintenir -> gestion des dépendances (-) • Non Atomique et non applicable pour l’embarqué (-) • Container • Concept intéressant (+) • Implique de gérer les applications dans un container (-) 9
Sur quelle base ? • Fichiers • A éviter, difficile de garantir l’atomicité (-) • Gestionnaire de paquets • RPM, deb, opkg • rpm -ivh my-wonderful-app.rpm ? (-) • Facile (+) mais difficile à maintenir -> gestion des dépendances (-) • Non Atomique et non applicable pour l’embarqué (-) • Container • Concept intéressant (+) • Implique de gérer les applications dans un container (-) • Delta (atomique) • Faible bande-passante (+) • Complexe (-) • Risques sur la corruption du système de fichiers principal (-) 9
Sur quelle base ? • Fichiers • A éviter, difficile de garantir l’atomicité (-) • Gestionnaire de paquets • RPM, deb, opkg • rpm -ivh my-wonderful-app.rpm ? (-) • Facile (+) mais difficile à maintenir -> gestion des dépendances (-) • Non Atomique et non applicable pour l’embarqué (-) • Container • Concept intéressant (+) • Implique de gérer les applications dans un container (-) • Delta (atomique) • Faible bande-passante (+) • Complexe (-) • Risques sur la corruption du système de fichiers principal (-) • Image complète : Full OS • Le cas le plus courant dans l’embarqué • Facile à mettre en oeuvre (+) 9
Quels mécanismes ? • En fonctionnement : • Non Atomique (quelques exceptions) • Donwtime très court • Qui ? : Package managers, AGL • Mode maintenance : initrd/initramfs • Robuste • Retour en arrière impossible si erreur • Downtime -> long • Qui ? : Android (avant Nougat) • A/B ou Seamless update : • Robuste, mais coûteux en espace de stockage • Retour en arrière possible si erreur • Downtime -> court • Toujours opérationnel • Qui ? : Android (depuis Nougat) 10
Et comment ? • Mises à jour sur site • Pas de connectivité • Accès physique : • Gestion par clé USB/carte SD • Interactif • Déplacement d’un technicien eee • Mises à jour distantes : OTA • Pas d’accès physique : • HTTPS, FTP, ... • Pas d’intéraction • Serveur pour la gestion des périphériques (flotte) • Mise à jour programmée • Campagne de mise à jour • Inventaire des périphériques • Statut des périphériques • Version logicielle courante • Gestion des artefacts 11
Exigences clés d’un dispositif de mise à jour • Doit être capable de mettre à jour l’ensemble des composants • Bootloader = dangereux • Doit s’interfacer avec le Bootloader (e.g Environnement U-Boot) • Doit être Robuste (coupures de courant et pertes de connexions réseau) • L’opération doit être atomique = Pas d’installation partielle • Ne doit pas rendre le périphérique inutilisable (Fail-safe) • Notion de Rollback • Doit disposer d’un espace pour les données persistentes (Stateless FS) • Partition dédiée • Doit être sécurisé • Empêcher une action non autorisée • Doit permettre une gestion Locale et Distante (OTA) • Doit permettre d’effectuer des tests (Sanity check) avant validation 12
Downtime
Exemple 1/4 @internetofshit 13
Exemple 2/4 @internetofshit 14
Exemple 3/4 @internetofshit 15
Exemple 4/4 16
Robuste ?!
Coupure de courant ?! 17
Atomicité : Exemple schéma A/B • Démarrage sur A 18
Atomicité : Exemple schéma A/B • Démarrage sur A • Mise à jour de B 18
Atomicité : Exemple schéma A/B • Démarrage sur A • Mise à jour de B • coupure de courant ! 18
Atomicité : Exemple schéma A/B • Démarrage sur A • Mise à jour de B • coupure de courant ! • Démarrage sur A 18
Atomicité : Exemple schéma A/B • Démarrage sur A • Mise à jour de B • coupure de courant ! • Démarrage sur A • Mise à jour de B 18
Rollback ?!
”Etre capable de revenir sur une version stable (et fonctionnelle) lors de la détection d’un problème” 19
Pour éviter ... 20
Pour éviter ... 21
Pour éviter ... 22
Rollback : Quand ? Plusieurs cas de figures : • Echec d’une mise à jour • Détecté par l’updater • Mise à jour réussie mais problème Noyau (Kernel Panic) • BUG logiciel ! • Mise à jour réussie mais problème sur l’applicatif métier • BUG logiciel ! 23
Rollback : Scénario • Démarrage sur A 24
Rollback : Scénario • Démarrage sur A • Mise à jour de B • Mise à jour du flag active_partition (flag bootloader) 24
Rollback : Scénario • Démarrage sur A • Mise à jour de B • Mise à jour du flag active_partition (flag bootloader) • Reboot 24
Rollback : Scénario • Démarrage sur A • Mise à jour de B • Mise à jour du flag active_partition (flag bootloader) • Reboot • Démarrage sur B • Anomalie de l’application principale 24
Rollback : Scénario • Démarrage sur A • Mise à jour de B • Mise à jour du flag active_partition (flag bootloader) • Reboot • Démarrage sur B • Anomalie de l’application principale • Détection de l’anomalie • Reboot 24
Rollback : Scénario • Démarrage sur A • Mise à jour de B • Mise à jour du flag active_partition (flag bootloader) • Reboot • Démarrage sur B • Anomalie de l’application principale • Détection de l’anomalie • Reboot • Rollback • Mise à jour du flag active_partition (flag bootloader) 24
Rollback : Scénario • Démarrage sur A • Mise à jour de B • Mise à jour du flag active_partition (flag bootloader) • Reboot • Démarrage sur B • Anomalie de l’application principale • Détection de l’anomalie • Reboot • Rollback • Mise à jour du flag active_partition (flag bootloader) • Démarrage sur A 24
Rollback : Fondamentaux 1/2 Gestion des Kernel Panic : 25
Rollback : Fondamentaux 1/2 Gestion des Kernel Panic : • Utilisation de CONFIG_PANIC_TIMEOUT • Pour définir le timeout avant redémarrage sur un Kernel Panic 25
Rollback : Fondamentaux 1/2 Gestion des Kernel Panic : • Utilisation de CONFIG_PANIC_TIMEOUT • Pour définir le timeout avant redémarrage sur un Kernel Panic ”Sanity Check” : 25
Rollback : Fondamentaux 1/2 Gestion des Kernel Panic : • Utilisation de CONFIG_PANIC_TIMEOUT • Pour définir le timeout avant redémarrage sur un Kernel Panic ”Sanity Check” : • Après la mise à jour, il faut vérifier si le système est opérationnel avant de valider celle-ci : 25
Rollback : Fondamentaux 1/2 Gestion des Kernel Panic : • Utilisation de CONFIG_PANIC_TIMEOUT • Pour définir le timeout avant redémarrage sur un Kernel Panic ”Sanity Check” : • Après la mise à jour, il faut vérifier si le système est opérationnel avant de valider celle-ci : • Vérification de l’applicatif métier (UI, services, serveur, ...), • Vérification de la configuration système, • ... 25
Rollback : Fondamentaux 1/2 Gestion des Kernel Panic : • Utilisation de CONFIG_PANIC_TIMEOUT • Pour définir le timeout avant redémarrage sur un Kernel Panic ”Sanity Check” : • Après la mise à jour, il faut vérifier si le système est opérationnel avant de valider celle-ci : • Vérification de l’applicatif métier (UI, services, serveur, ...), • Vérification de la configuration système, • ... Mécanisme de redémarrage lors d’une défaillance : 25
Rollback : Fondamentaux 1/2 Gestion des Kernel Panic : • Utilisation de CONFIG_PANIC_TIMEOUT • Pour définir le timeout avant redémarrage sur un Kernel Panic ”Sanity Check” : • Après la mise à jour, il faut vérifier si le système est opérationnel avant de valider celle-ci : • Vérification de l’applicatif métier (UI, services, serveur, ...), • Vérification de la configuration système, • ... Mécanisme de redémarrage lors d’une défaillance : • Watchdog • Pour détecter les freezes • Solution matérielle 25
Rollback : Fondamentaux 2/2 Gestion des cycles de redémarrage répétitif (e.g U-Boot) : 26
Rollback : Fondamentaux 2/2 Gestion des cycles de redémarrage répétitif (e.g U-Boot) : • Implémentation Bootcount Limit • CONFIG_BOOTCOUNT_LIMIT et CONFIG_BOOTCOUNT_ENV • bootcount : variable incrémentée à chaque redémarrage • bootlimit : pour définir le nombre maximal de redémarrage • altbootcmd : séquence alternative si bootcount > bootlimit • upgrade_available : pour la gestion de bootcount 26
Rollback : Fondamentaux 2/2 Gestion des cycles de redémarrage répétitif (e.g U-Boot) : • Implémentation Bootcount Limit • CONFIG_BOOTCOUNT_LIMIT et CONFIG_BOOTCOUNT_ENV • bootcount : variable incrémentée à chaque redémarrage • bootlimit : pour définir le nombre maximal de redémarrage • altbootcmd : séquence alternative si bootcount > bootlimit • upgrade_available : pour la gestion de bootcount • Interaction Bootloader <-> userspace afin de positionner les variables • Utilisation de fw_setenv et fw_printenv 26
Rollback : Fondamentaux 2/2 Gestion des cycles de redémarrage répétitif (e.g U-Boot) : • Implémentation Bootcount Limit • CONFIG_BOOTCOUNT_LIMIT et CONFIG_BOOTCOUNT_ENV • bootcount : variable incrémentée à chaque redémarrage • bootlimit : pour définir le nombre maximal de redémarrage • altbootcmd : séquence alternative si bootcount > bootlimit • upgrade_available : pour la gestion de bootcount • Interaction Bootloader <-> userspace afin de positionner les variables • Utilisation de fw_setenv et fw_printenv Exemple : bootlimit=1 26
Rollback : Fondamentaux 2/2 Gestion des cycles de redémarrage répétitif (e.g U-Boot) : • Implémentation Bootcount Limit • CONFIG_BOOTCOUNT_LIMIT et CONFIG_BOOTCOUNT_ENV • bootcount : variable incrémentée à chaque redémarrage • bootlimit : pour définir le nombre maximal de redémarrage • altbootcmd : séquence alternative si bootcount > bootlimit • upgrade_available : pour la gestion de bootcount • Interaction Bootloader <-> userspace afin de positionner les variables • Utilisation de fw_setenv et fw_printenv Exemple : bootlimit=1 • Démarrage sur A, mise à jour de B 26
Rollback : Fondamentaux 2/2 Gestion des cycles de redémarrage répétitif (e.g U-Boot) : • Implémentation Bootcount Limit • CONFIG_BOOTCOUNT_LIMIT et CONFIG_BOOTCOUNT_ENV • bootcount : variable incrémentée à chaque redémarrage • bootlimit : pour définir le nombre maximal de redémarrage • altbootcmd : séquence alternative si bootcount > bootlimit • upgrade_available : pour la gestion de bootcount • Interaction Bootloader <-> userspace afin de positionner les variables • Utilisation de fw_setenv et fw_printenv Exemple : bootlimit=1 • Démarrage sur A, mise à jour de B • fw_setenv bootcount 0 26
Rollback : Fondamentaux 2/2 Gestion des cycles de redémarrage répétitif (e.g U-Boot) : • Implémentation Bootcount Limit • CONFIG_BOOTCOUNT_LIMIT et CONFIG_BOOTCOUNT_ENV • bootcount : variable incrémentée à chaque redémarrage • bootlimit : pour définir le nombre maximal de redémarrage • altbootcmd : séquence alternative si bootcount > bootlimit • upgrade_available : pour la gestion de bootcount • Interaction Bootloader <-> userspace afin de positionner les variables • Utilisation de fw_setenv et fw_printenv Exemple : bootlimit=1 • Démarrage sur A, mise à jour de B • fw_setenv bootcount 0 • fw_setenv upgrade_available 1 26
Rollback : Fondamentaux 2/2 Gestion des cycles de redémarrage répétitif (e.g U-Boot) : • Implémentation Bootcount Limit • CONFIG_BOOTCOUNT_LIMIT et CONFIG_BOOTCOUNT_ENV • bootcount : variable incrémentée à chaque redémarrage • bootlimit : pour définir le nombre maximal de redémarrage • altbootcmd : séquence alternative si bootcount > bootlimit • upgrade_available : pour la gestion de bootcount • Interaction Bootloader <-> userspace afin de positionner les variables • Utilisation de fw_setenv et fw_printenv Exemple : bootlimit=1 • Démarrage sur A, mise à jour de B • fw_setenv bootcount 0 • fw_setenv upgrade_available 1 • Démarrage sur B (bootcount=1) 26
Rollback : Fondamentaux 2/2 Gestion des cycles de redémarrage répétitif (e.g U-Boot) : • Implémentation Bootcount Limit • CONFIG_BOOTCOUNT_LIMIT et CONFIG_BOOTCOUNT_ENV • bootcount : variable incrémentée à chaque redémarrage • bootlimit : pour définir le nombre maximal de redémarrage • altbootcmd : séquence alternative si bootcount > bootlimit • upgrade_available : pour la gestion de bootcount • Interaction Bootloader <-> userspace afin de positionner les variables • Utilisation de fw_setenv et fw_printenv Exemple : bootlimit=1 • Démarrage sur A, mise à jour de B • fw_setenv bootcount 0 • fw_setenv upgrade_available 1 • Démarrage sur B (bootcount=1) • Si OK fw_setenv upgrade_available 0, MAJ validée 26
Rollback : Fondamentaux 2/2 Gestion des cycles de redémarrage répétitif (e.g U-Boot) : • Implémentation Bootcount Limit • CONFIG_BOOTCOUNT_LIMIT et CONFIG_BOOTCOUNT_ENV • bootcount : variable incrémentée à chaque redémarrage • bootlimit : pour définir le nombre maximal de redémarrage • altbootcmd : séquence alternative si bootcount > bootlimit • upgrade_available : pour la gestion de bootcount • Interaction Bootloader <-> userspace afin de positionner les variables • Utilisation de fw_setenv et fw_printenv Exemple : bootlimit=1 • Démarrage sur A, mise à jour de B • fw_setenv bootcount 0 • fw_setenv upgrade_available 1 • Démarrage sur B (bootcount=1) • Si OK fw_setenv upgrade_available 0, MAJ validée • Si NOK, redémarrage, bootcount > bootlimit, exécution de la commande altbootcmd, retour sur A 26
Rollback : Gestion du Watchdog • Interface = /dev/watchdog • Utilisation via systemd • Watchdog matériel : • RuntimeWatchdogSec • ShutdownWatchdogSec • Watchdog logiciel (pour les services) : ”keep-alive ping” [Unit] Description=FooBar application [Service] ExecStart=/usr/bin/foobarapp WatchdogSec=10s Restart=on-failure StartLimitInterval=5min StartLimitBurst=2 StartLimitAction=reboot ... 27
Rollback : protection • Mécanisme vulnérable aux attaques : • Retour sur l’ancienne partition afin d’y exploiter une faille de sécurité • Utilisation TPM (Trusted Platform Module) • Utilisation d’un compteur (counter) • afin d’éviter qu’un attaquant ne remplace un nouveau logiciel sécurisé par un logiciel vulnérable plus ancien 28
Sécurité ?!
Comment empêcher une installation non autorisée ? De façon générale : • Gestion des compatibilités (Même matériel != Même produit) • Contrôle d’intégrité Lié à la sécurité : • Communication sécurisée (OTA) • Cryptographie (signature/vérification) 29
? 30
Pour résumer ... mender.io 31
Les différents projets Open-Source
Hawkbit Eclipse hawkBit is a domain independent back-end framework for rolling out software updates 32
Frameworks
RAUC Robust Auto-Update Controller • https://github.com/rauc • LGPLv2.1 • C & GLib • Client très léger (167.7Ko) • Mise à jour Symétrique/Asymétrique + flexibilité (data, appfs, ...) • Configurable par le fichier system.conf • Notion de Slot • U-Boot, Barebox, GRUB, EFI • Support PKCS#11 (HSM) • SD/eMMC, UBI, Raw NAND, SquashFS • HTTP(S), FTP, SSH 33
RAUC • ”Bundle” au format SquashFS et signé (x509) • Rollback non intégré (exemple rauc/contrib/uboot.sh) • Bootchooser Framework • BOOT_ORDER, BOOT_bootname_LEFT • rauc status mark-good & rauc status mark-bad • Utilisation des scripts U-Boot • Compatible casync (delta update) • Contrôlable via D-Bus • Notion de handlers et hooks -> customisation • Mise à jour locale (USB) ou distante (rauc-hawkbit) • Bien documenté mais ... • Très peu d’exemples pour l’intégration • Build System 34
SWUpdate SWUpdate: software update for embedded system • https://github.com/sbabic/swupdate • Un mix de MIT, GPLv2 and GPLv2+ • C • Client léger (400Ko) • Mise à jour Symétrique/Asymétrique + flexibilité • Configurable par le fichier sw-description • XML, JSON et libconfig Exemple • U-Boot, GRUB, EFI • SD/eMMC, UBI, Raw NAND, NOR/SPI NOR • HTTP(S), FTP, SSH -> (libcurl) pour l’aspect networking 35
SWUpdate • Archive CPIO (signature et chiffrement possible) • Rollback non intégré (quelques implémentaions disponibles) • IPC : Unix Domain Socket pour avoir le statut (progression) • Mise à jour locale (USB et serveur web) ou distante (Hawkbit) • Interface graphique en Lua pour le mode recovery (RescueGUI) • Gestion scripts pre/post install • Gestion microcontrôleur en UART (ucfw), gestion maître/esclave (SWU forwarder) • Bien documenté • Exemples sur raspberry-pi, beaglebone, wandboard -> (meta-swupdate-boards) • Build System 36
SWUpdate : RescueGUI 37
SWUpdate : Serveur Web 38
Solutions End-to-End
Mender Mender is an end-to-end open source update manager for IoT • https://github.com/mendersoftware • Apache 2.0 • Solution Clé en main (client + serveur) • Client lourd (4.6Mo) • Mise à jour Symétrique seulement • 4 Partitions (Boot + RootFS A + RootFS B + Data) • U-Boot, GRUB • SD/eMMC, UBI, Raw NAND, NOR • HTTP(S) 39
Mender • Archive TAR .mender (gestion signature via l’outil mender-artifact) • Rollback intégré • State Scripts pour la gestion des actions durant l’opération de mise à jour • Mise à jour locale (mode standalone) ou distante (Managed) • Hosted Mender (payant) • Infrastructure Docker • Facile d’intégration (Auto-patch) • mender -commit pour valider la mise à jour en mode standalone • Bien documenté • Exemples sur https://hub.mender.io/ • Build System 40
Mender : State Scripts • Use cases : • Migration des données • Confirmation utilisateur (retry later) • ... 41
Mender : Hosted Mender hosted mender 42
Mender : Mender Hub 43
Mender : GCP/Mender ”Google Cloud IoT Core integrates with Mender.io to analyze issues and enable OTA software updates for IoT” 44
UpdateHub An end-to-end solution for large scale over-the-air update of devices • https://github.com/updatehub • GPLv2 • Solution Clé en main (client + serveur) • Golang (mais passage prévu en Rust !) • Client léger (476ko) • Mise à jour Symétrique/Asymétrique + flexibilité • Configurable par le fichier cible_uhupkg.config Exemple • U-Boot, GRUB • SD/eMMC, UBI, Raw NAND, NOR • HTTP(S) 45
UpdateHub • ”Package” signé • Rollback intégré • Contrôlable via plusieurs SDK : Go, Qt, Python • Unix Domain Socket • Mise à jour locale (USB) ou distante (Serveur UpdateHub -> e) • Bientôt une nouveauté ? • Bien documenté • Exemples sur raspberry-pi, beaglebone, wandboard, WaRP7, ... • Build System 46
UpdateHub : Serveur UpdateHub 47
Mais aussi 1/2 • resin.io maintenant balena (Container) • Container Utilisateur (docker) (Delta Update -> librsync) • Mise à jour symétrique pour la partie core balenaOS • Read-Only rootFS • Integration Yocto/OE = meta-balena • Supporte seulement : SD/eMMC 48
Mais aussi 2/2 • libostree (Delta) • ”Like git but for a root file system” • commit = rootfs • 1 repository = /ostree/repo et un ensemble de ”déploiements” stockés dans /ostree/deploy/... • Image initramfs (init.sh) • chroot dans /ostree/deploy/myos/234... • /usr = lecture seule • /var = persistant • Utilisé par AGL, Qt OTA, Flatpak, ... • Integration Yocto/OE = meta-updater 49
RAUC, WaRP7 & Yocto/OE
RAUC : system.conf • Configuration du système cible : system.conf • Dans meta-cdl/recipes-core/rauc (recette dérivée) [system] compatible=AwesomeProduct bootloader=uboot [keyring] path=/etc/rauc/ca.cert.pem [handlers] post-install=/usr/lib/rauc/post-install.sh [slot.rootfs.0] device=/dev/mmcblk1p2 type=ext4 bootname=A [slot.rootfs.1] device=/dev/mmcblk1p3 type=ext4 bootname=B 50
RAUC : Bundle • Création d’un recette permettant la génération du paquet de mise à jour (Bundle) : cdl-bundle.bb DESCRIPTION = "RAUC bundle for Capitole du Libre" inherit bundle RAUC_BUNDLE_COMPATIBLE = "AwesomeProduct" RAUC_BUNDLE_VERSION = "v2018 -11-17-1" RAUC_BUNDLE_DESCRIPTION = "Simple Demo Bundle for CDL" RAUC_BUNDLE_SLOTS = "rootfs" RAUC_SLOT_rootfs = "core-image-base" RAUC_SLOT_rootfs[fstype] = "ext4" RAUC_KEY_FILE = "chemin/vers/development -1.key.pem" RAUC_CERT_FILE = "chemin/vers/development -1.cert.pem" • Possible aussi avec l’outil tmp/deploy/tools/rauc • bitbake rauc-native 51
RAUC : Partitions • Création du fichier rauc.wks pour la définition des partitions part /boot --source bootimg-partition --ondisk mmcblk --fstype=vfat --label boot --active --align 4096 --size 20 part / --source rootfs --ondisk mmcblk --fstype=ext4 --label rootfs_A --align 8192 --extra-space 200 part / --source rootfs --ondisk mmcblk --fstype=ext4 --label rootfs_B --align 8192 --extra-space 200 part /data --ondisk mmcblk --fstype=ext4 --label data --size 128M --align 8192 --extra-space 0 bootloader --ptable msdos • Kickstart file pour la création des 4 partitions eMMC 52
RAUC : Paramètres de l’image • Utilisation de systemd : # Use systemd as init system VIRTUAL-RUNTIME_init_manager = "systemd" DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit" VIRTUAL-RUNTIME_initscripts = "" DISTRO_FEATURES_append = " systemd wifi" • Intégration des éléments vitaux : CORE_IMAGE_EXTRA_INSTALL_append = " rauc rauc-hawkbit packagegroup -base u-boot-fw-utils kernel-devicetree " # Script pour la gestion du rollback IMAGE_BOOT_FILES_append = " boot.scr" • Encore un peu de configuration : IMAGE_FSTYPES_append = " ext4" WKS_FILES_imx7s -warp = "rauc.wks" 53
RAUC : génération $: bitbake cdl-bundle • core-image-base-imx7s-warp.ext4 • core-image-base-imx7s-warp.wic.gz • cdl-bundle-imx7s-warp.raucb 54
Mender, WaRP7 & Yocto/OE
Mender : Configuration 1/2 • Intégration avec U-Boot INHERIT += "mender-full" MENDER_FEATURES_DISABLE_append = " mender-grub mender-image-uefi" # Périphérique de stockage MENDER_STORAGE_DEVICE = "/dev/mmcblk1" # Périphérique de stockage (U-Boot) MENDER_UBOOT_STORAGE_INTERFACE = "mmc" MENDER_UBOOT_STORAGE_DEVICE = "0" # Script U-Boot IMAGE_BOOT_FILES_append = " boot.scr" 55
Mender : Configuration 2/2 • meta-cdl/recipes-bsp/u-boot/u-boot-mender-warp7.inc FILESEXTRAPATHS_prepend := "${THISDIR}/u-boot-fslc:" SRC_URI_remove = " file://0005-fw_env_main.c-Fix-incorrect-size-for-malloc-ed-strin.patch " SRC_URI_append = " file://0001-warp7-add-mender-requirements.patch " MENDER_UBOOT_AUTO_CONFIGURE = "0" BOOTENV_SIZE = "0x2000" • Ajout des variables CONFIG_BOOTCOUNT_ENV et CONFIG_BOOTCOUNT_LIMIT +CONFIG_BOOTCOUNT_LIMIT=y +CONFIG_BOOTCOUNT_ENV=y 56
Mender : Paramètres de l’image • Utilisation de systemd : # Use systemd as init system VIRTUAL-RUNTIME_init_manager = "systemd" DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit" VIRTUAL-RUNTIME_initscripts = "" DISTRO_FEATURES_append = " systemd wifi" • Configuration Artefact et Serveur : MENDER_ARTIFACT_NAME = "CDL-release -1" MENDER_SERVER_URL = "https://hosted.mender.io" MENDER_TENANT_TOKEN = "..." 57
Mender : génération $: bitbake core-image-base • core-image-base-imx7s-warp.sdimg • core-image-base-imx7s-warp.mender • Signature de l’artefact : $: ./mender-artifact sign core-image-base-imx7s-warp.mender -k ./private.key 58
Buildroot
Mender 59
RAUC 60
SWUpdate 61
Démos
Démos • Mender Mode Standalone • Mender Mode Hosted Mender • RAUC 62
Conclusion
Conclusion Ce qu’il faut retenir : • Un mécanisme de mise à jour est obligatoire (le penser au début du projet) • Toujours déployer un logiciel bien testé • Bien tester les différentes solutions • Oublier les solutions ”Maison” • FOSS 63
Questions? 63

Contenu connexe

PDF
Mender 2.0 101: Bien démarrer avec les 'update modules'
parPierre-jean Texier
 
PDF
Mise à jour d’un système Linux embarqué « Over The Air »
parPierre-jean Texier
 
PDF
Pipeline Devops - Intégration continue : ansible, jenkins, docker, jmeter...
parXavierPestel
 
PDF
RASPBERRY PI - votre infrastructure : ansible, user, iptables, monitoring, re...
parXavierPestel
 
PDF
Consul, un vrai couteau suisse
parXavierPestel
 
PDF
Solutions temps réel sous linux
parembedded-linux-bdx
 
PDF
Linux et le temps réel - Meetup du 15 octobre 2015
parChristian Charreyre
 
PDF
Zabbix, garder un oeil toujours ouvert
parLook a box
 
Mender 2.0 101: Bien démarrer avec les 'update modules'
parPierre-jean Texier
 
Mise à jour d’un système Linux embarqué « Over The Air »
parPierre-jean Texier
 
Pipeline Devops - Intégration continue : ansible, jenkins, docker, jmeter...
parXavierPestel
 
RASPBERRY PI - votre infrastructure : ansible, user, iptables, monitoring, re...
parXavierPestel
 
Consul, un vrai couteau suisse
parXavierPestel
 
Solutions temps réel sous linux
parembedded-linux-bdx
 
Linux et le temps réel - Meetup du 15 octobre 2015
parChristian Charreyre
 
Zabbix, garder un oeil toujours ouvert
parLook a box
 

Tendances

PDF
NetBSD operating system: Clean Code, Ports, Anykernel, pkgsrc and Desktop pro...
parjihbed
 
PDF
Gestion des dépendances dans un projet PHP - Forum PHP 2012
parJean-Marc Fontaine
 
PDF
Principes de fonctionnement unix
parwebreaker
 
PDF
Zabbix
parkamiloo2009
 
PDF
Meetup Systemd vs sysvinit
parChristian Charreyre
 
PDF
I le langage java d'una manière avancée introduction
parsabrine_hamdi
 
PDF
CD d’auto-installation de Nagios, Centreon et NaReTo
parguest3be047
 
PDF
Retour d'expérience : gérer des flux vidéos multiples de manière optimisée
parSilicon Comté
 
PDF
Déploiement pour l’hébergement d’architecture cliente et mise en place du Sel...
parOpenNebula Project
 
PPTX
Moussasambe projet de securite zabbix
parmoussa sambe
 
ODP
Fully Automated Nagios Jm2L 2009
parFAN Fully Automated Nagios
 
ODP
Parinux 2009
parFAN Fully Automated Nagios
 
PDF
Les solutions libres pour les systèmes embarqués
parAlexandre LAHAYE
 
PDF
Synthese
parAlexis Pelhâte
 
PDF
Distro Recipes 2013 : Yocto / OpenEmbedded
parAnne Nicolas
 
PDF
Docker en Production (Docker Paris)
parJérôme Petazzoni
 
PPT
Vm ware
parJIngenieur
 
PDF
Important Vm Ware Infrastrucutre Slides
parnouari
 
PDF
Docker : quels enjeux pour le stockage et réseau ? Paris Open Source Summit ...
parJérôme Petazzoni
 
ODP
Journées du Logiciel Libre 2008
parFAN Fully Automated Nagios
 
NetBSD operating system: Clean Code, Ports, Anykernel, pkgsrc and Desktop pro...
parjihbed
 
Gestion des dépendances dans un projet PHP - Forum PHP 2012
parJean-Marc Fontaine
 
Principes de fonctionnement unix
parwebreaker
 
Zabbix
parkamiloo2009
 
Meetup Systemd vs sysvinit
parChristian Charreyre
 
I le langage java d'una manière avancée introduction
parsabrine_hamdi
 
CD d’auto-installation de Nagios, Centreon et NaReTo
parguest3be047
 
Retour d'expérience : gérer des flux vidéos multiples de manière optimisée
parSilicon Comté
 
Déploiement pour l’hébergement d’architecture cliente et mise en place du Sel...
parOpenNebula Project
 
Moussasambe projet de securite zabbix
parmoussa sambe
 
Fully Automated Nagios Jm2L 2009
parFAN Fully Automated Nagios
 
Parinux 2009
parFAN Fully Automated Nagios
 
Les solutions libres pour les systèmes embarqués
parAlexandre LAHAYE
 
Synthese
parAlexis Pelhâte
 
Distro Recipes 2013 : Yocto / OpenEmbedded
parAnne Nicolas
 
Docker en Production (Docker Paris)
parJérôme Petazzoni
 
Vm ware
parJIngenieur
 
Important Vm Ware Infrastrucutre Slides
parnouari
 
Docker : quels enjeux pour le stockage et réseau ? Paris Open Source Summit ...
parJérôme Petazzoni
 
Journées du Logiciel Libre 2008
parFAN Fully Automated Nagios
 

Similaire à Mises à jour logicielles en environnement Linux Embarqué, petit guide et tour d'horizon

PDF
Embarquer Linux et des systèmes libres, méthodes et apports
parguest3be047
 
ODP
Comment travailler avec les logiciels Open Source
parChristian Charreyre
 
PDF
Linux et les systèmes embarqués
parStéphane Legrand
 
PPTX
Retour BreizhCamp 2023
parSpikeeLabs
 
ODP
Conference Informatique Embarquée Synergie-NTIC
parChristian Charreyre
 
PDF
Présentation CoreOS
pargcatt
 
PDF
Tv21 02-07 linuxembedded
parPascal Flamand
 
PPT
Virtualiastion des systèmes d'exploitations
parSGHIOUAR abdelfettah
 
PDF
Cours introduction au systeme d exploitation
parHassanSaadaoui2
 
PDF
Comment choisir le bon système d'exploitation pour un système embarqué.pdf
parAitAddiHajar
 
ODP
Fully Automated Nagios, Solutions Linux 2009
parFAN Fully Automated Nagios
 
PPTX
Gestion-des-parcs-informatiques Windows et Linux.pptx
parssusercbaa22
 
PDF
Point de vue sur les Systeme d'exploitation 2.pdf
parerdiskuajo
 
PDF
Sysadmin Day #5
parOlivier (DaffyDuke) Duquesne
 
PDF
Cours SE Gestion des périphériques - IG IPSET
parMedBechir
 
PDF
20120110 paris jug-packaging-natif
parHenri Gomez
 
PPT
LINUX Mise en place d’une exploitation industrialisée – automatisée – sécuris...
parJean-Antoine Moreau
 
PDF
REX Ansible
parNoël Bardelot
 
PDF
ch1_introduction_aux_systemes_embarques.pdf
parHoudaBezziane
 
PDF
Backdoors et rootkits_avancees
parUltraUploader
 
Embarquer Linux et des systèmes libres, méthodes et apports
parguest3be047
 
Comment travailler avec les logiciels Open Source
parChristian Charreyre
 
Linux et les systèmes embarqués
parStéphane Legrand
 
Retour BreizhCamp 2023
parSpikeeLabs
 
Conference Informatique Embarquée Synergie-NTIC
parChristian Charreyre
 
Présentation CoreOS
pargcatt
 
Tv21 02-07 linuxembedded
parPascal Flamand
 
Virtualiastion des systèmes d'exploitations
parSGHIOUAR abdelfettah
 
Cours introduction au systeme d exploitation
parHassanSaadaoui2
 
Comment choisir le bon système d'exploitation pour un système embarqué.pdf
parAitAddiHajar
 
Fully Automated Nagios, Solutions Linux 2009
parFAN Fully Automated Nagios
 
Gestion-des-parcs-informatiques Windows et Linux.pptx
parssusercbaa22
 
Point de vue sur les Systeme d'exploitation 2.pdf
parerdiskuajo
 
Sysadmin Day #5
parOlivier (DaffyDuke) Duquesne
 
Cours SE Gestion des périphériques - IG IPSET
parMedBechir
 
20120110 paris jug-packaging-natif
parHenri Gomez
 
LINUX Mise en place d’une exploitation industrialisée – automatisée – sécuris...
parJean-Antoine Moreau
 
REX Ansible
parNoël Bardelot
 
ch1_introduction_aux_systemes_embarques.pdf
parHoudaBezziane
 
Backdoors et rootkits_avancees
parUltraUploader
 

Mises à jour logicielles en environnement Linux Embarqué, petit guide et tour d'horizon

  • 1.
    Linux Embarqué Mises àjour logicielles en environnement Linux Embarqué, petit guide et tour d’horizon Pierre-Jean Texier Samedi 17 Novembre Toulouse, CDL 2018
  • 2.
  • 3.
    Pierre-Jean Texier • IngénieurLinux Embarqué Lafon Technologies • 28 ans • FOSS enthusiast • Contributions : U-Boot, Kernel Linux, Yocto/OE, ... • Co-auteur de ”Yocto for Raspberry Pi” et auteur dans GNU/Linux magazine et Open silicium (RIP) 1
  • 4.
    Sommaire 1. Mise àjour des systèmes embarqués 2. Les différents projets Open-Source 3. RAUC, WaRP7 & Yocto/OE 4. Mender, WaRP7 & Yocto/OE 5. Démos 6. Conclusion 2
  • 5.
    Mise à jourdes systèmes embarqués
  • 6.
    Pourquoi un systèmede mise à jour ? • Bugs Logiciels • Ajouts de fonctionnalités • Correctifs liés à la sécurité (CVE) 3
  • 7.
    Pourquoi si spécialdans l’embarqué ? • Accessibilité • Disponibilité • Fiabilité du réseau électrique • Système sur batterie, • Perte de tension (secteur) • Connectivités réseaux (pour les mises à jour distantes) • GPRS, 3G, LTE, WiFi, ... • Faible bande passante • Microcontrôleur, Microprocesseur, FPGA, ... • Durée de vie sur site supérieure à 10 ans 4
  • 8.
    Ok, mais quelscomposants ? 5
  • 9.
    fitImage • zImage /dts-v1/; / { description= "CDL fitImage"; #address-cells = <1>; images { kernel { description = "zImage"; data = /incbin/("./zImage"); type = "kernel"; arch = "arm"; os = "linux"; compression = "none"; load = <0x80800000 >; entry = <0x80800000 >; hash-1 { algo = "sha256"; }; }; ... 6
  • 10.
    fitImage • FDT fdt-1 { description= "Flattened Device Tree blob"; data = /incbin/("./imx7s-warp.dtb"); type = "flat_dt"; arch = "arm"; compression = "none"; ... }; }; • Firmware firmware -1 { description = "Firmware Cortex M4"; data = /incbin/("./main.bin"); type = "firmware"; arch = "arm"; compression = "none"; ... }; 7
  • 11.
    fitImage • Configuration configurations { default= "conf-1"; conf-1 { description = "CDL Configuration"; kernel = "kernel"; fdt = "fdt-1"; firmware = "firmware -1"; signature { algo = "sha256,rsa4096"; key-name-hint = "cdl-key"; sign-images = "firmware", "fdt", "kernel"; }; }; }; • Chargement => load mmc 0:1 0x85000000 fitImage => bootm 0x85000000 8
  • 12.
    Sur quelle base? • Fichiers • A éviter, difficile de garantir l’atomicité (-) 9
  • 13.
    Sur quelle base? • Fichiers • A éviter, difficile de garantir l’atomicité (-) • Gestionnaire de paquets • RPM, deb, opkg • rpm -ivh my-wonderful-app.rpm ? (-) • Facile (+) mais difficile à maintenir -> gestion des dépendances (-) • Non Atomique et non applicable pour l’embarqué (-) 9
  • 14.
    Sur quelle base? • Fichiers • A éviter, difficile de garantir l’atomicité (-) • Gestionnaire de paquets • RPM, deb, opkg • rpm -ivh my-wonderful-app.rpm ? (-) • Facile (+) mais difficile à maintenir -> gestion des dépendances (-) • Non Atomique et non applicable pour l’embarqué (-) • Container • Concept intéressant (+) • Implique de gérer les applications dans un container (-) 9
  • 15.
    Sur quelle base? • Fichiers • A éviter, difficile de garantir l’atomicité (-) • Gestionnaire de paquets • RPM, deb, opkg • rpm -ivh my-wonderful-app.rpm ? (-) • Facile (+) mais difficile à maintenir -> gestion des dépendances (-) • Non Atomique et non applicable pour l’embarqué (-) • Container • Concept intéressant (+) • Implique de gérer les applications dans un container (-) • Delta (atomique) • Faible bande-passante (+) • Complexe (-) • Risques sur la corruption du système de fichiers principal (-) 9
  • 16.
    Sur quelle base? • Fichiers • A éviter, difficile de garantir l’atomicité (-) • Gestionnaire de paquets • RPM, deb, opkg • rpm -ivh my-wonderful-app.rpm ? (-) • Facile (+) mais difficile à maintenir -> gestion des dépendances (-) • Non Atomique et non applicable pour l’embarqué (-) • Container • Concept intéressant (+) • Implique de gérer les applications dans un container (-) • Delta (atomique) • Faible bande-passante (+) • Complexe (-) • Risques sur la corruption du système de fichiers principal (-) • Image complète : Full OS • Le cas le plus courant dans l’embarqué • Facile à mettre en oeuvre (+) 9
  • 17.
    Quels mécanismes ? •En fonctionnement : • Non Atomique (quelques exceptions) • Donwtime très court • Qui ? : Package managers, AGL • Mode maintenance : initrd/initramfs • Robuste • Retour en arrière impossible si erreur • Downtime -> long • Qui ? : Android (avant Nougat) • A/B ou Seamless update : • Robuste, mais coûteux en espace de stockage • Retour en arrière possible si erreur • Downtime -> court • Toujours opérationnel • Qui ? : Android (depuis Nougat) 10
  • 18.
    Et comment ? •Mises à jour sur site • Pas de connectivité • Accès physique : • Gestion par clé USB/carte SD • Interactif • Déplacement d’un technicien eee • Mises à jour distantes : OTA • Pas d’accès physique : • HTTPS, FTP, ... • Pas d’intéraction • Serveur pour la gestion des périphériques (flotte) • Mise à jour programmée • Campagne de mise à jour • Inventaire des périphériques • Statut des périphériques • Version logicielle courante • Gestion des artefacts 11
  • 19.
    Exigences clés d’undispositif de mise à jour • Doit être capable de mettre à jour l’ensemble des composants • Bootloader = dangereux • Doit s’interfacer avec le Bootloader (e.g Environnement U-Boot) • Doit être Robuste (coupures de courant et pertes de connexions réseau) • L’opération doit être atomique = Pas d’installation partielle • Ne doit pas rendre le périphérique inutilisable (Fail-safe) • Notion de Rollback • Doit disposer d’un espace pour les données persistentes (Stateless FS) • Partition dédiée • Doit être sécurisé • Empêcher une action non autorisée • Doit permettre une gestion Locale et Distante (OTA) • Doit permettre d’effectuer des tests (Sanity check) avant validation 12
  • 20.
  • 21.
  • 22.
  • 23.
  • 24.
  • 25.
  • 26.
  • 27.
    Atomicité : Exempleschéma A/B • Démarrage sur A 18
  • 28.
    Atomicité : Exempleschéma A/B • Démarrage sur A • Mise à jour de B 18
  • 29.
    Atomicité : Exempleschéma A/B • Démarrage sur A • Mise à jour de B • coupure de courant ! 18
  • 30.
    Atomicité : Exempleschéma A/B • Démarrage sur A • Mise à jour de B • coupure de courant ! • Démarrage sur A 18
  • 31.
    Atomicité : Exempleschéma A/B • Démarrage sur A • Mise à jour de B • coupure de courant ! • Démarrage sur A • Mise à jour de B 18
  • 32.
  • 33.
    ”Etre capable derevenir sur une version stable (et fonctionnelle) lors de la détection d’un problème” 19
  • 34.
  • 35.
  • 36.
  • 37.
    Rollback : Quand? Plusieurs cas de figures : • Echec d’une mise à jour • Détecté par l’updater • Mise à jour réussie mais problème Noyau (Kernel Panic) • BUG logiciel ! • Mise à jour réussie mais problème sur l’applicatif métier • BUG logiciel ! 23
  • 38.
    Rollback : Scénario •Démarrage sur A 24
  • 39.
    Rollback : Scénario •Démarrage sur A • Mise à jour de B • Mise à jour du flag active_partition (flag bootloader) 24
  • 40.
    Rollback : Scénario •Démarrage sur A • Mise à jour de B • Mise à jour du flag active_partition (flag bootloader) • Reboot 24
  • 41.
    Rollback : Scénario •Démarrage sur A • Mise à jour de B • Mise à jour du flag active_partition (flag bootloader) • Reboot • Démarrage sur B • Anomalie de l’application principale 24
  • 42.
    Rollback : Scénario •Démarrage sur A • Mise à jour de B • Mise à jour du flag active_partition (flag bootloader) • Reboot • Démarrage sur B • Anomalie de l’application principale • Détection de l’anomalie • Reboot 24
  • 43.
    Rollback : Scénario •Démarrage sur A • Mise à jour de B • Mise à jour du flag active_partition (flag bootloader) • Reboot • Démarrage sur B • Anomalie de l’application principale • Détection de l’anomalie • Reboot • Rollback • Mise à jour du flag active_partition (flag bootloader) 24
  • 44.
    Rollback : Scénario •Démarrage sur A • Mise à jour de B • Mise à jour du flag active_partition (flag bootloader) • Reboot • Démarrage sur B • Anomalie de l’application principale • Détection de l’anomalie • Reboot • Rollback • Mise à jour du flag active_partition (flag bootloader) • Démarrage sur A 24
  • 45.
    Rollback : Fondamentaux1/2 Gestion des Kernel Panic : 25
  • 46.
    Rollback : Fondamentaux1/2 Gestion des Kernel Panic : • Utilisation de CONFIG_PANIC_TIMEOUT • Pour définir le timeout avant redémarrage sur un Kernel Panic 25
  • 47.
    Rollback : Fondamentaux1/2 Gestion des Kernel Panic : • Utilisation de CONFIG_PANIC_TIMEOUT • Pour définir le timeout avant redémarrage sur un Kernel Panic ”Sanity Check” : 25
  • 48.
    Rollback : Fondamentaux1/2 Gestion des Kernel Panic : • Utilisation de CONFIG_PANIC_TIMEOUT • Pour définir le timeout avant redémarrage sur un Kernel Panic ”Sanity Check” : • Après la mise à jour, il faut vérifier si le système est opérationnel avant de valider celle-ci : 25
  • 49.
    Rollback : Fondamentaux1/2 Gestion des Kernel Panic : • Utilisation de CONFIG_PANIC_TIMEOUT • Pour définir le timeout avant redémarrage sur un Kernel Panic ”Sanity Check” : • Après la mise à jour, il faut vérifier si le système est opérationnel avant de valider celle-ci : • Vérification de l’applicatif métier (UI, services, serveur, ...), • Vérification de la configuration système, • ... 25
  • 50.
    Rollback : Fondamentaux1/2 Gestion des Kernel Panic : • Utilisation de CONFIG_PANIC_TIMEOUT • Pour définir le timeout avant redémarrage sur un Kernel Panic ”Sanity Check” : • Après la mise à jour, il faut vérifier si le système est opérationnel avant de valider celle-ci : • Vérification de l’applicatif métier (UI, services, serveur, ...), • Vérification de la configuration système, • ... Mécanisme de redémarrage lors d’une défaillance : 25
  • 51.
    Rollback : Fondamentaux1/2 Gestion des Kernel Panic : • Utilisation de CONFIG_PANIC_TIMEOUT • Pour définir le timeout avant redémarrage sur un Kernel Panic ”Sanity Check” : • Après la mise à jour, il faut vérifier si le système est opérationnel avant de valider celle-ci : • Vérification de l’applicatif métier (UI, services, serveur, ...), • Vérification de la configuration système, • ... Mécanisme de redémarrage lors d’une défaillance : • Watchdog • Pour détecter les freezes • Solution matérielle 25
  • 52.
    Rollback : Fondamentaux2/2 Gestion des cycles de redémarrage répétitif (e.g U-Boot) : 26
  • 53.
    Rollback : Fondamentaux2/2 Gestion des cycles de redémarrage répétitif (e.g U-Boot) : • Implémentation Bootcount Limit • CONFIG_BOOTCOUNT_LIMIT et CONFIG_BOOTCOUNT_ENV • bootcount : variable incrémentée à chaque redémarrage • bootlimit : pour définir le nombre maximal de redémarrage • altbootcmd : séquence alternative si bootcount > bootlimit • upgrade_available : pour la gestion de bootcount 26
  • 54.
    Rollback : Fondamentaux2/2 Gestion des cycles de redémarrage répétitif (e.g U-Boot) : • Implémentation Bootcount Limit • CONFIG_BOOTCOUNT_LIMIT et CONFIG_BOOTCOUNT_ENV • bootcount : variable incrémentée à chaque redémarrage • bootlimit : pour définir le nombre maximal de redémarrage • altbootcmd : séquence alternative si bootcount > bootlimit • upgrade_available : pour la gestion de bootcount • Interaction Bootloader <-> userspace afin de positionner les variables • Utilisation de fw_setenv et fw_printenv 26
  • 55.
    Rollback : Fondamentaux2/2 Gestion des cycles de redémarrage répétitif (e.g U-Boot) : • Implémentation Bootcount Limit • CONFIG_BOOTCOUNT_LIMIT et CONFIG_BOOTCOUNT_ENV • bootcount : variable incrémentée à chaque redémarrage • bootlimit : pour définir le nombre maximal de redémarrage • altbootcmd : séquence alternative si bootcount > bootlimit • upgrade_available : pour la gestion de bootcount • Interaction Bootloader <-> userspace afin de positionner les variables • Utilisation de fw_setenv et fw_printenv Exemple : bootlimit=1 26
  • 56.
    Rollback : Fondamentaux2/2 Gestion des cycles de redémarrage répétitif (e.g U-Boot) : • Implémentation Bootcount Limit • CONFIG_BOOTCOUNT_LIMIT et CONFIG_BOOTCOUNT_ENV • bootcount : variable incrémentée à chaque redémarrage • bootlimit : pour définir le nombre maximal de redémarrage • altbootcmd : séquence alternative si bootcount > bootlimit • upgrade_available : pour la gestion de bootcount • Interaction Bootloader <-> userspace afin de positionner les variables • Utilisation de fw_setenv et fw_printenv Exemple : bootlimit=1 • Démarrage sur A, mise à jour de B 26
  • 57.
    Rollback : Fondamentaux2/2 Gestion des cycles de redémarrage répétitif (e.g U-Boot) : • Implémentation Bootcount Limit • CONFIG_BOOTCOUNT_LIMIT et CONFIG_BOOTCOUNT_ENV • bootcount : variable incrémentée à chaque redémarrage • bootlimit : pour définir le nombre maximal de redémarrage • altbootcmd : séquence alternative si bootcount > bootlimit • upgrade_available : pour la gestion de bootcount • Interaction Bootloader <-> userspace afin de positionner les variables • Utilisation de fw_setenv et fw_printenv Exemple : bootlimit=1 • Démarrage sur A, mise à jour de B • fw_setenv bootcount 0 26
  • 58.
    Rollback : Fondamentaux2/2 Gestion des cycles de redémarrage répétitif (e.g U-Boot) : • Implémentation Bootcount Limit • CONFIG_BOOTCOUNT_LIMIT et CONFIG_BOOTCOUNT_ENV • bootcount : variable incrémentée à chaque redémarrage • bootlimit : pour définir le nombre maximal de redémarrage • altbootcmd : séquence alternative si bootcount > bootlimit • upgrade_available : pour la gestion de bootcount • Interaction Bootloader <-> userspace afin de positionner les variables • Utilisation de fw_setenv et fw_printenv Exemple : bootlimit=1 • Démarrage sur A, mise à jour de B • fw_setenv bootcount 0 • fw_setenv upgrade_available 1 26
  • 59.
    Rollback : Fondamentaux2/2 Gestion des cycles de redémarrage répétitif (e.g U-Boot) : • Implémentation Bootcount Limit • CONFIG_BOOTCOUNT_LIMIT et CONFIG_BOOTCOUNT_ENV • bootcount : variable incrémentée à chaque redémarrage • bootlimit : pour définir le nombre maximal de redémarrage • altbootcmd : séquence alternative si bootcount > bootlimit • upgrade_available : pour la gestion de bootcount • Interaction Bootloader <-> userspace afin de positionner les variables • Utilisation de fw_setenv et fw_printenv Exemple : bootlimit=1 • Démarrage sur A, mise à jour de B • fw_setenv bootcount 0 • fw_setenv upgrade_available 1 • Démarrage sur B (bootcount=1) 26
  • 60.
    Rollback : Fondamentaux2/2 Gestion des cycles de redémarrage répétitif (e.g U-Boot) : • Implémentation Bootcount Limit • CONFIG_BOOTCOUNT_LIMIT et CONFIG_BOOTCOUNT_ENV • bootcount : variable incrémentée à chaque redémarrage • bootlimit : pour définir le nombre maximal de redémarrage • altbootcmd : séquence alternative si bootcount > bootlimit • upgrade_available : pour la gestion de bootcount • Interaction Bootloader <-> userspace afin de positionner les variables • Utilisation de fw_setenv et fw_printenv Exemple : bootlimit=1 • Démarrage sur A, mise à jour de B • fw_setenv bootcount 0 • fw_setenv upgrade_available 1 • Démarrage sur B (bootcount=1) • Si OK fw_setenv upgrade_available 0, MAJ validée 26
  • 61.
    Rollback : Fondamentaux2/2 Gestion des cycles de redémarrage répétitif (e.g U-Boot) : • Implémentation Bootcount Limit • CONFIG_BOOTCOUNT_LIMIT et CONFIG_BOOTCOUNT_ENV • bootcount : variable incrémentée à chaque redémarrage • bootlimit : pour définir le nombre maximal de redémarrage • altbootcmd : séquence alternative si bootcount > bootlimit • upgrade_available : pour la gestion de bootcount • Interaction Bootloader <-> userspace afin de positionner les variables • Utilisation de fw_setenv et fw_printenv Exemple : bootlimit=1 • Démarrage sur A, mise à jour de B • fw_setenv bootcount 0 • fw_setenv upgrade_available 1 • Démarrage sur B (bootcount=1) • Si OK fw_setenv upgrade_available 0, MAJ validée • Si NOK, redémarrage, bootcount > bootlimit, exécution de la commande altbootcmd, retour sur A 26
  • 62.
    Rollback : Gestiondu Watchdog • Interface = /dev/watchdog • Utilisation via systemd • Watchdog matériel : • RuntimeWatchdogSec • ShutdownWatchdogSec • Watchdog logiciel (pour les services) : ”keep-alive ping” [Unit] Description=FooBar application [Service] ExecStart=/usr/bin/foobarapp WatchdogSec=10s Restart=on-failure StartLimitInterval=5min StartLimitBurst=2 StartLimitAction=reboot ... 27
  • 63.
    Rollback : protection •Mécanisme vulnérable aux attaques : • Retour sur l’ancienne partition afin d’y exploiter une faille de sécurité • Utilisation TPM (Trusted Platform Module) • Utilisation d’un compteur (counter) • afin d’éviter qu’un attaquant ne remplace un nouveau logiciel sécurisé par un logiciel vulnérable plus ancien 28
  • 64.
  • 65.
    Comment empêcher uneinstallation non autorisée ? De façon générale : • Gestion des compatibilités (Même matériel != Même produit) • Contrôle d’intégrité Lié à la sécurité : • Communication sécurisée (OTA) • Cryptographie (signature/vérification) 29
  • 66.
  • 67.
  • 68.
  • 69.
    Hawkbit Eclipse hawkBit isa domain independent back-end framework for rolling out software updates 32
  • 70.
  • 71.
    RAUC Robust Auto-Update Controller •https://github.com/rauc • LGPLv2.1 • C & GLib • Client très léger (167.7Ko) • Mise à jour Symétrique/Asymétrique + flexibilité (data, appfs, ...) • Configurable par le fichier system.conf • Notion de Slot • U-Boot, Barebox, GRUB, EFI • Support PKCS#11 (HSM) • SD/eMMC, UBI, Raw NAND, SquashFS • HTTP(S), FTP, SSH 33
  • 72.
    RAUC • ”Bundle” auformat SquashFS et signé (x509) • Rollback non intégré (exemple rauc/contrib/uboot.sh) • Bootchooser Framework • BOOT_ORDER, BOOT_bootname_LEFT • rauc status mark-good & rauc status mark-bad • Utilisation des scripts U-Boot • Compatible casync (delta update) • Contrôlable via D-Bus • Notion de handlers et hooks -> customisation • Mise à jour locale (USB) ou distante (rauc-hawkbit) • Bien documenté mais ... • Très peu d’exemples pour l’intégration • Build System 34
  • 73.
    SWUpdate SWUpdate: software updatefor embedded system • https://github.com/sbabic/swupdate • Un mix de MIT, GPLv2 and GPLv2+ • C • Client léger (400Ko) • Mise à jour Symétrique/Asymétrique + flexibilité • Configurable par le fichier sw-description • XML, JSON et libconfig Exemple • U-Boot, GRUB, EFI • SD/eMMC, UBI, Raw NAND, NOR/SPI NOR • HTTP(S), FTP, SSH -> (libcurl) pour l’aspect networking 35
  • 74.
    SWUpdate • Archive CPIO(signature et chiffrement possible) • Rollback non intégré (quelques implémentaions disponibles) • IPC : Unix Domain Socket pour avoir le statut (progression) • Mise à jour locale (USB et serveur web) ou distante (Hawkbit) • Interface graphique en Lua pour le mode recovery (RescueGUI) • Gestion scripts pre/post install • Gestion microcontrôleur en UART (ucfw), gestion maître/esclave (SWU forwarder) • Bien documenté • Exemples sur raspberry-pi, beaglebone, wandboard -> (meta-swupdate-boards) • Build System 36
  • 75.
  • 76.
  • 77.
  • 78.
    Mender Mender is anend-to-end open source update manager for IoT • https://github.com/mendersoftware • Apache 2.0 • Solution Clé en main (client + serveur) • Client lourd (4.6Mo) • Mise à jour Symétrique seulement • 4 Partitions (Boot + RootFS A + RootFS B + Data) • U-Boot, GRUB • SD/eMMC, UBI, Raw NAND, NOR • HTTP(S) 39
  • 79.
    Mender • Archive TAR.mender (gestion signature via l’outil mender-artifact) • Rollback intégré • State Scripts pour la gestion des actions durant l’opération de mise à jour • Mise à jour locale (mode standalone) ou distante (Managed) • Hosted Mender (payant) • Infrastructure Docker • Facile d’intégration (Auto-patch) • mender -commit pour valider la mise à jour en mode standalone • Bien documenté • Exemples sur https://hub.mender.io/ • Build System 40
  • 80.
    Mender : StateScripts • Use cases : • Migration des données • Confirmation utilisateur (retry later) • ... 41
  • 81.
    Mender : HostedMender hosted mender 42
  • 82.
  • 83.
    Mender : GCP/Mender ”GoogleCloud IoT Core integrates with Mender.io to analyze issues and enable OTA software updates for IoT” 44
  • 84.
    UpdateHub An end-to-end solutionfor large scale over-the-air update of devices • https://github.com/updatehub • GPLv2 • Solution Clé en main (client + serveur) • Golang (mais passage prévu en Rust !) • Client léger (476ko) • Mise à jour Symétrique/Asymétrique + flexibilité • Configurable par le fichier cible_uhupkg.config Exemple • U-Boot, GRUB • SD/eMMC, UBI, Raw NAND, NOR • HTTP(S) 45
  • 85.
    UpdateHub • ”Package” signé •Rollback intégré • Contrôlable via plusieurs SDK : Go, Qt, Python • Unix Domain Socket • Mise à jour locale (USB) ou distante (Serveur UpdateHub -> e) • Bientôt une nouveauté ? • Bien documenté • Exemples sur raspberry-pi, beaglebone, wandboard, WaRP7, ... • Build System 46
  • 86.
  • 87.
    Mais aussi 1/2 •resin.io maintenant balena (Container) • Container Utilisateur (docker) (Delta Update -> librsync) • Mise à jour symétrique pour la partie core balenaOS • Read-Only rootFS • Integration Yocto/OE = meta-balena • Supporte seulement : SD/eMMC 48
  • 88.
    Mais aussi 2/2 •libostree (Delta) • ”Like git but for a root file system” • commit = rootfs • 1 repository = /ostree/repo et un ensemble de ”déploiements” stockés dans /ostree/deploy/... • Image initramfs (init.sh) • chroot dans /ostree/deploy/myos/234... • /usr = lecture seule • /var = persistant • Utilisé par AGL, Qt OTA, Flatpak, ... • Integration Yocto/OE = meta-updater 49
  • 89.
    RAUC, WaRP7 &Yocto/OE
  • 90.
    RAUC : system.conf •Configuration du système cible : system.conf • Dans meta-cdl/recipes-core/rauc (recette dérivée) [system] compatible=AwesomeProduct bootloader=uboot [keyring] path=/etc/rauc/ca.cert.pem [handlers] post-install=/usr/lib/rauc/post-install.sh [slot.rootfs.0] device=/dev/mmcblk1p2 type=ext4 bootname=A [slot.rootfs.1] device=/dev/mmcblk1p3 type=ext4 bootname=B 50
  • 91.
    RAUC : Bundle •Création d’un recette permettant la génération du paquet de mise à jour (Bundle) : cdl-bundle.bb DESCRIPTION = "RAUC bundle for Capitole du Libre" inherit bundle RAUC_BUNDLE_COMPATIBLE = "AwesomeProduct" RAUC_BUNDLE_VERSION = "v2018 -11-17-1" RAUC_BUNDLE_DESCRIPTION = "Simple Demo Bundle for CDL" RAUC_BUNDLE_SLOTS = "rootfs" RAUC_SLOT_rootfs = "core-image-base" RAUC_SLOT_rootfs[fstype] = "ext4" RAUC_KEY_FILE = "chemin/vers/development -1.key.pem" RAUC_CERT_FILE = "chemin/vers/development -1.cert.pem" • Possible aussi avec l’outil tmp/deploy/tools/rauc • bitbake rauc-native 51
  • 92.
    RAUC : Partitions •Création du fichier rauc.wks pour la définition des partitions part /boot --source bootimg-partition --ondisk mmcblk --fstype=vfat --label boot --active --align 4096 --size 20 part / --source rootfs --ondisk mmcblk --fstype=ext4 --label rootfs_A --align 8192 --extra-space 200 part / --source rootfs --ondisk mmcblk --fstype=ext4 --label rootfs_B --align 8192 --extra-space 200 part /data --ondisk mmcblk --fstype=ext4 --label data --size 128M --align 8192 --extra-space 0 bootloader --ptable msdos • Kickstart file pour la création des 4 partitions eMMC 52
  • 93.
    RAUC : Paramètresde l’image • Utilisation de systemd : # Use systemd as init system VIRTUAL-RUNTIME_init_manager = "systemd" DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit" VIRTUAL-RUNTIME_initscripts = "" DISTRO_FEATURES_append = " systemd wifi" • Intégration des éléments vitaux : CORE_IMAGE_EXTRA_INSTALL_append = " rauc rauc-hawkbit packagegroup -base u-boot-fw-utils kernel-devicetree " # Script pour la gestion du rollback IMAGE_BOOT_FILES_append = " boot.scr" • Encore un peu de configuration : IMAGE_FSTYPES_append = " ext4" WKS_FILES_imx7s -warp = "rauc.wks" 53
  • 94.
    RAUC : génération $:bitbake cdl-bundle • core-image-base-imx7s-warp.ext4 • core-image-base-imx7s-warp.wic.gz • cdl-bundle-imx7s-warp.raucb 54
  • 95.
  • 96.
    Mender : Configuration1/2 • Intégration avec U-Boot INHERIT += "mender-full" MENDER_FEATURES_DISABLE_append = " mender-grub mender-image-uefi" # Périphérique de stockage MENDER_STORAGE_DEVICE = "/dev/mmcblk1" # Périphérique de stockage (U-Boot) MENDER_UBOOT_STORAGE_INTERFACE = "mmc" MENDER_UBOOT_STORAGE_DEVICE = "0" # Script U-Boot IMAGE_BOOT_FILES_append = " boot.scr" 55
  • 97.
    Mender : Configuration2/2 • meta-cdl/recipes-bsp/u-boot/u-boot-mender-warp7.inc FILESEXTRAPATHS_prepend := "${THISDIR}/u-boot-fslc:" SRC_URI_remove = " file://0005-fw_env_main.c-Fix-incorrect-size-for-malloc-ed-strin.patch " SRC_URI_append = " file://0001-warp7-add-mender-requirements.patch " MENDER_UBOOT_AUTO_CONFIGURE = "0" BOOTENV_SIZE = "0x2000" • Ajout des variables CONFIG_BOOTCOUNT_ENV et CONFIG_BOOTCOUNT_LIMIT +CONFIG_BOOTCOUNT_LIMIT=y +CONFIG_BOOTCOUNT_ENV=y 56
  • 98.
    Mender : Paramètresde l’image • Utilisation de systemd : # Use systemd as init system VIRTUAL-RUNTIME_init_manager = "systemd" DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit" VIRTUAL-RUNTIME_initscripts = "" DISTRO_FEATURES_append = " systemd wifi" • Configuration Artefact et Serveur : MENDER_ARTIFACT_NAME = "CDL-release -1" MENDER_SERVER_URL = "https://hosted.mender.io" MENDER_TENANT_TOKEN = "..." 57
  • 99.
    Mender : génération $:bitbake core-image-base • core-image-base-imx7s-warp.sdimg • core-image-base-imx7s-warp.mender • Signature de l’artefact : $: ./mender-artifact sign core-image-base-imx7s-warp.mender -k ./private.key 58
  • 100.
  • 101.
  • 102.
  • 103.
  • 104.
  • 105.
    Démos • Mender ModeStandalone • Mender Mode Hosted Mender • RAUC 62
  • 106.
  • 107.
    Conclusion Ce qu’il fautretenir : • Un mécanisme de mise à jour est obligatoire (le penser au début du projet) • Toujours déployer un logiciel bien testé • Bien tester les différentes solutions • Oublier les solutions ”Maison” • FOSS 63
  • 108.