Journal Microcode ouvert sur materiel HPE ?

Posté par (page perso) . Licence CC by-sa.
62
12
mai
2020

Bonsoir,

Il y a bien longtemps que je n'ai écris de journal. Il faut dire que l'année 2019 a été un tsunami de mon cote suite à l'acquisition de ma société par un groupe américain, un déménagement outre atlantique et un départ de celui-ci pour rejoindre HPE à Houston, où je pilote la stratégie Open Platform. Me voila "influenceur" (plutot que chef on va dire) chez un constructeur, et de retour à mes sources (j'avais quitté HPE pour créer ma structure en 2006).

Je ne suis pas là pour faire de la pub pour HPE, meme si indirectement je vais vous parler de mes priorités, et j'aimerai avoir l'opportunité d'avoir un échange avec vous sur ce que je fais. Je n'ai pas abandonné mes développements FreeCAD (ils seront le sujet d'un prochain journal leur étant dédié), et l'actualité sur ce sujet est d'ailleurs très riche suite à ma rencontre (physique!) avec d'autres développeurs lors du dernier Fosdem.

Certains d'entres vous le savent je suis un des co-createurs de linuxboot un environnement qui permet de s'affranchir au maximum de codes propriétaires au niveau des BIOS des serveurs. J'ai travaillé aussi sur des approches équivalentes au niveau des BMC (les chips de remote management de ces memes serveurs) au travers de projets comme OpenBMC et u-bmc. Ces projets ont été présentes plusieurs fois lors de conférences internationales comme OCP et/ou Fosdem (Facebook y a fait un très bon talk cette année sur la manière dont ils testent les dits microcodes).

En arrivant chez HPE, il m'était évident que cette approche allait créer un choc culturel. Il faut dire que l'engineering local développe ses propres BIOS avec succès depuis plus de 25 ans sur les systèmes ProLiant, et arriver avec une approche ou on casse tout, au profit du kernel linux, il faut avouer que je me suis dit qu'en tant que Francais au Texas, il allait falloir etre subtil et prudent.

Apres quelques mois, d'engueulades positives et bbq (on résout pas mal de choses autours d'un bbq ici), on a réussi à avoir des Proliant qui démarrent sous OpenBMC (Gen10/skylake) ainsi que linuxboot. Ils ont été présentés d'ailleurs pour l'un d'entre eux cette année à Bruxelles au Fosdem (second choc culturel d'ailleurs). La difficulté technique repose principalement sur la mise en oeuvre des mécanismes de protection (légitime) des microcodes depuis quelques années (Silicon Root of Trust, et Intel Bootguard en sont quelques exemples). Comment concilier liberté de choix et mécanisme de protection ?

Apres cette étape de tests au travers de PoC (Proof of Concept), nous sommes entrés dans la phase suivante de pré-industrialisation. Ils nous restent évidemment beaucoup de travail, tests et validations. Mais vous allez pouvoir y participer, enfin j'espère. Nous sommes en train d'assembler des prototypes de DL360Gen10, que nous allons proposer à quelques uns de nos gros et petits clients, qui souhaitent s'impliquer dans cette aventure. Si vous en faites parties, faites moi signe !

Etant un fervent défenseur des travaux communautaires, et de la nécessité d'offrir la possibilité à tout le monde de tester les microcodes libres, j'ai créée un petit projet dénommé OSFCI (Open Source Firmware Continuous Integration) disponible sur github, et au travers d'une plateforme en ligne qui permet de tester a distance un serveur Proliant qui fonctionne sur OpenBMC, et linuxboot. Evidemment il reste beaucoup de travail, mais celui-ci peut se faire de manière collaborative et a bien entendu démarré au travers de communautés des microcodes libres.

Vous pouvez acceder a la plateforme fonctionnelle sur https://osfci.tech. Nous l'utilisons pour valider nos propres développements et cela fonctionne plutot bien durant cette pandémie qui nous touche tous. L'idée étant de recompiler une image openbmc et/ou linuxboot en local, de la télécharger sur un FPGA connecté a un ProLiant qui va émuler des Flash SPI, et de controler a distance l'alimentation électrique du serveur. Une fois allumé, les consoles des différents microcodes sont accessibles. Une image de demo est disponible par défaut.

Nous travaillons sur une API qui permettra de faire tout cela en mode automatique, permettant ainsi de valider chaque assemblage de microcode à la volée.

Les microcodes propriétaires ne vont pas disparaitre, mais les logiciels libres arrivent à se créer une place dans ce domaine et j'espère que chacun pourra ainsi choisir sa stratégie de sécurité au travers d'options soient totalement propriétaires soit totalement auditables, modifiables et libres.

N'hésitez pas à me fournir votre retour sur cette approche qui me tient sincèrement à coeur.

vejmarie

  • # Congrats

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

    La boîte où je travaille a plutôt tendance à acheter des Lenovo plutôt que des HP.

    Mais en tout cas, bravo de driver cette stratégie et d'arriver petit à petit à mettre en œuvre du logiciel libre à ce (bas) niveau chez un grand constructeur.

    • [^] # Re: Congrats

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

      Merci pour votre soutien. La mise en oeuvre d'une telle strategie a l'echelle d'un groupe comme HPE est en effet un challenge a part entiere, mais aussi une aventure humaine tres interessante a vivre, meme si on passe par des hauts et des bas ! Peut-etre qu'un jour vous reviendrez sur des machines plus "transparentes" et/ou pionnieres.

      • [^] # Re: Congrats

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

        Un grand bravo pour ce parcours professionnel si riche.
        Je me souviens de tes premières tentatives pour que HP puisse fournir des PC sans Windows. HP l'avait permis sur des machines en fin de commercialisation et à des prix élevés. On appelle ça un sabotage.
        Tes serveurs dans l'huile et sur les toits m'ont aussi beaucoup intrigué.

        En 2010, j'avais acheté un Quietty, une petite machine étonnante qui gérait et surveillait ma maison d'Arcachon. C'était une machine complètement statique avec laquelle j'ai eu plus de 18 mois de fonctionnement entre 2 boot. J'en parle au passé car elle est tombée en panne au début du confinement. Je vais sans doute la remplacer par un raspberry.

        Il me tarde d'avoir des machines qui démarrent en moins d'une seconde sur un SSD sans passer par in BIOS UEFI et sans partition FAT32 sur un support GPT.
        C'est un peu une lettre au père Noël que je fais là, mais je pense que c'est en ton pouvoir.

  • # Merci !

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

    Merci pour ce que vous faites, j'ai travaillé pendant longtemps sur du matériel HP avec des DL et j'ai toujours beaucoup aimé leur robustesse, leur stabilité et leur ouverture vers linux. Si en plus maintenant on va avoir du logiciel libre dedans c'est fantastique.

    • [^] # Re: Merci !

      Posté par (page perso) . Évalué à 5 (+3/-0). Dernière modification le 13/05/20 à 09:08.

      En parallèle des serveurs, cela pourrait être intéressant de le faire aussi sur les commutateurs dont l'espérance de vie est plus grande que les serveurs. Avoir un commutateur / routeur libre serait top pour une maintenance très long terme.

      • [^] # Re: Merci !

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

        Tu parle de https://www.openswitch.net/ ou de Cumulus (récemment racheté par nVidia) ?

        « 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: Merci !

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

          Ou Interface Masters qui propose des switchs OpenSwitch et OCP.

          • [^] # Re: Merci !

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

            Je rajoute : cela va-t-il dégager cette s…. d'IME ?
            Purism propose un serveur Coreboot, sans IME : https://puri.sm/products/librem-server/

            • [^] # Re: Merci !

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

              Il existe déjà des switch avec des ARM ou des PPC, donc je ne vois pas le problème à dégager l'IME.

              « 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: Merci !

                Posté par . Évalué à 5 (+3/-0). Dernière modification le 13/05/20 à 15:40.

                Oui comme dit dans le nourjal, il y a OpenBMC et ça tourne sur ARM. C'est ce genre de SoC qui est installé sur une partie des cartes mères OpenPower.

        • [^] # Re: Merci !

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

          Je pensais à la couche firmware des commutateurs, pas forcément à la couche logicielle par dessus. Je n'ai pas testé Cumulus avec avec lui, tu charges 100% des firmwares de la boiboite ?

          • [^] # Re: Merci !

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

            Oui, tu charge un gros firmware proprio de chez broadcom pour la puce du switch. Je ne sais pas ce qu'il en est pour les asic Mellanox.

            « 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: Merci !

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

              Je sais qu'on peut changer d'OS sur les commutateurs DELL. Est-ce que quelqu'un a déjà essayé ?

              • [^] # Re: Merci !

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

                Ce n'est pas possible pour tous (je crois que c'est que la gamme Open Network (ON))

                « 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: Merci !

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

        Le projet SONiC travaille sur ce type de sujets, il est plus dynamique que FBOSS, et supporte par de plus en plus de hardware.

  • # pas là pour faire de la pub pour HPE

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

    Je ne suis pas là pour faire de la pub pour HPE
    ```Ici de la pub pour une entreprise qui fais de l open source ou open hardware, on en redemande. Tu n a pas a te justifier. Notre souhait est que les entreprise fassent de l open source alirs on est prêt a payer pour ça 😉
    
  • # HP-ILO

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

    Peut-être un jour les managers de chez HP se réveilleront.

    J'ai dû un jour redémarrer un serveur critique, la console HP-ILO était buggée, impossible de faire un power cycle de la machine.

    C'est quand même bien HP, la fonctionnalité numero 1 de leur ILO ne fonctionnait pas!

    Ou peut-être il fallair payer une license pour avoir cette fonctionnalité en plus?

    Et si on pourrait virer Java et avoir le clavier d'une console qui fonctionne, ce serait pas mal non plus.

    De tout coeur avec vous!

    • [^] # Re: HP-ILO

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

      Ne t'inquiète pas, chez Dell, c'est pareil.

      « 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: HP-ILO

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

        Je ne peux pas juger pour Dell (le pire c'est qu'en 25 ans de carriere je n'ai jamais utilise leurs serveurs), mais en ce qui concerne iLO meme si je suis persuade que les equipes logicielles font tout ce qu'elles peuvent pour atteindre la perfection, cela reste du logiciel. Mon optique reste de penser que pouvoir offrir le choix est la meilleure maniere de repondre a ces soucis, chacun pouvant utiliser le logiciel qui correspond a son besoin et a ses aspirations. Il n'est pas sure que les logiciels libres resolvent tous les problemes, mais ils offrent la possibilite d'en comprendre la nature si on le souhaite, et de pouvoir collaborer ensemble.

        • [^] # Re: HP-ILO

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

          Je pense qu’il y a aussi beaucoup de code legacy qui n’est pas forcément facilement maintenable et une difficulté à tester. Mais j’ai quand même régulièrement le cas avec des serveurs qui viennent d’être rackés, un qui ne peut pas démarrer avec l’iDRAC.

          « 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

  • # BBQ?

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

    Excellent journal, avec quand même un terme technique non explicité : BBQ ;-)

    Il semblerait que ce soit un appareil à cuisson dans lequel les aliments sont posés sur une grille. Oui, même barbecue est un mot anglais arrivé dans le français dans les années 1950…

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

    • [^] # Re: BBQ?

      Posté par . Évalué à 3 (+1/-0). Dernière modification le 15/05/20 à 13:58.

      Oui, même barbecue est un mot anglais […]

      Je n'ai pas compris cette phrase… tu veux dire que tu ne le découvres que maintenant ?

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: BBQ?

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

        Oui, je ne savais pas que c'était anglais.

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

  • # Mécanismes de protection ?

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

    La difficulté technique repose principalement sur la mise en oeuvre des mécanismes de protection (légitime) des microcodes depuis quelques années (Silicon Root of Trust, et Intel Bootguard en sont quelques exemples). Comment concilier liberté de choix et mécanisme de protection ?

    Heu, perso ça m'intéresse, parce que ça fait longtemps que j'étudie le sujet et que je ne vois absolument pas comment c'est possible… Déjà rien qu'au vocabulaire que tu utilises (« protection »), ça n'augure rien de bon. Mais je suppose que tes compromis sont différents de ceux que je pense acceptables. Aurais-tu plus de détails stp ?

    • [^] # Re: Mécanismes de protection ?

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

      On envisage plusieurs options, une qui tient la corde consiste a creer une chaine de confiance entre nous et les proprietaires. Ce n'est pas l'ideal mais cela permet de garantir la securite de la plateforme avec une minimum de modification pour les clients actuels qui souhaitent rester sur des firmware proprietaires et l'unicite de son usage. A chaque sortie d'usine les machines restent les memes, mais nous avons re-organise le firmware de telle sorte que celui-ci ait un boot loader. Ce boot loader est integre sur la flash signee et evalue le code du firmware par rapport a une clef publique de l'utilisateur et l'ID unique du systeme (chaque BMC en possede un) qui aura ete crypte avec le mecanisme du root of trust prealablement par HPE (etablissement de la chain of trust) et qui valide l'etape de chargement du code du firmware sur la machine qui lui aura ete signe avec la clef privee du proprietaire (uniquement le proprietaire peut le faire). Le mecanisme requiert qu'un canal de confiance soit etabli prealablement entre HPE et le proprietaire pour que nous puissions emettre le blob binaire crypte qui permet a la machine de demarrer avec la clef public fourni et son ID. Il faut le faire qu'une fois, a chaque update de firmware la machine reconnaitra le nouveau firmware via sa signature. Tant que la clef privee du proprietaire n'est pas compromise le systeme fonctionne. Pour changer de proprietaire, nous restons un tier de confiance, et le proprietaire precedant revoque aupres d'HPE l'integration de ca clef publique sur l'ID de la machine, permettant au futur proprietaire de faire une nouvelle demande par rapport a cet ID via une preuve de propriete.

      Ca peut sembler etre une usine a gaz, mais a court terme, cela permet deja d'avancer et ne compromet pas le mode de fonctionnement deja etablit. On etudie d'autres options avec moins de dependances vis a vis d'HPE et/ou sans tier de confiance en utilisant une approche blockchain, mais on doit modifier le hardware, ce que l'on va faire, mais on est sur des cycles de dev de 3 ans sur cet asic, donc soit on attendait trois ans, soit on trouvait un compromis et je prefere avancer comme on dit !

      • [^] # Re: Mécanismes de protection ?

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

        OK donc pour reformuler en français, le « propriétaire » de la machine (je mets entre guillemets parce que pour les logiciels qui tournent dessus c'est un mensonge, il n'en est pas propriétaire du tout ; juste du matériel) peut demander gentiment à HPE de faire valider (signer) sa clé intermédiaire qui lui permettra de faire tourner le(s) firmeware(s) de son choix, pour certaines machines désignées seulement. C'est mieux que rien, mais perso c'est une telle entrave à la liberté de faire tourner ses logiciels que j'ai beaucoup de peine à appeler ça une « liberté de choix », mais bon. Encore moins de décrire la volonté de « protection » comme légitime, mais c'est mon avis perso.

        Le fait que tu décrives le mécanisme en détail sans évoquer de grand système de gestion connu me fait penser que c'est une solution ad-hoc, imaginée par vous dans un coin, et ça ne me rassure pas du tout sur la maturité du truc : ça ressemble à un proto qui a de grands risques de ne jamais voir le jour. Vous basez-vous sur un dérivé de ce qui a été fait pour le Secure Boot sur UEFI (pas que ça soit un système qui ait ma sympathie, mais il a le mérite d'exister), ou alors c'est du BootGuard avec implémentation custom ? Sans parler des questions de gestion, qui sont malheureusement souvent oubliées des concepteurs de ce genre de solution parce que c'est la partie selon moi la plus importante, puisqu'elle concerne les garanties que les utilisateurs peuvent attendre d'un tel système, mais qu'en général c'est la dernière préoccupation des constructeurs. Bref, ça ressemble plus à de la poudre aux yeux qu'à un réel système qui mettrait vaguement en avant l'intérêt de l'utilisateur.

        Ca peut sembler etre une usine a gaz, mais a court terme, cela permet deja d'avancer et ne compromet pas le mode de fonctionnement deja etablit.

        Le principe technique ne me paraît pas tant usine à gaz : les chaînes de confiance à niveaux multiples sont un classique — même si ici tu ajoutes une propriété comme l'ID de la machine —, et je comprends la volonté de rétro-compatibilité avec l'existant. Mais cette volonté de faire du spécifique est pour moi vouée à l'échec. Enfin, toutes les solutions de protection de ce genre sont pour moi pourries, donc d'un côté je suis content qu'elle échoue.

        On etudie d'autres options avec moins de dependances vis a vis d'HPE

        Est-ce une réelle volonté ou un affichage pour faire sembler de ce préoccuper de ce point ?

        et/ou sans tier de confiance en utilisant une approche blockchain

        OK je suis désolé mais quand tu en arrives à sortir ça, pour moi tu es 100% dans le bullshit sans avoir compris réellement le problème. Tu es comme un certain nombre de personne à t'amuser avec de la crypto parce que c'est marrant, mais tu n'as pas compris l'essentiel des problématiques de liberté d'utilisation des machines. C'est un dilemme classique : on met des personne qui croient honnêtement œuvrer à faire des choses bien, mais qui abordent un problème sans les connaissances adéquates. Je sais que tu vas me trouver méprisant, mais je pense que tu devrais réellement te poser la question de ce que tu fais avec les techniques que tu es en train de mettre en place.

        Merci en tous cas pour ces explications des mécanismes sur lesquels tu travailles.

        Après, pour une note de contexte finale sur mon point de vue : perso, je trouve que la libération des firmwares a peu d'intérêt en dehors de la vérification de l'absence de fonction déloyale à l'utilisateur, et je ne cherche pas absolument à les « libérer » : en effet, ce sont des logiciels plutôt fixés et utilisés uniquement au démarrage de la machine, dont l'OS prend vite le relais. Bref, ça n'a pas un intérêt gigantesque en terme de liberté logicielle pour l'utilisateur. Et l'absence de fonction déloyale serait plutôt à chercher dans la publication de code source ou la certification par des organisme spécifique que dans la possibilité de faire tourner un firmware choisit par l'utilisateur, qui sera de toutes façons toujours une solution minoritaire et ne règle pas le problème de manière globale.

Envoyer un commentaire

Suivre le flux des commentaires

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