Journal Vers des serveurs libres, ouverts et sécurisés : NERF (2)

Posté par (page perso) . Licence CC by-sa
54
15
nov.
2017

Bonsoir à tous,

Le projet NERF (Non Extensible Reduced Firmware) progresse à grand pas. Nous l'avons présenté avec succès lors de la dernière linuxcon de Prague et vous pouvez trouver la video du talk de Ron ici ( https://www.youtube.com/watch?v=iffTJ1vPCSo ). La video est en anglais c'est normal Ron est américain, on se connait depuis une vingtaine d'années quand il a créée linuxbios à Los Alamos, mon pseudo ne vous dira rien mais dans le talk je suis Jean-Marie Verdun.

Pour rappel les objectifs de NERF sont de supprimer les trous de sécurités induits par l'introduction de ME et UEFI dans les machines Intel, mais aussi d'ouvrir la voie à des machines les plus ouvertes possibles. Pour se faire nous désactivons la partie ME (remote management IPMI) et remplaçons le code UEFI par un kernel linux qui est directement présent sur le chip des cartes mères.

J'ai fait il y a quelques temps un journal sur cette approche à une époque où nous en étions au stade de preuve conceptuelle. Depuis nous avons rebooté avec succès un serveur Open Compute plus de 10 000 fois sans aucun plantage ni ralentissement (ce qui n'a jamais été possible avec un BIOS UEFI) et nous travaillons au support de grub directement dans NERF avec pour objectif de booter une distro standard d'ici la fin du mois de décembre (encore une fois c'est un objectif).

Il reste encore pas mal de travail à accomplir, mais nous sommes de plus en plus optimiste quand à notre capacité à atteindre notre objectif qui est de commercialiser des serveurs à base de BIOS NERF et de supprimer UEFI/ME des machines. J'espère qu'on y arrivera en début 2018. Un des objectifs des fondateurs du projet avec cette technologie en dehors de tout ce que vous pourrez lire sur internet suite à ce talk est de pouvoir éteindre et rallumer de manière prédictible des serveurs à grande échelle et d'induire ainsi une reduction drastique de la consommation d'énergie des datacenters. (on boote linux en moins de 20s actuellement depuis un power on. On a pour objectif de descendre ce temps sous les 5s)

Aussi fou que cela puisse paraitre, il nous reste beaucoup de chose à définir et notamment la partie interface utilisateur, en tant qu'administrateur système comment envisageriez vous un BIOS qui fonctionne sur la base d'un kernel linux ? Quelles commandes vous semblent les plus importantes avant d'exécuter un kexec ? Comment géreriez vous un système sans interface IPMI ? (c'est faisable en y réflechissant un peu)

A ce jour nous faisons des choses basiques, mais suffisantes, on boot un kernel linux, qui démarre une interface réseau, attrape une adresse IP sur un serveur dhcp et fait un wget en https sur un serveur remote pour executer un kexec d'un kernel de distro standard et monter le systeme de fichier associé. C'est suffisant pour nos cas d'usage probablement pas pour les votres et c'est la dessus dont on a besoin de vos inputs, alors pour une fois n'hésitez pas à me troller je suis sure que la plupart de vos idées seront bonnes. Typiquement on ne regarde pas la MBR des disques en attachement direct, c'est beaucoup trop "old school" et on peut faire bien mieux avec un noyau linux a la place du BIOS.

Quoiqu'il en soit, j'espere que cette technologie trouvera un intérêt auprès de notre modeste communauté linux francaise, les personnes impliquées derrieres ont passe un grand nombres d'heures pour la faire fonctionner et les années d'experience acquises dans la gestion de systèmes hyperscales se retrouvent dans le résultat de ces travaux (Ron est le papa de coreboot).

Pour ceux qui souhaitent tester NERF, nous allons mettre en ligne prochainement des serveurs qui fonctionneront à base de cette technologie chez Data4, un des rares hébergeurs francais qui a conçu des salles machines faites pour le free cooling et les équipements Open Compute / Open Power et qui a accepter de nous aider a mettre au point ces technologies en nous proposant des espaces à des tarifs corrects.

Sinon nous pouvons vous vendre des kits de développements qui permettent de découvrir la technologie sur un serveur Open Compute utilisé pour le développement du projet. On en a disséminer un grand nombre dans la silicon vallée et j'ai toujours ce doux rève de penser qu'un jour la France pourra etre leader en infrastructure. (remarque: on peut l'etre sans NERF probablement)

vejmarie

ps: je suis de l'autre coté de l'atlantique, ne m'en voulez pas si je ne répond pas a vos commentaires "instantanement"

  • # IPMI, remote management

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

    Tout d'abord, bravo pour ce travail et merci de nous rapporter des avancements.

    J'ai quelques questions. L'IPMI c'est pratique pour retrouver des informations systèmes comme la consommation ou savoir qu'un ventilateur est défectueux, du coup, le but ce serait de le remplacer par quoi ? Pareil pour faire un power cycle (on peut le faire via le pdu mais ça me semble moins bon pour les composants, je me trompe peut-être) ? Il y a aussi les technologies annexes à l'IPMI, comme avoir accès via un serveur web à l'écran de la machine pour ne pas devoir se déplacer dans le DC pour comprendre pourquoi l'OS ne boot pas (ou ne voit pas sa carte réseau), envisagez-vous un système similaire ?

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: IPMI, remote management

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

      On travaille sur des demons en mode user pour le monitoring. Le plus important est de detecter les erreurs ECC. Globalement on part du principe que si une machine ne demarre pas elle doit etre analysee par un technicien. Une erreur hardware ou de configuration doit engendrer une sortie de la prod du systeme. Les tests devant etre effectues sur des machines de labo presentent a cote de toi.

      C'est une approche un peu brutale qui permet temporairement d'eliminer les interfaces de remote management "proprietaires" pleines de bugs et mal supportees. Ces derniers annees, iLo, iRack, ME, AMI ont tous eu des trous de securites beant et/ou des interruptions de services lies a des bugs softs. OpenBMC(Rackspace, IBM, Google, FB) ouvre le chemin a une interface BMC ouverte et maintenable par une communaute.

      • [^] # Re: IPMI, remote management

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

        Une erreur hardware ou de configuration doit engendrer une sortie de la prod du systeme.

        C'est évident. Mais justement pouvoir analyser l'erreur avant de déplacer quelqu'un sur place permet de faire des économies pour les petites structures. Cela étant dit, je comprends tout à fait le raisonnement que vous faites.

        Ces derniers annees, iLo, iRack, ME, AMI ont tous eu des trous de securites beant et/ou des interruptions de services lies a des bugs softs.

        C'est évident que c'est à mettre dans un réseaux bien protégé.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: IPMI, remote management

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

          Il faut juste travailler avec le DC qui fournit un service local de reparation et d'analyse qui evite ainsi de se deplacer. Ils commencent a monter dans la chaine de valeur et c'est pas plus mal.

          • [^] # Re: IPMI, remote management

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

            Il faut juste travailler avec le DC qui fournit un service local de reparation et d'analyse

            Je vois dans ma boule de cristal que si tu commence à dire au gens comment ils doivent travailler, tout cela ne va pas aller bien loin…

            Chef on va mettre a jour le bios des serveurs, c'est plus sécurisé, mieux pour les données personnelles de nos clients bla bla, 3 libertés, bla bla backdoor, bla bla NSA, boot plus vite, … , par contre ça va niquer tout notre process industriel …

            • [^] # Re: IPMI, remote management

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

              ONIE, ONL, FBOSS, Cumulus Networks, Pica8 sont des technologies qui ont changees la maniere dont les reseaux fonctionnent et sont geres. Il est probable que le meme type de changement apparaisse sur les serveurs ne serait-ce parce qu'ils ne deviennent qu'un outils parmi tant d'autre et que la resilience est deportee au niveau applicatif.

              • [^] # Re: IPMI, remote management

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

                Sous cumulus, j'ai quand même telnet et une console série comme sur un bon vieux Cisco.

                Le fait de porter une vision sur la façon dont les choses devraient être faites, n'empêche pas de comprendre ce que font les gens, pourquoi ils le font et de s'y adapter. Ne serait-ce que pour faciliter la transition.

  • # comme le cloud ?

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

    Niveau interface, j'imagine que la gestion des clouds peut être une bonne source d'inspiration.

    La mode est au API, comme celle d'AWS ou au conteneur type docker. Je dis une connerie ?

    "La première sécurité est la liberté"

    • [^] # Re: comme le cloud ?

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

      Il y a déjà des interface vers l'IPMI avec HTTP et JSON.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: comme le cloud ?

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

        Il est probable que l'on finisse avec une API, meme si je ne suis pas un super grand fan d'avoir un serveur web qui tourne dans un BIOS.

        • [^] # Re: comme le cloud ?

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

          Ce serveur web ne tourne qu'au boot et disparait ensuite, non ? Il pourrait tourner dans un réseau différent de "la prod", c'est impossible de faire un vpn de "configuration" ?

          "La première sécurité est la liberté"

          • [^] # Re: comme le cloud ?

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

            En fait tout est possible, apres on est contraint par la taille de la flash SPI qui est en general de 16 Mo. On ecrit aussi le user space en Go (contrainte positive de Google). Ce qui est sure c'est qu'il disparait apres oui et on peut en effet faire un VPN de config.

            • [^] # Re: comme le cloud ?

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

              Vous pouvez aussi mettre une clef cryptographique dedans pour le TLS ou autre, le genre de clef qui est sur une étiquette sur la machine. Le principe est que seul une personne pouvant voir physiquement la machine au moins une fois, peut avoir accès à la clef. Cela me fait penser aux clefs WPA derrière les box wifi.

              "La première sécurité est la liberté"

        • [^] # Re: comme le cloud ?

          Posté par . Évalué à 1 (+1/-0). Dernière modification le 16/11/17 à 09:01.

          Redfish n'est pas censé remplacer IPMI ? (Je ne sais pas si ça prend, pour le moment.)
          Pensez-vous à utiliser Redfish ?

          • [^] # Re: comme le cloud ?

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

            Si, mais c'est de nouveau une usine a gaz, pas forcement necessaire.

            • [^] # Re: comme le cloud ?

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

              Colles un ssh dans le bios dans ce cas, la "surface d'attaque" est simple, connu et sécurisé.

              "La première sécurité est la liberté"

              • [^] # Re: comme le cloud ?

                Posté par (page perso) . Évalué à 4 (+2/-0). Dernière modification le 18/11/17 à 17:23.

                Les machines Itanium SGI (type Latix 350, ALtix 450) avait une couche L2. En pratique, le L2 était un Linux embarqué que tu pouvais attaquer en console et te permettait de gérer le boot EFI.

                Les dernières cartes réseaux DELL remplacent leur iDRAC java tout pourris par du HTML javascript bien léger (c'est un Minix embarqué il me semble). Bilan, on augmente encore la RAM et le CPU de la carte réseau ;-) Un IPMI tout léger à la SNMP, c'est bien aussi !

  • # 10⁴

    Posté par (page perso) . Évalué à 7 (+5/-0).

    félicitations. Tout le monde le sait « nul ne peut servir deux maîtres ». Alors avoir du logiciel privateur propriétaire tournant dans une machine…

    Un peu ignorant dans le domaine où vous œuvrez, la phrase suivante m'intrigue :

    « Depuis nous avons rebooté avec succès un serveur Open Compute plus de 10 000 fois sans aucun plantage ni ralentissement (ce qui n'a jamais été possible avec un BIOS UEFI) […] »

    Est-ce à dire que les logiciels UEFI soient tous de tels bloatware qu'il soit délicat pour eux de produire de nombreuses fois la même séquence d'opérations ? Ou autre chose ? Qu'est ce qui cause ces plantages au démarrage ? Ces ralentissement ? Ensuite ? Et comment se fait-il que NERF/Linux les résolve ? Est-ce bien lui ? Eux ? Sans doute la magie de l'open-source ;-) ?

    Voyez, les questions se pressent sans bien pouvoir cerner le sujet. Merci d'avance pour les lumières que vous saurez apporter.

    • [^] # Re: 10⁴

      Posté par (page perso) . Évalué à 10 (+8/-0).

      Il nous manque 2 ressources critiques sur la partie test UEFI. Le temps, 10 000 boot sur une meme machine c'est long en UEFI tres long. Sur une meme machine que celle executant NERF, (meme hardware), le boot s'arrete de maniere aleatoire apres une cinquantaine de demarrage, comme si il y avait de la resilience entre chaque boot. Ce qu'on a constate c'est qu'UEFI utilise la flash du BIOS comme un systeme de fichiers et y stock des informations, on imagine qqs soucis dans la gestion entre boot, mais ce ne sont que des suppositions. NERF utilise les devices drivers de linux pour initialiser le hardware, ils sont publics, ouverts, testes a grande echelle et bien plus sollicite que ceux contenus dans le code UEFI qui en general croise les doigts pour reussir a faire un PXE/TFTP. NERF ne stock aucune information entre boot et recommence ineluctablement toujours la meme tache.

  • # Et l'ACPI ?

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

    Merci pour ce projet !
    Une question que je me pose par rapport au projet NERF : que devient là dedans l'ACPI ? Est-ce-que l'OS 'client' peut s'en passer en utilisant à la place des mécanismes comme le device tree d'OpenFirmware ? Ou le noyau Linux remplaçant l'UEFI fournit-il ses propres tables ACPI et cie à l'OS ? Ou l'ACPI reste-t-il sans intervention du noyau Linux embarqué dans le NERF ?

    • [^] # Re: Et l'ACPI ?

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

      La gestion ACPI est un peu cauchemardesque. En mode serveur on refait une table a la main, d'ou l'interet aussi de le faire sur une plateforme open hardware car on connait un minima de choses. Sur un laptop c'est beaucoup plus chaud. Le second noyau a donc acces aux tables ACPI.

  • # Disponibilité de serveurs pour 2019?

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

    Peut-on imaginer ce type de serveur en 2019 (2018, c'est un peu juste)?

    Vous auriez un constructeur avec vous?

    • [^] # Re: Disponibilité de serveurs pour 2019?

      Posté par (page perso) . Évalué à 7 (+5/-0).

      On aura ce type de machines en 2018 pour sure (le projet est soutenu par quelques geants de la silicon vallee qui nous donne franchement un sacre coup de main). Nous aurons la capacite de livrer bien plus de machines que le marche peut en absorber ;).

  • # Petites questions

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

    Excellent progres ! Du coup, cela me fait poser quelques questions.

    Est-ce qu'il y a une possibilite de gerer secureboot lorsque l'on remplace le bios ? En continuant dans cette direction, si oui, est-il possible d'acceder a un TPM ? Si oui, est-il possible d'utiliser cela pour initialiser des SED ? Ca serait assez utile pour les serveurs avec des disques et les protegers a minima quand on est dans un data center partage.

    En fait, la question devient aussi quelle forme de distribution allez vous utiliser ? Une base de distribution classique facon debian ? Ou un firmware base sur buildroot ou yocto ? Comment va se passer la mise a jour d'un bios ?

    Si je ne me trompe pas, lorsqu'on fait un kexec, on perd rapidement le "contact" et on ne peut pas debugger un kernel ou initrd qui ne demarre pas sans avoir acces physique a l'ecran. Sans une carte a cote, je ne vois pas trop de moyen acceptable de faire cela. Vous avez des idees sur le sujet ?

    Ah, et sinon, c'est probablement une evidence, mais sshd et remote acces lors de la phase de boot pour pouvoir faire des diagnostic manuel, ca me parait tellement utile.

    Oh et sinon go, vous aimez ?

    • [^] # Re: Petites questions

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

      Salut Cedric,

      La premiere image de notre initrd est ecrite entierement en go ;). Google etant a l'origine des travaux c'est pas illogique. Donc pour repondre a tes questions, une fois que tu as un kernel linux tu fais la meme chose qu'avec un kernel linux, donc si tu as active au moment de la compilation du noyau le support TPM, ben le TPM marchera ;)

      On a la stack GPG qui fonctionne pour la signature de certains binaires, ainsi que des echanges https.

      On va probablement pas utiliser buildroot ni yocto, en fait sur l'image u-root, tout doit etre ecrit en go. Apres il existe un second initrd en cours de dev a partir de busybox et qui supporte donc la libc ;). La "beaute" du truc c'est qu'on peut avoir des initrd tres variables en fonction des besoins.

      La philosophie c'est que tu debugges ton install serveur avec ton serveur a cote de toi, une fois que ca tourne tu deploies ;)
      Pour la partie ssh on va regarder ca, mais on est pas encore hyper fan meme si a mon avis on va pas y couper !

      vejmarie

  • # IMPI-like mais qui fonctionne en vrai

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

    en tant qu'administrateur système […] Comment géreriez vous un système sans interface IPMI ?

    IPMI est une bonne idée mais les implémentations que j'ai vu sont toutes (toutes) des bouses : Dell, Supermicro, Tyan, HP, Lenovo. Je crois que c'est tout.

    Il est vraiment important de voir ce qui se passe à l'écran dans tous les cas, d'agir au clavier/souris, et de redémarrer (reset ou power). Donc interface HTML5, ou VNC, ou n'importe quoi (oui enfin un truc standard sans Java/Mono/etc), mais possibilité de voir et agir. De préférence routable pour que ce soit accessible depuis un autre réseau, et sécurisé (SSH/HTTPS/autre).
    Cela permet de comprendre ce qui bloque lors du boot, et de le résoudre. Cela permet de modifier les réglages une fois qu'on a bien merdé avec le pare-feu, etc.

    Il faut également pouvoir « monter » des périphériques à distance. Au moins une clef USB et/ou un DVD. Cela permet d'effectuer une installation à distance sans sortir la grosse artillerie (bien pratique avec du Windows bare-métal). Cela permet de booter un autre Linux pour récupérer des données, etc.

Envoyer un commentaire

Suivre le flux des commentaires

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