c'est une partie de la solution pour meltdown, sur spectre et les attaques qui utilisent les branchements speculatifs, y a moyen de modifier les algorithmes de predictions, d'ajouter qqs instructions assembleurs certains endroits etc etc pour limiter les impacts, et vaut mieux le faire en microcode en fait.
Une partie des problemes sont corriges via microcode/patches O/S. les bugs sont principalement lies a l'algorithme utilise par les processeurs modernes lors de l'execution de code de maniere speculative.
On travaille sur des machines du marche issue du projet Open Compute et Open Power (qui boot deja un firmware linux), et on va dire d'hyperscalers de la silicon vallee (je les nommerai des qu'ils nous en auront donne l'autorisation mais ca va pas tarder et pour certains vous pouvez deviner). Les fournisseurs ne sont pas franchement des innovateurs forts en ce moment. On a eu qqs contacts avec HPe, mais qui ne sont pas alles tres loin, quand a Quanta, Wistron et Foxconn j'en parle meme pas. Le projet va etre integre a part entiere dans Open Compute. Mais on peut deja acheter des machines chez nous.
Si c'est d'ailleurs ce que je propose en ne mettant la mise a jour que dans le DXE et pas dans la partie PEI. Par contre sur la partie fall back uniquement le driver DXE est capable de le faire et il faut le remplacer par celui d'EDK2 si il existe.
Exact, les O/S ont la capacite de recharger les microcodes (linux sait meme le faire en live) ce qui est une bonne nouvelle et me laisse d'ailleurs dubitatif chez certains CSP qui expliquent qu'ils vont devoir rebooter pour prendre en charge le nouveau micro code. L'avantage de le faire dans le BIOS c'est qu'une fois que c'est fait, c'est fait et que si par hasard tu re-installes une vieille distro t'es pas embete ;). Apres au final, tout le ramdam fait me laisse quand meme dubitatif, car pour une fois Intel a pas mal fait le boulot sur la partie capacite de mise a jour de ses produits. (et pourtant je leur tape dessus souvent)
Ca reste une bonne nouvelle de voir un utilisateur comme online se pencher sur des outils comme coreboot. Le seul truc qui est dommage c'est que coreboot n'est pas la bonne option pour le monde des serveurs, c'est d'ailleurs pour cela qu'on a lance NERF/linuxboot avec Ron Minnich le createur de coreboot. On devrait etre capable de demarrer le provionning complet d'une ubuntu avec BIOS Nerf d'ici qqs semaines (avant fin janvier). Pour la petite histoire le probleme de core boot reside dans l'init des bus QPI et la gestion des blobs binaires. L'approche prise par linuxboot reside a s'interfacer apres la phase PEI (qui reste proprietaire) et a ne basculer que sur du code libre (pas d'appels futurs a des blobs binaire)
La gestion des erreurs materiels est une vrai plaie sur serveur car elles sont remontees dans le systeme event log generalement gere en mode SMM et aboutisse dans le ME
Ce que l'on voit c'est la surface de l'iceberg. Le resultat provient d'annees d'engineering issus de Coreboot, et de comprehension des limitations de cette approche.
Exact, et on a trouve qqs astuces du memes acabit pour serveur. (c'est juste un peu plus chaud sur les serveurs a faire marcher, car la partie ME gere plus de trucs)
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.
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 !
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 ;).
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.
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.
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.
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.
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.
pour les bogomips aucune idee ;) Pour les applis ben les serveurs sont utilises par Facebook donc ils font un peu de tout (database, AI, frontaux web etc …). C'est globalement des bi sockets epures nous dirons.
[^] # Re: Le rapport avec meltdown et spectre?
Posté par vejmarie (site web personnel) . En réponse au journal Un peu de NERF et de microcode Intel (merci Meltdown/Spectre). Évalué à 6.
c'est une partie de la solution pour meltdown, sur spectre et les attaques qui utilisent les branchements speculatifs, y a moyen de modifier les algorithmes de predictions, d'ajouter qqs instructions assembleurs certains endroits etc etc pour limiter les impacts, et vaut mieux le faire en microcode en fait.
[^] # Re: Le rapport avec meltdown et spectre?
Posté par vejmarie (site web personnel) . En réponse au journal Un peu de NERF et de microcode Intel (merci Meltdown/Spectre). Évalué à 3.
Une partie des problemes sont corriges via microcode/patches O/S. les bugs sont principalement lies a l'algorithme utilise par les processeurs modernes lors de l'execution de code de maniere speculative.
[^] # Re: Des liens ?
Posté par vejmarie (site web personnel) . En réponse au journal Un peu de NERF et de microcode Intel (merci Meltdown/Spectre). Évalué à 8.
On travaille sur des machines du marche issue du projet Open Compute et Open Power (qui boot deja un firmware linux), et on va dire d'hyperscalers de la silicon vallee (je les nommerai des qu'ils nous en auront donne l'autorisation mais ca va pas tarder et pour certains vous pouvez deviner). Les fournisseurs ne sont pas franchement des innovateurs forts en ce moment. On a eu qqs contacts avec HPe, mais qui ne sont pas alles tres loin, quand a Quanta, Wistron et Foxconn j'en parle meme pas. Le projet va etre integre a part entiere dans Open Compute. Mais on peut deja acheter des machines chez nous.
[^] # Re: 2 microcodes ?
Posté par vejmarie (site web personnel) . En réponse au journal Un peu de NERF et de microcode Intel (merci Meltdown/Spectre). Évalué à 9.
Si c'est d'ailleurs ce que je propose en ne mettant la mise a jour que dans le DXE et pas dans la partie PEI. Par contre sur la partie fall back uniquement le driver DXE est capable de le faire et il faut le remplacer par celui d'EDK2 si il existe.
[^] # Re: Et une version OS ?
Posté par vejmarie (site web personnel) . En réponse au journal Un peu de NERF et de microcode Intel (merci Meltdown/Spectre). Évalué à 8.
Exact, les O/S ont la capacite de recharger les microcodes (linux sait meme le faire en live) ce qui est une bonne nouvelle et me laisse d'ailleurs dubitatif chez certains CSP qui expliquent qu'ils vont devoir rebooter pour prendre en charge le nouveau micro code. L'avantage de le faire dans le BIOS c'est qu'une fois que c'est fait, c'est fait et que si par hasard tu re-installes une vieille distro t'es pas embete ;). Apres au final, tout le ramdam fait me laisse quand meme dubitatif, car pour une fois Intel a pas mal fait le boulot sur la partie capacite de mise a jour de ses produits. (et pourtant je leur tape dessus souvent)
[^] # Re: Euh…
Posté par vejmarie (site web personnel) . En réponse au journal Un peu de NERF et de microcode Intel (merci Meltdown/Spectre). Évalué à 9.
A terme on envisage de tout remplacer en dehors de la partie PEI :)
[^] # Re: Des liens ?
Posté par vejmarie (site web personnel) . En réponse au journal Un peu de NERF et de microcode Intel (merci Meltdown/Spectre). Évalué à 10.
Malheureusement une fois le journal poste, je ne peux plus l'editer.
Pour NERF NERF
Pour flashrom flashrom
Pour UEFITool github
# Bonne nouvelle pour les BIOS "libre"
Posté par vejmarie (site web personnel) . En réponse au journal coreboot sur les serveurs de Online ?. Évalué à 6.
Ca reste une bonne nouvelle de voir un utilisateur comme online se pencher sur des outils comme coreboot. Le seul truc qui est dommage c'est que coreboot n'est pas la bonne option pour le monde des serveurs, c'est d'ailleurs pour cela qu'on a lance NERF/linuxboot avec Ron Minnich le createur de coreboot. On devrait etre capable de demarrer le provionning complet d'une ubuntu avec BIOS Nerf d'ici qqs semaines (avant fin janvier). Pour la petite histoire le probleme de core boot reside dans l'init des bus QPI et la gestion des blobs binaires. L'approche prise par linuxboot reside a s'interfacer apres la phase PEI (qui reste proprietaire) et a ne basculer que sur du code libre (pas d'appels futurs a des blobs binaire)
[^] # Re: Je ne comprends pas le nom
Posté par vejmarie (site web personnel) . En réponse au journal NERF(3) vers des serveurs ouverts. Évalué à 3.
Merci et desole pour tout ces desagrements
[^] # Re: ME est dégageable
Posté par vejmarie (site web personnel) . En réponse au journal NERF(3) vers des serveurs ouverts. Évalué à 8.
La gestion des erreurs materiels est une vrai plaie sur serveur car elles sont remontees dans le systeme event log generalement gere en mode SMM et aboutisse dans le ME
[^] # Re: PC ?
Posté par vejmarie (site web personnel) . En réponse au journal NERF(3) vers des serveurs ouverts. Évalué à 10.
Ce que l'on voit c'est la surface de l'iceberg. Le resultat provient d'annees d'engineering issus de Coreboot, et de comprehension des limitations de cette approche.
[^] # Re: ME est dégageable
Posté par vejmarie (site web personnel) . En réponse au journal NERF(3) vers des serveurs ouverts. Évalué à 6.
Exact, et on a trouve qqs astuces du memes acabit pour serveur. (c'est juste un peu plus chaud sur les serveurs a faire marcher, car la partie ME gere plus de trucs)
[^] # Re: PC ?
Posté par vejmarie (site web personnel) . En réponse au journal NERF(3) vers des serveurs ouverts. Évalué à 7.
Ca doit pouvoir marcher oui. Bon apres il faut qu'on teste c'est un peu comme tout, mais je ne vois pas de limitations techniques.
[^] # Re: Je ne comprends pas le nom
Posté par vejmarie (site web personnel) . En réponse au journal NERF(3) vers des serveurs ouverts. Évalué à 4.
Yep, tu as raison, le decallage horaire a encore qqs effets nefastes ;)
[^] # Re: IPMI, remote management
Posté par vejmarie (site web personnel) . En réponse au journal Vers des serveurs libres, ouverts et sécurisés : NERF (2). É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: Petites questions
Posté par vejmarie (site web personnel) . En réponse au journal Vers des serveurs libres, ouverts et sécurisés : NERF (2). É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
[^] # Re: comme le cloud ?
Posté par vejmarie (site web personnel) . En réponse au journal Vers des serveurs libres, ouverts et sécurisés : NERF (2). Évalué à 2.
Si, mais c'est de nouveau une usine a gaz, pas forcement necessaire.
[^] # Re: Disponibilité de serveurs pour 2019?
Posté par vejmarie (site web personnel) . En réponse au journal Vers des serveurs libres, ouverts et sécurisés : NERF (2). É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 ;).
[^] # Re: comme le cloud ?
Posté par vejmarie (site web personnel) . En réponse au journal Vers des serveurs libres, ouverts et sécurisés : NERF (2). É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: IPMI, remote management
Posté par vejmarie (site web personnel) . En réponse au journal Vers des serveurs libres, ouverts et sécurisés : NERF (2). É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: Et l'ACPI ?
Posté par vejmarie (site web personnel) . En réponse au journal Vers des serveurs libres, ouverts et sécurisés : NERF (2). É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.
[^] # Re: 10⁴
Posté par vejmarie (site web personnel) . En réponse au journal Vers des serveurs libres, ouverts et sécurisés : NERF (2). É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.
[^] # Re: comme le cloud ?
Posté par vejmarie (site web personnel) . En réponse au journal Vers des serveurs libres, ouverts et sécurisés : NERF (2). É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: IPMI, remote management
Posté par vejmarie (site web personnel) . En réponse au journal Vers des serveurs libres, ouverts et sécurisés : NERF (2). É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: lieu
Posté par vejmarie (site web personnel) . En réponse au journal C'est la rentrée, un timing parfait pour un meetup Open Hardware sur Paris @Criteo . Évalué à 3.
pour les bogomips aucune idee ;) Pour les applis ben les serveurs sont utilises par Facebook donc ils font un peu de tout (database, AI, frontaux web etc …). C'est globalement des bi sockets epures nous dirons.