Journal Et si on parlait un peu d'OpenBMC....

… à travers un petit journal ou en direct la semaine prochaine pour les parisiens (Meetup OpenBMC parisien)

Il y a très longtemps que je n'ai pas écrit de journal, et j'espère ne pas être trop rouillé, et que tout le monde va bien. La vie m'a emmenée aux USA ou je travaille maintenant pour HPE dans l'équipe des technologies avancées, ou mon role est de m'occuper de tout ce qui est associé au monde de l'open hardware (ou matériel libre). Je supervise ainsi nos développements autours d'OpenBMC et microcodes libres, dans l'optique d'intégrer ces technologies dans les produits HPE.

On ne va pas parler d'HPE ici, mais plutot d'OpenBMC. Pour ceux qui ne connaissent pas ce projet et vous êtes probablement nombreux, l'objectif de celui-ci est de remplacer le logiciel propriétaire des contrôleurs de serveurs par un équivalent libre. Le projet est hébergé par la linux fondation et a un site web ( https://www.openbmc.org/ ). Il est bien entendu disponible sur github (https://github.com/openbmc/).

Un BMC moderne s'est un O/S avec une myriade d'applications qui ont pour objectif de gérer la santé de votre serveur. Ainsi ce logiciel prend en charge, le systeme de refroidissement, la gestion des erreurs matérielles (et leurs recouvrements éventuelles), le déploiement initial d'O/S, la sécurité de la platforme, les mises à jours des microcodes des cartes périphériques, etc …

Pour les aventuriers n'hésitez pas

L'apport du libre dans ce domaine repose principalement sur deux avantages particuliers.

• La possibilité d'auditer le code source et de basculer d'un modèle de sécurité de confiance (où l'utilisateur délègue la sécurité de sa plateforme à son fournisseur) à un modèle d'appropriation (où l'utilisateur a en charge la sécurité de la plateforme et accès aux outils lui permettant de la garantir comme des mécanismes de signatures électroniques employés dans les silicons root of trust).
• La possibilité d'ajouter ses propres fonctionnalités dans le cadre de son propre environnement (démarrage différent, système de refroidissement immersif etc …). Un exemple simple, pour les usagers qui ont à gérer de grands parcs, la possibilité de démarrer les BMC via des boots réseaux sur des serveurs centraux dans l'optique de simplifier les mises à jours en centralisant le stockage des firmwares.

Il existe bien entendu d'autres avantages à utiliser des versions libres de BMC et nous les approfondiront dans de futurs journaux en fonction de l'appétence que vous pourriez avoir sur ce sujet.

OpenBMC n'est pas l'unique solution libre qui existe pour BMC. Il existe aussi U-BMC (https://github.com/u-root/u-bmc) une alternative qui repose sur le kernel linux et un environnement utilisateur basé sur U-ROOT écrit en Go. OpenBMC est toutefois l'environnement le plus proche des environnements professionnels tel que vous le connaissez actuellement et s'est pourquoi j'ai focalisé ce premier journal sur celui-ci.

Alors comment fonctionne OpenBMC ?

OpenBMC est une "distribution" linux basée sur OpenEmbedded / Yocto (https://www.yoctoproject.org/) et utilise les outils de construction associes. Pour chaque serveur il est nécessaire de construire une image spécifique à la machine cible.

OpenBMC est une collection d'applications qui reposent sur l'infrastructure D-BUS pour assurer les mécanismes de synchronisations inter processus. Un exemple typique, l'application qui gère les sensors thermiques est perpétuellement "consultée" par l'application qui va gérer le système de refroidissement dans l'optique de l'optimiser.

Pourquoi utiliser Yocto ? Les BMC sont des équipements embarqués qui reposent sur des SoC principalement fabriqués par ASpeed (https://www.aspeedtech.com/server_ast2500/), Nuvoton (https://www.nuvoton.com/products/cloud-computing/ibmc/) et dans le cas de HPE, et bien HPE (je vous invite au meetup si vous voulez en savoir plus, ou dans un futur journal). Ces SoC sont basés sur des processeurs ARM basse consommation, avec peu d'environnement mémoire (généralement inférieur à 512Mo), mais surtout un espace de stockage très restreint (de 16 à 32Mo). Chaque octet est donc compté et il est nécessaire d'optimiser pour l'usage mémoire.

La difficulté d'OpenBMC repose principalement sur le fait que l'environnement est récent, le language de programmation retenu est principalement C++, et s'appuie sur un environnement de développement long à apprendre (j'aime beaucoup Yocto, mais il faut bien avouer que c'est compliqué). Toutefois, une fois toutes ces difficultés passées, les logiciels libres peuvent s'exprimer à plein dans un environnement jusqu'à présent non exploré par eux et permettent aux constructeurs d'expérimenter bien plus rapidement certaines pistes d'innovations, comme pour les environnement 0 trust ou 0 touch, qui nécessitent parfois de livrer des machines sans firmware, et d'aller les chercher sur le réseau.

Vous l'aurez compris je suis un grand fan d'OpenBMC. Si vous avez des questions n'hésitez pas à les poster en commentaire, si vous en avez l'opportunité je serai en France la semaine prochaine et à Cloudfest par la suite.

Pour les aventuriers, vous pouvez aussi tester OpenBMC sur matériel HPE tout en conservant la sécurité de ces systèmes et en signant vos propres images avec vos clefs de sécurité. Pour se faire rendez vous sur https://www.hpe.com/us/en/compute/openbmc-proliant-servers.html Pour ceux qui doutent de l'intérêt de s'enregistrer, cette étape est nécessaire afin de transférer la propriété logique du firmware.

A bientôt