Journal Et si on parlait de microcodes (firmware) open source pour serveur

Posté par  (site Web personnel) . Licence CC By‑SA.
64
2
juin
2021

Ils sont souvent ignorés mais ils sont aujourd’hui impliqués dans une part grandissante des attaques sur les systèmes informatiques. Souvent propriétaires, peu mis à jour car trop souvent considérés comme faisant partie intégrante du matériel, ils représentent pourtant des niveaux de complexités proches des systèmes d’exploitation modernes, et fournissent des accès en mode privilégié. Leurs mises à jour doivent être considérées et effectuées.

Depuis quelques années il existe des alternatives aux logiciels propriétaires (AMI MegaRAC, Dell iDRAC, HPE iLO, AMI Aptio) qui se développent pour les serveurs, on peut notamment citer les projets coreboot , linuxboot qui s’adressent à la partie BIOS des systèmes, et OpenBMC qui vise les cartes de contrôle à distance.

Ces projets ont longtemps été ignorés par les constructeurs, considérés comme immatures ou trop disruptifs par rapport à un usage standard de ces logiciels. Toutefois, cette situation pourrait rapidement évoluer suite à l'annonce d’AMI de fournir des solutions libres sur github conjointement avec la fondation Open Compute et de les proposer à ses clients OEM (Original Equipment Manufacturer) ou ODM (Original Design Manufacturer). Les codes sources de ces logiciels sont disponibles ici pour la partie BIOS nommé Aptio OpenEdition, et ici pour la partie matérielle de gestion à distance nommée MegaRAC OpenEdition chez AMI. Ils ciblent principalement la plateforme TiogaPass, un serveur Open Compute bi Xeon d’Intel.

Coreboot existe depuis de nombreuses années mais n’a pu se développer sur serveur que dernièrement par manque d’intérêt initial (ou d’envie) de la part des fondeurs (notamment Intel). Cette position a pu évoluer grâce à la publication des Firmware Support Package Intel sur Github et leurs usages simplifiés. Ces FSP contiennent du code propriétaire de bas niveau qui a pour objectif d’initialiser la plateforme à son strict minimum (essentiellement au travers du démarrage des interfaces mémoires, de la configuration des cœurs processeurs et du réseau de cohérence de cache QPI). Même si le FSP d’Intel ne représente pas une solution entièrement libre, son usage réduit drastiquement la surface d’attaque liée a du code propriétaire et permet aux logiciels de bas niveau libre d’exister sur des plateformes qui jusqu’à présent en étaient totalement dépourvues (dans le domaine x86, nous verrons que des alternatives sur ARM et/ou IBM Power existent).

Intel a en parallèle lancé le projet minplatform basé sur EDK2 une implémentation open source du standard UEFI qui est repris par AMI.

OpenBMC vise quant à lui les systèmes de contrôle à distance des serveurs. Il est basé sur des technologies embarquées libres comme Yocto (https://www.yoctoproject.org/) et OpenEmbedded. Il utilise de manière intensive DBUS et systemd du projet freedesktop afin d’assurer le démarrage du système. OpenBMC en est à la version 2.9 du projet et est déployé massivement chez les GAFA. Le support de fonctions avancées comme les Root of Trust matériel sur composant Aspeed ou HPE GXP sont effectifs et permettent d’assurer de haut niveau de sécurité, en signant l’ensemble de la pile logicielle à chacune des étapes critiques.

Alors pourquoi ces technologies ne sont-elles plus massivement adoptées, quels sont vraiment leurs apports ? Quelles sont leurs limitations, et que peut-on en espérer à moyen terme ?

On peut citer comme premier apport la possibilité d’auditer le code source des logiciels de bas niveau permettant d’apporter un système de sécurité transparent tout en réduisant la dépendance à un fournisseur. Cet audit ne peut toutefois pas être complet pour le moment, en raison de la nécessité de continuer à utiliser des blobs binaires pour construire une solution libre fonctionnelle sur matériel x86. Malgré cela, l'empreinte de ces blobs reste très faible, et le niveau de transparence obtenu reste bien plus élevé qu’avec une solution propriétaire.

Un second apport réside dans la capacité d'adaptabilité de ces solutions par rapport à une approche propriétaire qui impose une vision stricte de la manière d’administrer un serveur. L’apport des logiciels libres dans ce cas est fort, et les fonctions de gestion à distance peuvent être plus facilement intégrées au plus près du matériel dans l’optique de faciliter leur fonctionnement et d’en améliorer leurs performances. Le matériel s’adapte alors à l'environnement de son usager et non l’inverse.

Comme malheureusement beaucoup de projets libres, certaines fonctions sont manquantes. Ces fonctions peuvent parfois être critiques, et doivent être implémentées. On peut citer deux exemples. Le premier repose sur la mise en œuvre d’un canal de communication logique entre les BIOS et les systèmes de contrôles à distance afin d'échanger des données (typiquement des erreurs matérielles détectées par les processeurs centraux). Ce canal de communication n’est pas standardisé, et repose la plupart du temps sur des systèmes propriétaires à base de bus basse vitesse peu utiles, ou PCIe qui peuvent induire des problématiques de sécurité. Leur standardisation serait un vrai plus. Le second problème auquel on peut être confronté repose sur la richesse des logiciels mise en œuvre pour parfois résoudre un problème simple. OpenBMC typiquement est un logiciel complexe qui fonctionne mieux lorsque celui-ci est optimisé pour une plateforme cible. Son architecture et son approche technologique en font une solution relativement lourde à mettre en œuvre. La possibilité d’avoir une version minimaliste par défaut serait vraiment un plus.

Ces limitations n’en réduisent pas moins l’engouement actuel pour ces logiciels libres. De grands constructeurs s’y intéressent dont on peut citer HPE (mon employeur actuel), Wiwynn, IBM ainsi qu’AMI. Les efforts portés à la qualité au travers des travaux menés par HPE via le projet libre OSFCI (https://osfci.tech et https://github.com/hewlettpackard/osfci) permettent aux utilisateurs de construire leur propre pile logicielle et de la valider sur matériel réel en ligne avant tout déploiement local. Cette approche automatisable permet de limiter les mauvaises surprises en phase d'intégration et de tester toute fonctionnalité nécessaire de manière collaborative.

Cette approche a permis la mise en œuvre d’un programme beta international par HPE (je le pilote). Il est à noter que certaines grandes entreprises, de taille plus petite (on peut nommer Criteo par exemple), participent à l’effort pour que ces solutions soient aussi viables et fonctionnelles dans des infrastructures plus classiques que celles des géants du net.

Il reste encore beaucoup de chemin à parcourir avant que ces logiciels deviennent un standard sur nos serveurs, mais l’engouement est grandissant. L’existence de deux modèles de sécurité distincts (propriétaire ou ouverte) permet d'assurer la pérennité des logiciels de managements de bas niveau libres. Ils introduisent de nouveau mode de déploiement qu’il est intéressant d’explorer, et surtout permettent aux membres des communautés de participer activement à leurs évolutions. Alors pourquoi attendre !

  • # Sujet rarement débattu, merci

    Posté par  . Évalué à 8 (+7/-0).

    Ça fait plaisir de lire un bon article sur ce sujet obscur et peu visible, merci !

    Juste une petite interrogation : « peu mis à jour car trop souvent considérés comme faisant partie intégrante du matériel ». Sur les serveurs Dell il y a souvent des mises à jour des plateformes BMC/IDRAC/BIOS etc… Et ce plusieurs années après l'arrêt de la gamme. Par exemple les Poweredge Rx10 ont eu des mises à jour en 2020 par exemple. Je trouve que les grands constructeurs sont assez sérieux pour une fois. Me goure-je ?

    • [^] # Re: Sujet rarement débattu, merci

      Posté par  (site Web personnel) . Évalué à 7 (+5/-0).

      Je vais avoir du mal a dire l'inverse travaillant pour HPE. Mais je suis plutot d'accord avec toi les constructeurs sont de plus en plus serieux sur ces sujets. D'autre part le legislateur aide aussi. Les lois contre l'obscolescnce programmee impose aussi de mettre a disposition les mises a jours critiques gratuitements sur les nouveaux produits sur des periodes definies (de memoire 8 ans, je ne suis pas un specialiste de ce sujet, travaillant sur des thematiques open source, je ne m'inquiete pas trop de la disponibilite des logiciels)

      • [^] # Re: Sujet rarement débattu, merci

        Posté par  (site Web personnel) . Évalué à 3 (+2/-1).

        Sauf erreur, même si un constructeur propose une mise à jour de ses blobs, il reste nécessaire que les administrateurs de machine fassent des démarches actives pour les rechercher. Ça ne se fait jamais tout seul, non ? Comme en plus ces logiciels sont assez invisibles…
        Ce qui m’interroge dans cette dépêche, c’est la surface d’attaque offerte par ces blobs. J’ai longtemps vécu dans l’idée naïve qu’ils étaient totalement inaccessibles à l’utilisateur ; à l’exception de manœuvres aux démarrages. Y a-t-il beaucoup d’attaques connues basées sur eux ? Via le réseau ? Ou bien seulement des effets de bords autorisés/non mitigés comme les récentes méthodes d’extraction de données des Rams par influence entre cellules ?

        « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

        • [^] # Re: Sujet rarement débattu, merci

          Posté par  . Évalué à 6 (+4/-0).

          pour iLO par exemple, ça a l'air pas génial

          https://www.sstic.org/2021/presentation/hpe_ilo_5_security_go_home_cryptoprocessor_youre_drunk/

          il y a d'autres docs dans ce doc avec des previous research qui font un peu peur. Conclusion: séparez physiquement les réseaux !!!

        • [^] # Re: Sujet rarement débattu, merci

          Posté par  . Évalué à 6 (+4/-0).

          il reste nécessaire que les administrateurs de machine fassent des démarches actives pour les rechercher.

          Et les installer. Et il faut rebooter. Des serveurs. Comment on fait après pour la course au gros uptime, hein?

          En dehors des serveurs, qui j'espère ont tous une double banque, il y a le problème de risquer de briquer le matos, aussi.

          Je pense que ces problèmes sont aussi assez important dans l'explication de la non mise à jour.

          • [^] # Re: Sujet rarement débattu, merci

            Posté par  (site Web personnel) . Évalué à 7 (+5/-0).

            Alors je suis d'accord avec ton explication, mais sauf erreur de ma part, tout ne requiert pas un reboot.

            Par exemple, les iLo, iDrac et autre trucs d'admin distant peuvent être mis à jour et relancé sans impacter l'uptime du serveur.

            Mais en effet, c'est pas le cas du bios et des X firmwares embarqués

            On peut aussi rajouter le fait que c'est la plaie pour la mise à jour, genre la procédure en elle même.

            • [^] # Re: Sujet rarement débattu, merci

              Posté par  (site Web personnel) . Évalué à 9 (+7/-0).

              Oui je confirme il est de plus en plus rare qu'un reboot complet de la plateforme soit necessaire.

              L'essor des firmware open source permet d'envisager des alternatives pertinentes et surtout des innovations qui n'ont pas reussi a emerger sur des logiciels proprietaires.

        • [^] # Re: Sujet rarement débattu, merci

          Posté par  (site Web personnel) . Évalué à 7 (+5/-0).

          Exact, meme si il existe des moyens d'automatiser cela, ces moyens sont rarement mis en oeuvre. Il existe comme sur tous logiciels une surface d'attaque qui ne peut pas etre consideree comme nulle a partir du moment ou ceux-ci sont connectes au reseau ou a leur hote. Les contructeurs font un effort important pour patcher ces bugs des que les CVE sont ouverts, mais il faut pour autant que la mise a jour soit effectuee sur toutes les plateformes.

  • # Power

    Posté par  . Évalué à 5 (+3/-0).

    Du côté de la plateforme Power d'IBM, Raptor Engineering travaille sur Kestrel, un SoC dédié au BMC implémenté dans un FPGA et dont les sources sont libres (GPLv3).
    Il y a pas mal d'articles explicatifs sur le blog talospace.com

    La fondation OpenPower travaille elle sur LibreBMC, qui suivrait le même principe que Kestrel, un BMC sur ISA Power.

  • # Des produits utilisables?

    Posté par  . Évalué à 5 (+4/-0).

    Existe t il un serveur ou Pc déjà commercialisé? Même en se passant des fonctions manquantes. Ou y a t t'il un modop relativement simple pour en profiter ?

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.