Journal Un pas en avant pour les serveurs libres: Le projet NERF

Encore un journal écrit depuis les USA, avec un clavier qwerty, j'en suis sincèrement désolé, et espère que vous me lirez malgré cet aspect agaçant, je le reconnais. [NdM : corrigé, en étant aussi sincèrement désolé s'il reste deux trois coquilles]

Comme la plupart d’entre vous le savez, je suis un grand supporter des serveurs libres pour de multiples raisons que je ne vais pas ré-expliquer dans ce journal aujourd'hui. Beaucoup d'entre vous m'ont challengé ces derniers mois sur la notion d'ouverture réelle des serveurs libres, et je vous ai longtemps répondu que le monde du logiciel libre ne s’était pas construit en un jour.

C'est la même chose pour le matériel libre, et explique pourquoi je suis aujourd'hui plus impliqué dans le développement des outils nécessaires à faire du matériel, plutôt qu'a développer du matériel. J'aime l'analogie qui consiste à dire que développer Linux avec des outils propriétaires serait un non sens.

C'est pourquoi je suis un contributeur actif au projet FreeCAD, un utilisateur de KiCAD, et n'avais jusqu’à présent que peu de temps pour me pencher sur la problématique des BIOS. Toutefois FreeCAD s’améliore (notamment la version de développement) et est de plus en plus proche d'un statut suffisant pour développer la mécanique d'un serveur. Aussi j'ai décidé de me ré-intéresser au sujet des BIOS que j'ai quitté il y a bien longtemps. J'ai donc constitué mon baluchon et en route pour Denver, et ma première conférence Coreboot. Pas forcément à côté de la maison, mais les présentations furent forts intéressantes et effectuées par des contributeurs aguerris du projet.

Coreboot est le "fils" du projet linuxbios, initie par Ron Minnich à Los Alamos et qui travaille actuellement chez Google. Coreboot est un BIOS déployé sur la plupart des Chromebook de Google, sur lesquels il fonctionne parfaitement et répond au besoin. Des dizaines de millions de Chromebook ont été livrés avec Coreboot comme leur BIOS principal !

Coreboot (né LinuxBIOS) a fonctionné durant ses sept premières années sur serveurs. Son principal usage était dans le domaine du calcul scientifique, mais il n'est malheureusement plus disponible sur serveurs x86 aujourd'hui! C'est un fort contraste avec les serveurs Power d'IBM qui s'appuient sur le firmware OPAL disponible en Open Source.

Je suis donc arrivé avec mes tonnes de questions plus ou moins intelligentes afin de comprendre que faire pour essayer de refaire fonctionner Coreboot sur serveur, et mieux comprendre les complexités auxquelles la communauté de développeurs fait face par rapport aux fournisseurs de composants qui distribuent les informations techniques au compte gouttes.

En effet, même si coreboot est un projet Open Source, sur processeur Intel x86, celui-ci doit utiliser un ensemble de "blobs" binaires pour initialiser la machine. Ces blobs incluent notamment les mises a jour des microcodes des processeurs, leurs interconnexions avec les chipsets, les cartes graphiques, la reconnaissance mémoire et quelques astuces secrètes des vendeurs de composants. Ces blobs sont disponibles aux gros consommateurs comme Google ou à tout un chacun mais sans autorisation de redistribution, ce qui en limite leur intérêt pour une généralisation de leurs usages et ne simplifie pas la vie de coreboot.

Les serveurs ajoutent en complexité la notion de multiprocesseurs, et notamment sur chip Intel le bus QPI, qui n'a jamais souhaité fournir de "blob" binaire pour ce sous composant et rend ainsi coreboot inopérant.

Alors avons nous une chance d'avoir un code plus ouvert pour nos serveurs préférés ?

L'espoir vient d'un projet qui s'appelle NERF (Non-Extensible Reduced Firmware) lancé par une petite équipe d’ingénieurs de Google (dont Ron) qui a eu l’idée folle d'interfacer un noyau Linux avec la fin de la phase d'initialisation PEI des systèmes multi-processeurs (je sens que je vous ai perdu)

Depuis quelques années, Intel a introduit les BIOS UEFI (pas une réussite selon moi), qui délimite l'initialisation d'un système en plusieurs étapes:

• L’étape SEC, qui charge les microcodes des CPU(s) et les démarrent.
• L’étape PEI qui se charge d'initialiser le système (détection mémoire, et initialisation QPI)
• L’étape DXE qui initialise les bus PCI, exécute différents blobs afin de démarrer le système UEFI. Le contenu des blobs varie, et va des pilotes pour les périphériques, à des piles réseaux, des systèmes de fichiers complexes ou encore la gestion de système de sécurité SMM.

Tout ces magnifiques blobs, engendrent de sérieux soucis de sécurité, et peuvent avoir très peu d’intérêt pour le support des BIOS Open Source. Clairement il apparait que les phases SEC et PEI resteront probablement propriétaires pour les prochaines décennies, sauf si le succès de RISC-V munis d'un contrôleur mémoire ouvert s'effectue, et pourrait amener les vendeurs traditionnels à faire un pas en avant. En un autre sens, nous n'avons pas trop d'inquiétude quant à la sécurité et l’intérêt de ré-implémenter pour le moment les phases SEC et PEI avec du code libre tellement celui-ci est de bas niveau, dépendant des révisions de composants et utile principalement aux overclockers, très peu présents dans le domaine des serveurs.

Interfacer le noyau Linux juste après la phase PEI nécessite de résoudre quelques challenges intéressants:

• Le premier, un peu bébête, mais super complexe, est de faire rentrer notre code de BIOS dans une NVRAM ridiculement petite. La plupart des NVRAM de serveurs font 16 Mo, repartis en deux blocs de 8Mo chacun, dont un alloué au Management Engine (le machin qui re-implemente IPMI), et le second au code du BIOS Système qui inclut les phase SEC, PEI, les blobs DXE et le shell EFI. Nous avons besoin d'espace ! L'eéuipe de Ron a pour cela développé plusieurs outils (ATTENTION NE PAS LES UTILISER sans sauvegardes), dont un qui s'appelle "ME Cleaner" dont l'optique est de supprimer le code du Management Engine et ses trous de sécurité associés. Ils utilisent par la suite les outils UEFITool pour réaliser une "DXE-ectomie" dans l'optique de supprimer les Mo des codes DXE (dont un serveur web!), afin de faire de la place pour Linux.

Sur une carte de type MinnoxMax "Turbot", les blobs ME représentent 5Mo avant nettoyage, et 300Ko après, laissant suffisamment de place pour Linux et un initramfs

• Construire un noyau Linux qui peut rentrer dans un petit espace. La stratégie adoptée consiste à supprimer tout ce qui n'est pas nécessaire (même la fonction multi-utilisateur), afin d'avoir un kernel d'une taille inférieure à 1Mo. Ce noyau est ensuite étendu au fur et à mesure en fonction des besoins.

• Tester que tout fonctionne avec une approche pas a pas en démarrant tout d'abord le noyau via le shell efi en association avec son initramfs présent sur un disque SATA SSD, puis remonter dans la pile au fur et à mesure jusqu’à démarrer le noyau juste après la phase PEI.

• Supprimer le code standard du BIOS et ouvrir la porte à la créativité tout en améliorant drastiquement la sécurité en employant un projet comme u-root, qui est un autre projet complétement fou, qui ré-implemente la plupart des fonctions basiques d'un shell en Go, un langage bien plus sécurisé que C contre les erreurs de programmation et capable de compiler à la voler du code source. Une image de u-root au format bzImage fait entre 3 et 5Mo

Si vous voulez en savoir plus, une petite vidéo de Ron https://www.usenix.org/conference/atc15/technical-session/presentation/minnich

Est-ce que ça marche sur serveur Open Compute ?

Avant que je ne rencontre Ron la réponse était non. Depuis, nous lui avons fourni un peu de matériel et support, et après quelques semaines de travail acharné, l’équipe a été capable de démarrer un noyau Linux. Il reste quelques problèmes non négligeables comme initialiser correctement les interruptions, mais nous sommes proches de quelque chose de fonctionnel (pas pour de la prod hein)

C'est quoi les prochaines étapes ?

L’équipe de Ron a un bootstrap complet fonctionnel basé sur u-root avec un client wget, capable d'uploader un nouveau noyau et de le démarrer via kexec, permettant de s'affranchir du vieux et très lent TFTP. Il nous reste a proposer des menus de configuration du démarrage kexec, améliorer les systèmes de déploiement automatique de la solution, travailler sur la sécurisation du démarrage en utilisant un TPM.

Un des avantages en utilisant ces méthodes, c'est qu'on arrive à démarrer un serveur de bout en bout en moins de 5s là où un BIOS AMI de compétition peut mettre environ 2 minutes. On s'affranchit aussi au passage de l’exécution des ROM des cartes PCIe qui sont remplacées par de vrais pilotes présents dans le noyau Linux bien plus efficaces et à jour.

Le travail de Ron, de son équipe, associé aux serveurs Open Compute, permettra potentiellement de reprendre un contrôle total de son infrastructure. C’était vraiment un élément qui manquait actuellement dans le monde de l'open hardware, et nous sommes proches de combler ce trou. Il reste énormément de travail et de créativité. L’équipe de Ron est ouverte aux contributions, n’hésitez pas a rejoindre la communauté u-root (u-root.tk; github.com/u-root/u-root) et soumettre vos premiers patchs

Supporter des serveurs avec des firmwares Open Source permet aussi d’améliorer la durée de vie des machines en maintenant ce logiciel critique, et d'apporter ainsi des solutions techniques plus pérennes.

La bonne question maintenant qui sera le premier à acheter un serveur fonctionnel sous NERF pour démarrer la machine ?

ps: je tiens a remercier Ron qui à participer a la relecture de ce journal en sa version anglaise et espère que ma traduction reflète le texte commun sur lequel nous avons travaillé.