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 vidéo du talk de Ron ici (https://www.youtube.com/watch?v=iffTJ1vPCSo). La vidéo 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 ce 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 quelque 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 optimistes quant à 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 réduction 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éfléchissant 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 exécuter un kexec d'un kernel de distro standard et monter le système de fichier associé. C'est suffisant pour nos cas d'usage probablement pas pour les vôtres et c'est la dessus dont on a besoin de vos inputs, alors pour une fois n'hésitez pas à me troller je suis sûr 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.
Quoi qu’il en soit, j'espère que cette technologie trouvera un intérêt auprès de notre modeste communauté linux française, les personnes impliquées derrières ont passe un grand nombres d'heures pour la faire fonctionner et les années d'expérience 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 français qui a conçu des salles machines faites pour le free cooling et les équipements Open Compute / Open Power et qui a accepté de nous aider à 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éminé un grand nombre dans la silicon vallée et j'ai toujours ce doux rêve de penser qu'un jour la France pourra être leader en infrastructure. (remarque: on peut l'être sans NERF probablement)
vejmarie
ps: je suis de l'autre côté de l'atlantique, ne m'en voulez pas si je ne réponds pas a vos commentaires "instantanément"
# IPMI, remote management
Posté par claudex . Évalué à 10.
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 vejmarie (site web personnel) . Évalué à 5.
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 claudex . Évalué à 4.
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.
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 vejmarie (site web personnel) . Évalué à 3.
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 Joris Dedieu (site web personnel) . Évalué à 4.
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 vejmarie (site web personnel) . Évalué à 2.
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 Joris Dedieu (site web personnel) . Évalué à 4.
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.
[^] # Re: IPMI, remote management
Posté par FantastIX . Évalué à 2.
vejmarie a dit:
Je crois que tu viens de faire les deux.
# comme le cloud ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
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 claudex . Évalué à 3.
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 vejmarie (site web personnel) . Évalué à 4.
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 Nicolas Boulay (site web personnel) . Évalué à 3.
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 vejmarie (site web personnel) . Évalué à 4.
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 Nicolas Boulay (site web personnel) . Évalué à 4.
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 YannickP . Évalué à 1. Dernière modification le 16 novembre 2017 à 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 vejmarie (site web personnel) . Évalué à 2.
Si, mais c'est de nouveau une usine a gaz, pas forcement necessaire.
[^] # Re: comme le cloud ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
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 Sytoka Modon (site web personnel) . Évalué à 4. Dernière modification le 18 novembre 2017 à 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 ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 7.
félicitations. Tout le monde le sait « nul ne peut servir deux maîtres ». Alors avoir du logiciel
privateurpropriétaire tournant dans une machine…Un peu ignorant dans le domaine où vous œuvrez, la phrase suivante m'intrigue :
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.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: 10⁴
Posté par vejmarie (site web personnel) . Évalué à 10.
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 Pinaraf . Évalué à 5.
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 vejmarie (site web personnel) . Évalué à 7.
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 Tonio (site web personnel) . Évalué à 5.
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 vejmarie (site web personnel) . Évalué à 10.
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 cedric . Évalué à 3.
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 vejmarie (site web personnel) . Évalué à 6.
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 Kerro . Évalué à 5.
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.
# [LWN] Replacing x86 firmware with Linux and Go
Posté par Benoît Laurent (site web personnel) . Évalué à 6.
Il y a un article sur LWN : Replacing x86 firmware with Linux and Go (via reddit)
# coquille
Posté par PolePosition . Évalué à 1.
optimiste quand à notre capacité à atteindre
optimiste quan*t* à notre capacité à atteindre
[^] # Re: coquille
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# Suggestions/expérience sur le boot de serveur
Posté par zerodeux (site web personnel) . Évalué à 3.
Bonjour,
merci beaucoup pour ces journaux et votre travail sur le boot.
En ces temps où il est déjà difficile d'expliquer et responsabiliser des dev(ops) qui piochent n'importe quelle image cloud ou Docker et ne se posent aucune question de sécurité et de chaîne de confiance, aller jusqu'au boot et expliquer qu'il faudrait aussi s'inquiéter du firmware n°1 est une tâche super ardue… Ca me semble pourtant en effet essentiel.
Je vois aussi d'autres avantages : par ex. concernant Meltdown, les maj de microcodes restent étroitement liées aux constructeurs et à leurs BIOS (je peux les faire moi-même depuis Linux, mais le vendeur peut me garantir la couverture de test pour un hard particulier). Avec un LinuxBios je pourrais court-circuiter le vendeur et faire mes tests beaucoup plus facilement…
Et oui, le temps de boot des serveurs c'est un sujet, chez Dell on en arrive à des POSTs délirant de 2 à 3min pour le moindre serveur. Quand on debug un automate ou une panne ça rend le processus extrêmement inefficace. Quand on veut minimiser un downtime sur un service non redondé ou cloudé (et il en reste des tonnes dans la nature), c'est souvent ce qui plombe le SLA. Et objectivement on sait que c'est un indécent par rapport aux réels besoins que la physique impose (stabilisation des alims, allumage en cascade des éléments, etc). Tout POST > 10s devrait pouvoir être considéré comme un défaut de construction :(.
Note historique : j'ai bossé au début des années 2000 sur des Cobalt/Raq (projet Sun) qui utilisaient Linux comme firmware, et c'était tellement bien conçu et ouvert que je pouvais moi-même recompiler des Linux/firmwares sans soucis (sans être dév kernel). Le support Cobalt/Raq était d'ailleurs mainstream dans Linux (au moins pour les 2.2 et 2.4). J'ai ainsi maintenu des firmwares de ces Raq pendant plus de 5 ans après la fin de vie de ces produits. Ces machines étaient triviales à administrer à distance, provisionner, debugger. Elles postaient en 1 à 2s (!). Tous les autres équipements (serveurs, routeurs) me semblent d'une hostilité incroyable depuis cette expérience.
Sur vos questions sur le contexte de boot idéal, je ne sais pas trop ce qu'il pourrait être mais j'ai une bonne idée sur ce qu'il ne pourrait pas être :
Dans le cahier des charges, il me vient à l'esprit :
Et c'est peut être hors sujet, mais si on pouvait obliger la présence d'un support Flash librement utilisable d'environ 512 MB, ça ne coûterait quasiment rien à l'intégrateur, et ça pourrait révolutionner le déploiement de pas mal de serveurs où l'OS est très simple (hyperviseur, filers, routeurs soft, loadbalancers soft, etc.) quand on veut être plus résilient qu'une infra de netboot (qui de plus est pénible à maintenir et scaler).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.