Bon et bien l’année démarre sur les chapeaux de roue. Après avoir été touché par le rhume qui traine en région parisienne pour le nouvel an vla-t-y pas qu'on nous annonce le bug du siècle sur les CPU intel et plus généralement ceux qui implémentent un algorithme de type Tomasulo (exécution dans le désordre et spéculative).
Développant sur le projet NERF (et la conf de Ron Minich en vidéo) depuis quelques temps, je me suis tout de suite dit au vue du buzz sur le net que cela allait être le bazar et que l’idée de patcher avec des micro codes et à la hussarde dans les O/S allait avoir pas mal d'effets secondaires. Je me suis aussi demandé, mais comment va faire notre industrie pour patcher toutes les combinaisons de systèmes depuis 1995.
Malheureusement je n'ai pas la réponse à ces questions, mais dans mon soucis de maintenir à jour des "vieilles" machines et de mieux maitriser ce qu'il se passe au niveau des BIOS, j'ai sortie ma trousse à outils et me suis demandé comment faire pour patcher le micro code dans le BIOS sans avoir un nouveau BIOS, mais juste avec le micro code et quelques outils open source.
J'ai ressorti mon bon vieux Winterfell (c'est un serveur Open Compute bi-Xeonv2) qui me sert de plateforme de développement NERF, et me suis dit que ce satané micro code devait être quelque part dans la flash. (pour info cette technique ne marche qu'avec des machines qui supportent UEFI)
Alors, avec deux petits outils pertinents on arrive presque à faire des miracles. Le premier est flashrom. Il vous permet de dumper le contenu de votre flash SPI (le machin qui contient votre BIOS) dans un fichier binaire. Le second est UEFI tool.
Un petit coup de flashrom -p internal -r backup.bin permet de sauvegarder le contenu de votre BIOS que vous allez pouvoir ouvrir avec UEFI tool.
Ouvrez le fichier avec UEFI Tool et cherchez le GUID 17088572-377F-44ef-8F4E-B09FFF46A070 . (ça s'invente pas hein). C'est celui qui correspond au micro code.
Vous allez probablement le trouver à 2 endroits, un dans la zone PEI et un dans la zone DXE. La zone PEI servant à initialiser le hardware, j'aime bien le garder même si il est tout pourri, allez plutôt chercher celui dans la zone DXE. Sur Winterfell, il est parfait car il est vide et fait une taille de 64ko bien supérieur au 15ko du nouveau.
Un chti clique droit sur le DXE et remplace le body par le binaire de votre nouveau microcode. On sauvegarde le tout sur le disque et on reflash avec flashrom -p internal -w monnouveaubios.bin. On éteint pas la machine pendant ce temps hein !
Au prochain reboot soit vous avez briqué la machine et ça va être un peu complexe, soit ça c'est bien passé et vous voila avec le nouveau micro code d'actif car pour une fois UEFI aura fait le boulot. En effet un des DXE contenus dans la plupart des BIOS s'appelle UpdateMicrocode, et a pour job de vérifier si un nouveau micro code est dispo dans la flash et si oui ben il le charge.
Avantage, ben vous gardez votre bon vieux BIOS, pas besoin d'attendre un update tout buggé potentiellement, et vous avez le nouveau micro code.
Inconvénient si ça marche pas ça peut-être chaud pour récupérer la machine, il vous faudra un flasher SPI la plupart du temps, ça se fait. Mais si vous avez un grand parc de machines homogène et que ça marche sur une machine ben ça peut aller très vite, se faire en O/S en live etc etc …
Du coup j'en ai profité pour intégrer le bazar sur NERF, et en ai profité pour valider le bon fonctionnement de VTd avec NERF. Ça fonctionne, mais franchement Intel pourrait faire un effort dans l'activation de ce mode, le coup du power cycle et du lock bit sur la fonctionnalité est juste un cauchemar.
Sinon, j'ai profité aussi des vacances pour reconstruire un installer Ubuntu complet qui fonctionne avec NERF (en même temps quand on vire tout le support UEFI et les callback BIOS, les kernels modernes font un peu la tête et du coup installer l'O/S on va dire que s’était plus que challenging), basé sur Xenial. En parallèle l’équipe de Google a donne un sacré coup de pouce pour faire fonctionner le boot réseau, et c'est franchement le nirvana de booter en moins de 15s un serveur du power on au prompt login.
Voila tout est prêt pour que nous mettions en ligne notre premier cluster NERF/Linux sur le net la semaine prochaine chez Data4. Comme quoi l'Open Source, la maitrise complète de la stack logicielle ben ça a du bon !
Il nous reste encore du taf, mais on est dans les temps pour livrer les premières machines NERF/Linux sur le second trimestre 2018 !
# Euh…
Posté par MCMic (site web personnel) . Évalué à 8.
Ok, mais c’est quoi NERF ?
[^] # Re: Euh…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Des pistolets à fléchettes en mousse ?
[^] # Re: Euh…
Posté par Pinaraf . Évalué à 10.
C'est un projet qui vise à injecter dans la mémoire flash sur la carte mère, à la place de la partie «haute» de l'UEFI, un noyau Linux…
Cf https://linuxfr.org/news/un-pas-en-avant-pour-les-serveurs-libres-le-projet-nerf
[^] # Re: Euh…
Posté par vejmarie (site web personnel) . Évalué à 9.
A terme on envisage de tout remplacer en dehors de la partie PEI :)
[^] # Re: Euh…
Posté par Le Gab . Évalué à 1. Dernière modification le 10 janvier 2018 à 21:36.
Dites vejmarie, est-il possible de la refaire sans la caricature du gars ultra techos, svp? ;)
Qu'est ce que :
- DEX
- PEI
- NERF
Leurs relation… et finalement quoi ça palie à meldown/spectre?
Parce que si ça marche, c'est peut-être le truc qui pourrait pousser à l'ouverture de ces composants, non?
Merci pour le journal et d'avance pour les réponses.
[^] # Re: Euh…
Posté par Pinaraf . Évalué à 10.
Le rapport à meltdown : aucun, on ne peut pas patcher meltdown en dehors d'une modification du noyau.
Le rapport à spectre : il faut déployer la mise à jour du microcode, et le meilleur endroit pour le faire reste le firmware (garantie que c'est fait pour tous les OS notamment)
[^] # Re: Euh…
Posté par Renault (site web personnel) . Évalué à 10.
Personnellement, si je suis pour l'ouverture du matériel, je ne crois pas qu'un processeur ouvert aurait empêché nos déboires actuelles avec Spectre et Meltdown.
Déjà parce qu'un processeur (tout comme un logiciel ouvert) n'empêche pas l'existence des failles et des bogues. Ça te permet de vérifier par toi même mais cela ne devient pas magiquement 100% sûr.
De plus, nous sommes dans le monde matériel. Suivant le problème, comme ici, la solution vient par une mise à jour du matériel ce qui n'est pas gratuit ni immédiat. Bref, il faudrait probablement toujours produire et racheter du matériel neuf pour régler ce genre de soucis (sans pertes de perf).
Le libre est une bonne chose, mais ce n'est pas une réponse à tous les problèmes techniques.
[^] # Re: Euh…
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Si le microcode est chargé dans une ram au démarrage, cela aurait pu être possible d'invalider la ligne de cache préchargé, par exemple.
"La première sécurité est la liberté"
[^] # Re: Euh…
Posté par Le Gab . Évalué à 2.
Je ne parlais pas du CPU mais toute la partie initialisation (UEFI, firmware etc..)
Oui, l'OpenSource n'est pas immunisé de base, je parle plus dans l'optique de matériel EoL (end of life) qui marche encore très bien mais qui ne se verrait pas recevoir de correctif.
Après tout, c'est ce que fait en quelques sorte l'équipe de Vejmarie en "retapant" du matériel décommissionné.
# Des liens ?
Posté par showtime . Évalué à -1.
Pourrais-tu mettre un lien vers:
- NERF
- flashrom
- UEFI tool
Ainsi qu'un lien wikipédia pour les termes techniques, sigles et autres accronymes que tu utilises…
Pourrais-tu formater les lignes de commande que tu tapes correctement ?
[^] # Re: Des liens ?
Posté par vejmarie (site web personnel) . Évalué à 10.
Malheureusement une fois le journal poste, je ne peux plus l'editer.
Pour NERF NERF
Pour flashrom flashrom
Pour UEFITool github
[^] # Re: Des liens ?
Posté par ZeroHeure (site web personnel) . Évalué à 4.
corrigé, merci
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Des liens ?
Posté par Mathias Bavay (site web personnel) . Évalué à 1.
J'ai joué récemment avec flashrom, et j'ai buté bêtement sur un problème: les noyaux récents empêchent de faire un tel dump de mémoire. Normalement, il faut donc recompiler le noyau en ajoutant l'option qui va bien. Évidement, je suis tombé sur un bug de Debian qui gère mal mon disque crypté et du coup mon nouveau noyau n'est pas capable de booter mon système. J'ai cherché un système live sur clef usb qui ait flashrom, il y en a, mais aucun n'a l'air d'avoir le noyau avec les bonnes options (donc impossible d'utiliser flashrom pour dumper/charger le bios par exemple). Est ce que quelqu'un connaît une version sur clef usb qui fonctionne? (donc on copie sur la clef, on reboot, on dump et c'est finit en deux temps trois mouvements au lieux de semaines à passer de bugs en bugs).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Des liens ?
Posté par Nitchevo (site web personnel) . Évalué à 10.
man courtoisie
Aucune entrée de manuel pour courtoisie
Ca doit être le problème
[^] # Re: Des liens ?
Posté par Tonio (site web personnel) . Évalué à 2.
Vu l'avancé technique que nous offre le rédacteur, je lui pardonne facilement
Sinon pour des machines NERF, c'est des machines du marché ou des versions particulières?
Vous travaillez avec un fournisseur?
Bon courage pour la suite même si certains aspects sont très techniques (mais on aime cela)
[^] # Re: Des liens ?
Posté par vejmarie (site web personnel) . É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: Des liens ?
Posté par ZeroHeure (site web personnel) . Évalué à 4.
t'as oublié le lien
https://sales.horizon-computing.com/
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Des liens ?
Posté par vejmarie (site web personnel) . Évalué à 9.
Voulais pas polluer le forum avec du marketing (meme si on a besoin que des gens nous achetent des machines pour continuer nos travaux de R&D), et en plus en France y a vraiment pas grand monde qui achete de l'Open ce qui me laisse d'ailleurs perplexe meme si ca progresse.
[^] # Re: Des liens ?
Posté par ZeroHeure (site web personnel) . Évalué à 10.
Tu sais, les journaux que tu postes ici, c'est un des trucs les plus passionnant depuis les débuts du kernel Linux : Qy-share, RuggedPod, OpenCompute, … et maintenant NERF. On en a souvent transformé en dépêches, en regrettant que tu n'en ai pas dit beaucoup plus long. En plus Fabrice Bellard vient à tes conf! Tu es en train de devenir une bestiole mythique.
Alors, fais-toi de la pub, on ne t'en voudra pas.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Des liens ?
Posté par legranblon (site web personnel) . Évalué à 1.
On ne peut pas plusser deux fois … dommage.
[^] # Re: Des liens ?
Posté par Anonyme . Évalué à 6.
Il y a tout plein d'infos dans les journaux précédents: https://linuxfr.org/users/vejmarie
# Mise à jour des microcodes sur bios Award et AMI
Posté par Olivier Esver (site web personnel) . Évalué à 5.
Je l'avais déjà fait sur 2 de mes PC, un avec un bios AWARD et l'autre avec un bios AMI.
Par contre je ne garantie en rien le bon fonctionnement, sur l'un j'avais même du reflasher en spi la rom car je l'avais foirée une 1ere fois.
S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
# Et une version OS ?
Posté par Sébastien Koechlin . Évalué à 5.
Il me semblait que le paquet https://packages.debian.org/stretch/intel-microcode (et le correspondant https://packages.debian.org/stretch/amd64-microcode) permettaient justement de déployer un nouveau microcode. Des paquets équivalents existent sur d'autres distribution (et sous Windows m'a-t'on dit).
Je ne suis pas aller vérifier, mais dans mon esprit, le microcode est chargé au démarrage de l'OS (peut-être dans le ramdisk) si nécessaire, permettant ainsi de corriger le problème sans avoir à se lancer dans un flashage de BIOS (pour ceux qui ont un constructeur qui fait l'effort de sortir un nouveau BIOS).
[^] # Re: Et une version OS ?
Posté par vejmarie (site web personnel) . É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: Et une version OS ?
Posté par Sébastien Koechlin . Évalué à 7.
Moi je me dis rétrospectivement que vu la complexité des processeurs actuels, ils font plutôt du bon boulot de ce coté. Je suis plus inquiet de leur gestion de la sécurité et des pouvoir qu'ils ont donnés au ME.
Certes, il y a des bugs, mais sur les 25 dernières années, je n'en ai jamais vu un me poser des problèmes. Le bug de la FPU sur les premiers pentium a fait surtout du bruit, mais techniquement sans grande conséquence pour 99.99% des clients (pifométriquement). Après j'ai entendu parlé deux trois fois d'un truc qui présentait des risques; avec des contournements dans le kernel; mais ça ne m'a jamais empêché d'utiliser le CPU. Vu la complexité des processeurs actuels, je trouve ça bon.
A l'opposé, je ne compte pas les périphériques internes ou externes qui ne sortent pas correctement de veille, qui nécessitent des contournements dans tous les sens pour être utilisés, dont une partie des fonctions est trop bugués pour être utilisable…
[^] # Re: Et une version OS ?
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 4.
Pour FreeBSD, c'est dans le port sysutils/devcpu-data (en cours de mise à jour pour Intel et AMD).
# 2 microcodes ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Cela n'est pas possible d'avoir 2 microcodes dans le BIOS, avec un mode failback en cas de plantage du nouveau code ?
"La première sécurité est la liberté"
[^] # Re: 2 microcodes ?
Posté par vejmarie (site web personnel) . É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.
# Le rapport avec meltdown et spectre?
Posté par freem . Évalué à 3.
J'ai cru comprendre que ces failles étaient liées au câblage du CPU lui-même, et que justement si on se tape des patchs kernels c'est que changer le microcode ne changera rien? Si c'est bien le cas, pourquoi cette référence?
[^] # Re: Le rapport avec meltdown et spectre?
Posté par vejmarie (site web personnel) . É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: Le rapport avec meltdown et spectre?
Posté par freem . Évalué à 2.
De ce que j'ai compris des patchs, le principe est de supprimer le code kernel des pages mémoire utilisées par les applications, donc un microcodes différent ne changera rien à ça, non? À moins que les microcodes n'interfèrent directement avec le fonctionnement du kernel (me semblerait bien glissant, mais enfin, je n'y connais rien)?
[^] # Re: Le rapport avec meltdown et spectre?
Posté par vejmarie (site web personnel) . É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 Nicolas Boulay (site web personnel) . Évalué à 4.
La connerie de base, si j'ai bien compris, c'est que la prédiction de branchement déclenche le remplissage du cache, même si la lecture est interdite aux adresses de ses pages. Ensuite, une autre lecture mesurant un timing, permet de vérifier la présence en cache ou non de la donnée, ce qui donne une information sur sa valeur.
Pour que cela ne marche pas, il faut que les load spéculatifs fait sur des adresses interdites n'aient aucune différences de timing avec une page non lue dans l’exécution suivante. L'idéal serait de faire la vérification d’autorisation pendant l’exécution spéculative, dans l'ordre et non tout à la fin.
En gros, il ne faut pas qu'une exécution spéculative de code ou de data en provenance de zone interdite, puisse avoir un effet mesurable sur un code (comme le temps d'accès d'un load grâce au cache)
"La première sécurité est la liberté"
[^] # Re: Le rapport avec meltdown et spectre?
Posté par vejmarie (site web personnel) . Évalué à 5.
exact et apres tu peux te retrouver en mode bourrin a mettre des LFENCE partout.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.