Suport technique et veille technologique

Planet Libre  -  Renault : La sécurité, l'obsolescence et la maintenance des systèmes embarqués

 -  Novembre 2017 - 

Il est assez banal de dire que de plus en plus d'équipements modernes sont connectés au réseau. Cela apporte de nouvelles fonctionnalités, la possibilité d'améliorer le produit même une fois vendu par des mises à jour mais aussi des problèmes de confidentialité et de sécurité.

Les systèmes embarqués sont particulièrement concernés par ces problématiques, que les industriels traitent parfois mal et dont les consommateurs sont rarement dans le vrai également.

C'est de cette problématique dont on va parler.

Obsolescence programmée ?

Ce terme revient souvent dans ce genre de discussions. Que l'abandon du support d'un produit, comme par exemple l'absence d'une mise à jour Android, ou que justement la mise à jour de trop rend le système trop lent (cas de certains iPhone) serait une pratique digne de l'obsolescence programmée.

Globalement c'est faux. L'obsolescence programmée est une pratique supposée où un constructeur fragilise **volontairement** son produit afin de nécessiter un remplacement régulier pour augmenter ses ventes.

Le mot clé est donc l'aspect volontaire. Qui est difficile en réalité à constater. Et certains oublient aussi l'aspect de l'équilibre entre le prix et la qualité. Un produit bas de gamme va minimiser la qualité des matériaux par exemple pour que cela coûte moins cher au client. Il est donc normal que le produit dure moins longtemps. Cette question du compromis dans la réalisation du produit est l'essence même du travail d'un ingénieur et de la création de différentes gammes de produits, on ne peut assimiler cela à de l'obsolescence programmée qui consiste en un sabotage.

Je ne vais pas m'étendre beaucoup sur le sujet, il y a trois articles de blog (ici, là et là-bas) qui traitent bien de la question de l'obsolescence programmée qui reste une pratique à priori confidentielle. Mais le célèbre reportage d'Arte sur le sujet a mis en lumière cette pratique avec de mauvais exemples et certains le voient du coup... partout.

En tout cas on ne m'a jamais demandé de saboter mon propre produit, et aucun de mes collègues ou connaissances non plus. Par contre il arrive que certains bogues ne soient jamais corrigés, faute de temps ou de ressources financières pour les traiter.

De la question du progrès logiciel

Certains produits, comme nos ordinateurs ou téléphones portables, peuvent vivre des années sans problèmes. Et ces outils à usage assez génériques peuvent exécuter du logiciel conçu bien après la réalisation du produit.

Mon ordinateur portable personnel actuel date de 2011, il est passé de Fedora 16 à 27, de Windows 7 à 10, de Firefox 7 à Firefox 56, de GNOME 3.0 à GNOME 3.26, de Linux 3.1 à Linux 4.14, etc.

Ce sont des millions de lignes de code ajoutées depuis, le Web a beaucoup grossi entre temps avec du JavaScript devenu omniprésent et des sites devenant de plus en plus des applications complètes. Le contenu multimédia s’alourdit, passant du 720p à 4K pour les vidéos ou les photos. Le chiffrement s'est généralisé également dans les communications ou le stockage.

J'ai constaté peu à peu un ralentissement de ma machine, la consommation de la mémoire a monté (j'ai du rajouter 4 Gio récemment) alors que mon usage, fondamentalement n'a pas changé.

Ce phénomène n'a rien de nouveau, cela suit la loi de Wirth.

C'est un phénomène naturel. Les logiciels évoluent pour ajouter des fonctionnalités (pour répondre à des besoins des utilisateurs). Il est impossible de proposer du logiciel plus moderne tout en espérant une consommation en ressource identique indéfiniment. Soit il faut utiliser un produit qui n'évoluera plus fonctionnellement (cas de beaucoup d'outils simples et légers), ou alors il faudrait beaucoup de ressources financières et humaines pour maintenir plusieurs déclinaisons du logiciel dans le temps. Ce que l'on abordera plus tard.

Ce que la loi de Wirth n'explique pas ou mal, c'est que l'évolution du matériel se produit de manière globale, mais localement un produit a un matériel plutôt figé. Si le matériel évolue mais que les logiciels n'exploitent pas cette puissance supplémentaire, ce serait du gâchis. Donc la consommation des programmes évoluent pour bénéficier de ces ressources disponibles. Et forcément cela se fait au détriment des machines qui accusent d'un certain âge. Cela est encore plus visible sur les téléphones qui ont fait un saut de performances spectaculaire en très peu d'années.

Certains veulent exploiter la machine le plus longtemps possible (donc disons 10-15 ans) tout en bénéficiant de ces évolutions. Ce n'est pas possible sans concession. Il faut faire des choix, en payant cher des produits pour les maintenir longtemps, en renonçant partiellement à ce progrès, en changeant de machine ou renoncer à des usages. Typiquement, aller sur le Web avec une machine de 2002 doit être possible, mais cela ne doit pas être une expérience très agréable en dehors de quelques sites très légers.

Et pour un téléphone bas de gamme, conçu pour être tout juste capable de lancer les applications populaires de l'époque, ne peut pas soutenir la charge d'une mise à jour des dites applications sur le long terme.

Et après toute cette explication, comment associer cela à de l'obsolescence programmée alors que cette lourdeur progressive provient de logiciels extérieurs à la conception du matériel ? Ce n'est pas Intel qui a rendu Firefox plus lourd avec le temps.

La sécurité

La sécurité est devenue depuis quelques années un sujet de premier plan pour tout un nouveau panel de produits. Avec une connexion accessible depuis Internet, il devient possible d'essayer d'infiltrer ces produits qui peuvent être accessibles non stop pendant des années et sans maintenance active (il n'y a pas un administrateur système pour surveiller le réseau domestique d'un particulier).

Du coup, pour combler les failles, il devient nécessaire de mettre à jour le produit. Parfois changer l'outil interne, ou le protocole employé (le MD5 n'est plus un moyen fiable pour vérifier l'intégrité d'un fichier ou d'un certificat).

Du coup pour améliorer la sécurité, on doit les faire évoluer. Ce qui peut nous faire revenir sur le point précédent où le logiciel devient trop lourd pour le matériel considéré ce qui rend compliqué la conciliation des deux.

L'autre problème est... le coût. Quand on achète un produit type téléphone, un réfrigérateur connecté, un modem ou autre, nous achetons le produit à un prix fixe, parfois très dérisoire car très bas de gamme. Sauf que d'assurer une maintenance sur 10-15 ans, cela coûte très cher. Car il devient nécessaire de maintenir plusieurs versions du logiciel (suivant l'âge du matériel et de ses successeurs à maintenir), de tester chaque mise à jour sur chaque produit, tester son déploiement, corriger les éventuels ratés auprès des clients, communiquer auprès d'eux (manuels explicatifs, mise à jour d'un site Web possiblement en plusieurs langues, courriers / courriels envoyés en nombre).

Admettons que pour maintenir un modèle d'un téléphone portable pendant 15 ans il faut une équipe de 10 personnes à temps plein (ce qui n'est pas irréaliste car cela demande beaucoup de travail pour corriger la moindre faille ou les bogues découverts, sachant que le logiciel dépend également du lieu vendu pour des raisons de contraintes légales). En admettant qu'ils ne sont pas mal payés (et qu'il leur faut du matériel adéquat), cela peut revenir par employé à un coût annuel pour l'employeur d'environ 100 000€. Donc 1 million d'euros par an. Sachant qu'un modèle lambda d'un téléphone peut être vendu auprès du million d'unités au total, cela reviendrait a un coût de 10-15 millions d'euros rien que pour la maintenance une fois le produit vendu. Pour des téléphones à 100€, cela représente 10% du budget global du produit ! Ce n'est clairement pas négligeable. Et je ne parle pas des cas de produits moins vendus qui méritent pourtant la même maintenance.

Le Libre comme solution ?

Certains pensent qu'un produit embarqué, s'il est fait avec du logiciel libre, il est aisé de le maintenir pour proposer des mises à jour du produit pendant des années après l'abandon par son constructeur. La réalité est plus complexe.

Pour les projets assez puissants pour accueillir un système d'exploitation Linux (cas des téléphones par exemple), le système est rarement compilé de zéro à la main. Pour gagner du temps, il existe des solutions comme Yocto ou buildroot (et ses déclinaisons OpenWRT ou ptxdist) pour compiler l'ensemble des logiciels (dont le noyau) pour notre système afin d'obtenir une image qu'on pourra installer sur la cible. Je les présenterais dans un autre article.

Seulement, chaque processeur ou plateforme a ses spécificités. C'est pourquoi, les concepteurs des puces (Qualcomm, Texas Instrument, Broadcom, Freescale / NXP et autres) fournissent les solutions citées plus haut avec les changements nécessaires pour exploiter la plateforme. Très souvent le noyau Linux et le chargeur de démarrage U-Boot accueillent une grande liste de correctifs maison (plusieurs centaines).

Cela est bien, car nous n'avons pas à développer nous même les pilotes pour exploiter les fonctions du processeur (notamment pour la couche graphique) et dans l'essentiel cela reste du code libre. Cependant ces correctifs sont gros et souvent… mal réalisés. Faute de temps et de ressources, les constructeurs ne cherchent pas à concevoir des correctifs qui finiront dans le projet officiel. Leur but est que cela fonctionne avec le noyau fourni aux développeurs / intégrateurs. Du coup nous nous retrouvons avec un noyau et un chargeur de démarrage figé, car Linux évolue très vite et il est très difficile de porter ces correctifs pour une autre version. Et comme cela est trop souvent trop mal fait (utilisation d'une pile logicielle différente que celle du noyau pour une fonction donnée, comme le SPI ou le réseau par exemple, code spaghetti avec lien fort entre le tronc commun et leur pilote, etc.) il est difficilement imaginable de porter cela sur le noyau officiel directement.

Pas mal de personnes essayent pourtant de porter le nécessaire sur le noyau officiel. Mais cela demande beaucoup de temps (aujourd'hui le support du téléphone N900 est quasiment complet, mais il aura fallu 8 ans après sa sortie !) et c'est souvent au prix de fonctionnalités partielles (performances graphiques ou réseaux plus faibles, gestion de l'énergie douteuse). Sans collaboration du fondeur, c'est une tâche globalement vouée à l'échec étant donné le rythme de sortie des composants. Puis le fabricant de la puce bosse déjà sur la plateforme suivante. Ils n'ont pas le temps, ni l'envie, de s'attarder sur un produit qui n'a plus d'avenir.

Et même dans le cas où ce serait possible, il y a des sacs de nœuds dans l'architecture du système. Si vous souhaitez profiter par exemple des dernières tablettes Wacom sur votre machine, il faudra un noyau récent. En admettant que vous avez un noyau LTS un peu ancien comme la 3.4, il faudra rétro-porter cette fonctionnalité. Cela signifie récupérer le pilote mais souvent d'autres commits sur le sous-systèmes des périphériques entrées. Mais le noyau ne fait pas tout, il faut également que l'interface graphique propose de quoi configurer et exploiter le matériel. Donc par exemple en récupérant du travail effectué sur les versions récentes de GTK+ et de GNOME. Cela peut donc représenter beaucoup de travail, sur beaucoup de composants, et il faudra tester bien sûr du bon fonctionnement, de la sécurité et de la maintenance de tout ceci.

Bref, l'aspect libre peut aider bien sûr à maintenir un produit plus longtemps. D'ailleurs les initiatives du genre OpenWRT, CyanogenMod / LineageOS permettent de maintenir à jour certains produits embarqués plus longtemps que le support officiel du constructeur. Mais cela se fait souvent au détriment de certaines fonctionnalités matérielles.

Solutions ?

Je pense que la solution ne peut se passer de l'aide des industriels, qui eux-mêmes ne peuvent pas se permettre à un coût fixe d'une maintenance complexe sur une très longue durée. Imposer légalement une durée minimale de support conduirait à une hausse de prix d'achat inévitable de tous ces biens.

Une autre solution serait d'évoluer vers une tarification en tant que service. À savoir payer pour une durée de maintenance souhaitée. Si l'utilisateur souhaite 10 ans de maintenance, il le pourra, au prix d'un abonnement ajusté en conséquence. Je pense que c'est la seule solution, notamment pour les produits vendus à un volume moyen ou faible, d'avoir une maintenance dans le temps à la hauteur, sans rendre le produits inutilisable ou trop cher à l'achat.

La solution libre et gratuite me semble difficilement possible. Il suffit de voir qu'aucune distribution purement communautaire gratuite pour x86 n'arrive à gérer une maintenance de plus de 5 ans. Pourtant la plateforme est plus simple et plus standard. Donc aller au delà me paraît difficile. Car ce n'est pas une tâche aisée, ni très passionnante. Il faut en effet du savoir faire du matériel et beaucoup de temps.

Après bien entendu, les constructeurs ont leur part à jouer, en s'impliquant d'avantage dans le noyau officiel (qui pourrait lui également avoir une politique plus adaptée à ces besoins, en ayant une API interne plus stable). Il faut également réduire la surface d'attaque au maximum, n'offrir l'accès au réseau que lorsque la plus valu est réelle. Ce genre de décisions aideraient à avoir une meilleure sécurité dans le temps de ces plateformes.

Original post of Renault.Votez pour ce billet sur Planet Libre.

par Renault