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

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 !