URL: https://linuxfr.org/news/un-pas-en-avant-pour-les-serveurs-libres-le-projet-nerf Title: Un pas en avant pour les serveurs libres : le projet NERF Authors: vejmarie ZeroHeure, Sclarckone, Davy Defaud, Benoît Sibaud et palm123 Date: 2017年06月28日T10:45:16+02:00 License: CC By-SA Tags: coreboot, linuxbios, blob, intel, google, nerf et x86 Score: 88 Avons‐nous une chance d’avoir un code plus ouvert pour nos serveurs préférés ? Coreboot (né LinuxBIOS) a fonctionné durant ses sept premières années sur serveurs, mais il n’est malheureusement plus disponible sur serveurs x86 aujourd’hui ! La faute aux _blobs_ binaires obligatoires pour initialiser la machine, pour lesquels nous n’avons pas d’autorisation de redistribution — voire pas de _blobs_ du tout. C’est là qu’entre en jeu le projet NERF (_Non‐Extensible Reduced Firmware_), un autre fils de Ron Minich, déjà père de LinuxBIOS et Coreboot. Ron n’a pas peur des idées folles, et il voudrait contourner les _blobs_ avec un noyau Linux (et ses pilotes !) dans le BIOS. ---- [Journal à l’origine de la dépêche](https://linuxfr.org/users/vejmarie/journaux/un-pas-en-avant-pour-les-serveurs-libres-le-projet-nerf) [Journaux de vejmarie transformés en dépêche](http://linuxfr.org/users/vejmarie/news) [Coreboot](https://www.coreboot.org/) [Projet OpenCompute](http://www.opencompute.org/projects/server/) ---- Comme la plupart d’entre vous le savent, je suis un grand supporteur 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 cela explique pourquoi je suis aujourd’hui plus impliqué dans le développement des outils nécessaires à faire du matériel, plutôt qu’à 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éliorant (notamment la version de développement), il est de plus en plus proche d’un statut suffisant pour développer la mécanique d’un serveur. Aussi ai‐je décidé de me ré‐intéresser au sujet des BIOS, que j’avais quitté il y a bien longtemps. J’ai donc constitué mon baluchon et en route pour Denver à ma première conférence [Coreboot](http://www.coreboot.org). Pas forcément à côté de la maison, mais les présentations furent fort intéressantes et effectuées par des contributeurs aguerris du projet. #Coreboot inopérant Coreboot est le « fils » du projet _linuxbios_, initié par Ron Minnich à Los Alamos. Ron 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 Chromebooks ont été livrés avec Coreboot comme 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 micrologiciel OPAL librement disponible. Je suis donc arrivé avec mes tonnes de questions plus ou moins intelligentes, afin de savoir quoi faire pour essayer de refaire fonctionner Coreboot sur serveurs. Et puis mieux comprendre les complexités auxquelles la communauté de développeurs fait face dans ses rapports avec les fournisseurs de composants qui distribuent les informations techniques au compte‐gouttes. En effet, même si Coreboot est un projet libre sur processeur Intel x86, il doit utiliser un ensemble de _blobs_ binaires pour initialiser la machine. Ces _blobs_ incluent notamment les mises à jour des microcodes des processeurs, leurs interconnexions avec les jeux de puces (_chipsets_) des cartes mères, 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 limite l’intérêt de généraliser leur usage et ne simplifie pas la vie de Coreboot. Les serveurs ajoutent en complexité avec la notion de multi‐processeur. Sur puces Intel avec bus QPI notamment, car Intel n’a jamais souhaité fournir de _blob_ binaire pour ce sous‐composant, ce qui rend 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 perdus). 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 processeurs 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_ est varié et va des pilotes pour les périphériques, à des piles réseau, à des systèmes de fichiers complexes ou encore à la gestion de systèmes de sécurité SMM. Tous ces magnifiques _blobs_, engendrent de sérieux soucis de sécurité, et peuvent avoir très peu d’intérêt pour la prise en charge des BIOS libre. Il apparaît clairement que les phases SEC et PEI resteront probablement propriétaires pour les prochaines décennies, sauf avec le succès possible de RISC-V munis d’un contrôleur mémoire ouvert, ce qui pourrait amener les vendeurs traditionnels à faire un pas en avant. D’un autre côté, nous n’avons pas trop d’inquiétude quant à la sécurité, et peu d’intérêt à réimplémenter pour le moment les phases SEC et PEI avec du code libre tant celui‐ci serait de bas niveau, dépendant des révisions de composants et utile principalement au surcadencement (_overclocking_), 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 défis intéressants ! ## Le premier, un peu bébête mais super complexe : faire rentrer notre code de BIOS dans une NVRAM ridiculement petite La plupart des NVRAM de serveurs font 16 Mio, repartis en deux blocs de 8 Mio chacun, dont un alloué au _Management Engine_ (le machin qui réimplémente [[IPMI]]) et le second au code du BIOS système qui inclut les phases SEC, PEI, les _blobs_ DXE et le shell EFI. Or, nous avons besoin d’espace ! L’équipe de Ron a pour cela développé plusieurs outils (**attention ne pas les utiliser sans sauvegardes**). L’un d’eux s’appelle _ME Cleaner_, dont l’optique est de supprimer le code du [_Management Engine_](https://fr.wikipedia.org/wiki/Intel_Active_Management_Technology) et les trous de sécurité associés. Ils utilisent ensuite leur série de _UEFITool_ pour réaliser une « DXE‐ectomie » dans l’optique de supprimer quelques [[mébioctet]] des codes DXE (dont un serveur Web !), afin de faire de la place pour Linux. Sur une carte de type [MinnowBoard Turbot](https://minnowboard.org/), les _blobs_ ME représentent 5 Mio avant nettoyage, et 300 kio 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 noyau d’une taille inférieure à 1 Mio. Ce noyau est ensuite étendu au fur et à mesure en fonction des besoins. ## Tester que tout fonctionne... ... avec une approche pas à pas en démarrant tout d’abord le noyau via le shell EFI en association avec son _initramfs_ présent sur un disque SSD SATA, 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](http://u-root.tk/), qui est un autre projet complétement fou, qui réimplémente 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 volée du code source. Une image de u-root au format bzImage fait entre 3 et 5 Mio Si vous voulez en savoir plus, [voilà une petite vidéo de Ron](https://www.usenix.org/conference/atc15/technical-session/presentation/minnich) lors de la conférence _Usenix 2015_. # 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 de 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 programme d’amorçage (_bootstrap_) complet fonctionnel basé sur u-root avec un client _wget_, capable de téléverser un nouveau noyau et de le démarrer via _[kexec](https://en.wikipedia.org/wiki/Kexec)_, permettant de s’affranchir du vieux et très lent TFTP. Il nous reste à 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](https://fr.wikipedia.org/wiki/Trusted_Platform_Module "Trusted Platform Module"). Un des avantages en utilisant ces méthodes, c’est que l’on arrive à démarrer un serveur de bout en bout en moins de cinq secondes, là où un BIOS AMI de compétition peut mettre environ deux 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 et 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 du matériel libre 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](http://u-root.tk/#community) [[_dépôt GitHub_](https://github.com/u-root/u-root)] et à soumettre vos premiers correctifs. Supporter des serveurs avec des micrologiciels libres permet aussi d’améliorer la durée de vie des machines en maintenant ce logiciel critique ; on apporte ainsi des solutions techniques plus pérennes. La bonne question est maintenant : « **Qui sera le premier à acheter un serveur fonctionnel avec NERF pour démarrer la machine ?** » --- P.‐S. : Je tiens à remercier Ron qui a participé a la relecture en version anglaise et j’espère que ma traduction reflète le texte commun sur lequel nous avons travaillé.

AltStyle によって変換されたページ (->オリジナル) /