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

Posté par (page perso) . Licence CC by-sa
Tags : aucun
49
28
juin
2017
Ce journal a été promu en dépêche : 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é.

  • # Statut

    Posté par . Évalué à 2 (+1/-0).

    Il serait intéressant d'avoir le statut de ce projet, qu'on sache où on en est et vers quoi on se dirige (peut-être un planning de prévu, avec les nouvelles fonctionnalités prévues ?).

    En tout cas ça m'a l'air intéressant, et j'aimerai beaucoup mettre du libre du bout en bout sur mes ordinateurs.

    • [^] # Re: Statut

      Posté par (page perso) . Évalué à 4 (+2/-0).

      Pour le moment on essaie de finaliser le boot des serveurs Open Compute complet avec l'appelle d'un kernel complet via un call kexec sous u-root. Une fois que le prototypes fonctionnera de bout en bout on pourra alors passer a la realisation de la suite, et definir l'ensemble des fonctions necessaires.

      • [^] # Re: Statut

        Posté par . Évalué à 2 (+1/-0).

        Là où pour toi cela semble clair, cela ne l'est pas pour moi (et je suppose beaucoup d'autres) : quelles sont les parties qu'il faut avoir, où est-ce que vous en êtes et qu'est-ce qu'il manque ? Parce que "définir les fonctions nécessaires" ce n'est pas ce que j'appelle "clair".

        Je pense qu'il y a un petit effort à faire au niveau de la communication. Des points à éclaircir : ce qu'un bootloader doit faire, ce qui est fait par le votre et ce qui lui manque, ce qui est fait par les autres, avantages de développer son bootloader, compatibilité avec les matériels, quel usage. Je pense pas qu'on puisse décrire tout ça en 2 lignes, mais faire ce petit effort permettrait réellement d'avoir un recul sur le projet.

        • [^] # Re: Statut

          Posté par (page perso) . Évalué à 4 (+2/-0).

          Pour le moment le projet remplace l'integralite du code du BIOS en dehors des phases d'initialisation des CPUs, memoire et liens inter CPUs. Le remplacement s'effectue par le demarrage d'un kernel linux, et un prompt sur un compte root sur un filesystem qui ne contient que tres tres peu de commandes (globalement juste un call a kexec pour executer un nouveau noyau)

          Il faut construire tout le reste, a savoir par exemple:
          - Un systeme de menu pour configurer le demarrage du systeme secondaire (comment configurer le PCIexpress par exemple, les differents ports, quid des tables ACPI etc …)
          - Un systeme qui permet de demarrer automatiquement le noyau suivant
          - Un systeme qui permet d'installer un O/S sur la machine via un boot reseau par exemple ?
          - La gestion des signatures de l'ensemble des binaires

          Une fois qu'on aura ca, ca sera deja pas mal. L'avantage de developper son propre BIOS c'est de pouvoir adapter les differents systemes precedants et de maitrise les aspects securites.

  • # Orthographe

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

    Au-delà du problème que tu évoques (qui ne me semble pourtant pas non plus insurmontable, changer le layout est-il complexe ?), il y a tout de même de nombreuses erreurs et j’aurais bien aimé que tu te fasses relire (en français).

    Ce que tu décris est très technique, je pense que cela est très intéressant et pourrait attirer des curieux, mais ces erreurs de forme gênent à la lecture. C’est réellement dommage.

    • [^] # Re: Orthographe

      Posté par (page perso) . Évalué à 4 (+2/-0).

      tu parles d'erreur de francais ? (c'est fort probable et m'en excuse)

      • [^] # Re: Orthographe

        Posté par . Évalué à 10 (+11/-1).

        Heureusement, il y a Grammalecte !

        • [^] # Re: Orthographe

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

          Qu'il faut soutenir en effet !!! Sa deuxième campagne de financement fonctionne moins bien que la première et a mi-parcour n'est pas à la moitié du financement demandé … Donc s'il vous reste quelques €€€ en poche merci de faire un geste et ainsi contribuer à des dépêches/commentaires de meilleur qualité orthographique & grammaticale ;-)

  • # qwerty

    Posté par (page perso) . Évalué à -5 (+9/-16).

    Encore un journal ecrit depuis les USA, avec un clavier qwerty, j'en suis sincerement desole, et espere que vous me lirez malgre cet aspect agacant je le reconnais.

    J'ai pas bien compris, il est où le problème avec le fait d'avoir un clavier qwerty ? D'ailleurs ce commentaire est écrit depuis un clavier qwerty.

    Si c'est si agaçant, pourquoi juste pas configurer et/ou apprendre à utiliser son clavier ?

    • [^] # Re: qwerty

      Posté par (page perso) . Évalué à 10 (+13/-5).

      Pitié, le fond est tellement intéressant, ne noyons pas encore un fois LinuxFr sous la forme…

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

      • [^] # Re: qwerty

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

        Il y a quand même les correcteurs orthographiques, même dans les navigateurs. Ça permet de corriger bon nombre d'accents manquants, sans parler de grammalecte sur firefox, ou de la touche de composition sur les claviers *NIX. Bref, le clavier QWERTY est une fausse excuse.

        Et malgré tout, oui l'article est intéressant. Mais que l'auteur fasse l'effort de la correction, un modo mettra à jour, et tout le monde, surtout nous lecteurs, y gagnera.

      • [^] # Re: qwerty

        Posté par . Évalué à -3 (+4/-9).

        Ouais enfin quelque soit l'intérêt du contenu c'est limite insultant de se cacher derrière des excuses totalement bidons quand on est conscient de ne pas faire preuve d'un grand respect pour son interlocuteur.

        Un peu comme les signes de la mains en faux remerciements d'un conducteur qui te coupe sciemment la priorité.

      • [^] # Re: qwerty

        Posté par (page perso) . Évalué à 9 (+6/-0).

        À la demande de l'auteur, je viens d'utiliser mes super-pouvoirs de modérateur pour nettoyer le texte.
        Je pense aussi que ce journal pourrait être promu en article.

        • [^] # Re: qwerty

          Posté par (page perso) . Évalué à 5 (+4/-1).

          Merci Pierre, avec un peu de chance on va pouvoir parler du fond ;)

          • [^] # Re: qwerty

            Posté par (page perso) . Évalué à 3 (+1/-0).

            Le journal est déjà presque entièrement transformé en article. Encore des petites corrections et ça passe.
            Vous pouvez participer!

            "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

          • [^] # Re: qwerty

            Posté par (page perso) . Évalué à 2 (+3/-3). Dernière modification le 28/06/17 à 17:29.

            En même temps tu as démarré directement par ce sujet au début de ton journal.

            Et en vrai je me demande réellement où est le problème puisque j'écris avec un clavier qwerty et avec des accents.

      • [^] # Re: qwerty

        Posté par (page perso) . Évalué à 5 (+6/-3).

        Le fait est qu'on voit souvent cette excuse (je suis en qwerty alors je peux pas ecrire correctement desole) alors qu'elle est totalement fausse. Peut-être qu'à force de répéter qu'il est très simple (au moins sous OSX et Linux) de faire des accents en qwerty, ceux qui sont vraiment desoles pourront se sentir mieux en écrivant correctement, et les feignasses n'auront plus d'excuses. Et ça gagnera du confort de lecture pour tout le monde, et du temps pour le modo qui n'aura plus besoin de corriger.

        Et comme on a qu'un type de commentaire et pas plusieurs fils « réponses sérieuses » / « pinaillage » / … bah on le met où on peut.

  • # Relecture...

    Posté par (page perso) . Évalué à 3 (+1/-0).

    Jean-Marie, veux-tu relire la dépêche avant que je la passe en modération ? j'ai corrigé pas mal de choses (des expressions «franglaises»), ajouté des liens, …

    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

Envoyer un commentaire

Suivre le flux des commentaires

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