Avons‐nous une chance d’avoir un code plus ouvert pour nos serveurs préférés ?
Coreboot (né LinuxBIOS) a fonctionné durant ses sept premières années sur serveurs, mais il n’est malheureusement plus disponible sur serveurs x86 aujourd’hui ! La faute aux blobs binaires obligatoires pour initialiser la machine, pour lesquels nous n’avons pas d’autorisation de redistribution — voire pas de blobs du tout.
C’est là qu’entre en jeu le projet NERF (Non‐Extensible Reduced Firmware), un autre fils de Ron Minich, déjà père de LinuxBIOS et Coreboot. Ron n’a pas peur des idées folles, et il voudrait contourner les blobs avec un noyau Linux (et ses pilotes !) dans le BIOS.
Sommaire
- Coreboot inopérant
- Alors, avons‐nous une chance d’avoir un code plus ouvert pour nos serveurs préférés ?
- Interfacer le noyau Linux juste après la phase PEI nécessite de résoudre quelques défis intéressants !
- Est‐ce que ça marche sur serveur Open Compute ?
Comme la plupart d’entre vous le savent, je suis un grand supporteur des serveurs libres, pour de multiples raisons que je ne vais pas réexpliquer dans ce journal aujourd’hui. Beaucoup d’entre vous m’ont « challengé » ces derniers mois sur la notion d’ouverture réelle des serveurs libres, et je vous ai longtemps répondu que le monde du logiciel libre ne s’était pas construit en un jour.
C’est la même chose pour le matériel libre, et cela explique pourquoi je suis aujourd’hui plus impliqué dans le développement des outils nécessaires à faire du matériel, plutôt qu’à développer du matériel. J’aime l’analogie qui consiste à dire que développer Linux avec des outils propriétaires serait un non‐sens.
C’est pourquoi je suis un contributeur actif au projet FreeCAD, un utilisateur de KiCAD, et n’avais jusqu’à présent que peu de temps pour me pencher sur la problématique des BIOS. Toutefois, FreeCAD s’améliorant (notamment la version de développement), il est de plus en plus proche d’un statut suffisant pour développer la mécanique d’un serveur. Aussi ai‐je décidé de me ré‐intéresser au sujet des BIOS, que j’avais quitté il y a bien longtemps. J’ai donc constitué mon baluchon et en route pour Denver à ma première conférence Coreboot. Pas forcément à côté de la maison, mais les présentations furent fort intéressantes et effectuées par des contributeurs aguerris du projet.
Coreboot inopérant
Coreboot est le « fils » du projet linuxbios, initié par Ron Minnich à Los Alamos. Ron travaille actuellement chez Google. Coreboot est un BIOS déployé sur la plupart des Chromebook de Google, sur lesquels il fonctionne parfaitement et répond au besoin. Des dizaines de millions de Chromebooks ont été livrés avec Coreboot comme BIOS principal !
Coreboot (né LinuxBIOS) a fonctionné durant ses sept premières années sur serveurs. Son principal usage était dans le domaine du calcul scientifique, mais il n’est malheureusement plus disponible sur serveurs x86 aujourd’hui ! C’est un fort contraste avec les serveurs POWER d’IBM qui s’appuient sur le micrologiciel OPAL librement disponible.
Je suis donc arrivé avec mes tonnes de questions plus ou moins intelligentes, afin de savoir quoi faire pour essayer de refaire fonctionner Coreboot sur serveurs. Et puis mieux comprendre les complexités auxquelles la communauté de développeurs fait face dans ses rapports avec les fournisseurs de composants qui distribuent les informations techniques au compte‐gouttes.
En effet, même si Coreboot est un projet libre sur processeur Intel x86, il doit utiliser un ensemble de blobs binaires pour initialiser la machine. Ces blobs incluent notamment les mises à jour des microcodes des processeurs, leurs interconnexions avec les jeux de puces (chipsets) des cartes mères, les cartes graphiques, la reconnaissance mémoire et quelques astuces secrètes des vendeurs de composants. Ces blobs sont disponibles aux gros consommateurs comme Google, ou à tout un chacun, mais sans autorisation de redistribution. Ce qui limite l’intérêt de généraliser leur usage et ne simplifie pas la vie de Coreboot.
Les serveurs ajoutent en complexité avec la notion de multi‐processeur. Sur puces Intel avec bus QPI notamment, car Intel n’a jamais souhaité fournir de blob binaire pour ce sous‐composant, ce qui rend Coreboot inopérant.
Alors, avons‐nous une chance d’avoir un code plus ouvert pour nos serveurs préférés ?
L’espoir vient d’un projet qui s’appelle NERF (Non‐Extensible Reduced Firmware), lancé par une petite équipe d’ingénieurs de Google (dont Ron) qui a eu l’idée folle d’interfacer un noyau Linux avec la fin de la phase d’initialisation PEI des systèmes multi‐processeurs (je sens que je vous ai perdus).
Depuis quelques années, Intel a introduit les BIOS UEFI (pas une réussite selon moi), qui délimite l’initialisation d’un système en plusieurs étapes :
- l’étape SEC, qui charge les microcodes des processeurs et les démarrent ;
- l’étape PEI, qui se charge d’initialiser le système (détection mémoire et initialisation QPI) ;
- l’étape DXE, qui initialise les bus PCI, exécute différents blobs afin de démarrer le système UEFI. Le contenu des blobs est varié et va des pilotes pour les périphériques, à des piles réseau, à des systèmes de fichiers complexes ou encore à la gestion de systèmes de sécurité SMM.
Tous ces magnifiques blobs, engendrent de sérieux soucis de sécurité, et peuvent avoir très peu d’intérêt pour la prise en charge des BIOS libre. Il apparaît clairement que les phases SEC et PEI resteront probablement propriétaires pour les prochaines décennies, sauf avec le succès possible de RISC-V munis d’un contrôleur mémoire ouvert, ce qui pourrait amener les vendeurs traditionnels à faire un pas en avant. D’un autre côté, nous n’avons pas trop d’inquiétude quant à la sécurité, et peu d’intérêt à réimplémenter pour le moment les phases SEC et PEI avec du code libre tant celui‐ci serait de bas niveau, dépendant des révisions de composants et utile principalement au surcadencement (overclocking), très peu présents dans le domaine des serveurs.
Interfacer le noyau Linux juste après la phase PEI nécessite de résoudre quelques défis intéressants !
Le premier, un peu bébête mais super complexe : faire rentrer notre code de BIOS dans une NVRAM ridiculement petite
La plupart des NVRAM de serveurs font 16 Mio, repartis en deux blocs de 8 Mio chacun, dont un alloué au Management Engine (le machin qui réimplémente IPMI) et le second au code du BIOS système qui inclut les phases SEC, PEI, les blobs DXE et le shell EFI. Or, nous avons besoin d’espace !
L’équipe de Ron a pour cela développé plusieurs outils (attention ne pas les utiliser sans sauvegardes). L’un d’eux s’appelle ME Cleaner, dont l’optique est de supprimer le code du Management Engine et les trous de sécurité associés. Ils utilisent ensuite leur série de UEFITool pour réaliser une « DXE‐ectomie » dans l’optique de supprimer quelques mébioctet des codes DXE (dont un serveur Web !), afin de faire de la place pour Linux.
Sur une carte de type MinnowBoard Turbot, les blobs ME représentent 5 Mio avant nettoyage, et 300 kio après, laissant suffisamment de place pour Linux et un initramfs.
Construire un noyau Linux qui peut rentrer dans un petit espace.
La stratégie adoptée consiste à supprimer tout ce qui n’est pas nécessaire (même la fonction multi‐utilisateur), afin d’avoir un noyau d’une taille inférieure à 1 Mio. Ce noyau est ensuite étendu au fur et à mesure en fonction des besoins.
Tester que tout fonctionne…
… avec une approche pas à pas en démarrant tout d’abord le noyau via le shell EFI en association avec son initramfs présent sur un disque SSD SATA, puis remonter dans la pile au fur et à mesure, jusqu’à démarrer le noyau juste après la phase PEI.
Supprimer le code standard du BIOS…
… et ouvrir la porte à la créativité, tout en améliorant drastiquement la sécurité en employant un projet comme u-root, qui est un autre projet complétement fou, qui réimplémente la plupart des fonctions basiques d’un shell en Go, un langage bien plus sécurisé que C contre les erreurs de programmation et capable de compiler à la volée du code source. Une image de u-root au format bzImage fait entre 3 et 5 Mio
Si vous voulez en savoir plus, voilà une petite vidéo de Ron lors de la conférence Usenix 2015.
Est‐ce que ça marche sur serveur Open Compute ?
Avant que je ne rencontre Ron, la réponse était non. Depuis, nous lui avons fourni un peu de matériel et de support, et après quelques semaines de travail acharné, l’équipe a été capable de démarrer un noyau Linux. Il reste quelques problèmes non négligeables, comme initialiser correctement les interruptions, mais nous sommes proches de quelque chose de fonctionnel (pas pour de la prod, hein).
C’est quoi les prochaines étapes ?
L’équipe de Ron a un programme d’amorçage (bootstrap) complet fonctionnel basé sur u-root avec un client wget, capable de téléverser un nouveau noyau et de le démarrer via kexec, permettant de s’affranchir du vieux et très lent TFTP. Il nous reste à proposer des menus de configuration du démarrage kexec, améliorer les systèmes de déploiement automatique de la solution, travailler sur la sécurisation du démarrage en utilisant un TPM.
Un des avantages en utilisant ces méthodes, c’est que l’on arrive à démarrer un serveur de bout en bout en moins de cinq secondes, là où un BIOS AMI de compétition peut mettre environ deux minutes. On s’affranchit aussi au passage de l’exécution des ROM des cartes PCIe qui sont remplacées par de vrais pilotes présents dans le noyau Linux, bien plus efficaces et à jour.
Le travail de Ron et de son équipe, associé aux serveurs Open Compute, permettra potentiellement de reprendre un contrôle total de son infrastructure. C’était vraiment un élément qui manquait actuellement dans le monde du matériel libre et nous sommes proches de combler ce trou. Il reste énormément de travail et de créativité. L’équipe de Ron est ouverte aux contributions, n’hésitez pas a rejoindre la communauté u-root [dépôt GitHub] et à soumettre vos premiers correctifs.
Supporter des serveurs avec des micrologiciels libres permet aussi d’améliorer la durée de vie des machines en maintenant ce logiciel critique ; on apporte ainsi des solutions techniques plus pérennes.
La bonne question est maintenant : « Qui sera le premier à acheter un serveur fonctionnel avec NERF pour démarrer la machine ? »
P.‐S. : Je tiens à remercier Ron qui a participé a la relecture en version anglaise et j’espère que ma traduction reflète le texte commun sur lequel nous avons travaillé.
Aller plus loin
- Journal à l’origine de la dépêche (298 clics)
- Journaux de vejmarie transformés en dépêche (127 clics)
- Coreboot (202 clics)
- Projet OpenCompute (271 clics)
# Vitesse
Posté par Glandos . Évalué à 6.
Oh oui, c'est pour moi une véritable torture que d'attendre un HP DL80 Gen9 à 3000 € mettre 3 minutes à arriver sur Grub, là où n'importe quel ordinateur d'aujourd'hui met moins d'une seconde. Et je ne comprends pas pourquoi c'est si lent, ça ne devrait pas.
[^] # Re: Vitesse
Posté par Psychofox (Mastodon) . Évalué à 10.
Une machine de classe serveur passe une batterie de test à chaque reboot. C'est plutôt sain au final et ça n'a pas forcément grand chose à voir avec la qualité du bios/firmware.
Mais bon on est en 2017, ce n'est pas vraiment un problème (virtualisation, containers, toussa).
[^] # Re: Vitesse
Posté par Xavier Bestel (site web personnel) . Évalué à 10.
Bof. Il vaut mieux des tests qui puissent s'exécuter à la demande plutôt qu'au boot (là où c'est bien gênant et où en a en général complètement autre chose à faire que d'en examiner les résultats) et plus jamais par la suite, ce qui peut être long pour des serveurs qui tournent H24.
[^] # Re: Vitesse
Posté par SwordArMor (site web personnel) . Évalué à 3.
Le temps de boot d’un serveur n’est clairement pas la priorité des constructeurs. En effet, on passe par le BIOS environ une fois par an. Que le reboot dure une ou quinze minutes ne change pas grand-chose au final…
Et comme dit lors des autre commentaires, un BIOS de serveur va vérifier l’état des alimentations, des ventilateurs, de la RAM, des batteries de secours, des cartes RAID, des cartes réseaux, etc.
[^] # Re: Vitesse
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Et pourquoi aller lire ces valeurs prend plus que quelques ms ?
"La première sécurité est la liberté"
[^] # Re: Vitesse
Posté par freem . Évalué à 3.
parce que lire une valeur ecrite et tester qu elle est encore valide sont 2 choses qui n'ont rien a voir?
[^] # Re: Vitesse
Posté par vejmarie (site web personnel) . Évalué à 5.
Suis pas vraiment d'accord, on peut tester une machine bien plus vite que ce que ne fait un BIOS, qui la plupart du temps utilise du code qui date qui date.
[^] # Re: Vitesse
Posté par freem . Évalué à 2.
Peut-etre que les bios/uefi ne sont pas optimaux, mais tester la totalite de la ram, je doute que ca ne prenne que quelques ms. A une epoque, les tours le faisaient aussi quand on n'activait pas les fastboot et c'etait lent. Le boot rapide moderne l'est uniquement parce qu'il en fait moins je pense.
Et je repondais a un message qui parlait de lire des valeurs, et non de les tester.
Bref, meme si il est probable que lavitesse de test pourrait etre reduite, je doute que ca puisse se faire en moins de 10s, pas avec de grosses quantites (entres autres composants) de ram. Et 10s c'est loin de quelques ms pour moi.
[^] # Re: Vitesse
Posté par vejmarie (site web personnel) . Évalué à 9.
Chaque chip a une bande passante d'environ 50 a 80GB/s. Si tu veux ecrire dans toutes les cellules memoires intelligemment pas en sequentiel comme le font ces idiots de BIOS, il te faut moins d'une seconde pour couvrir 128 GB de RAM avec deux chip. Il suffit par la suite de checker les registres de status ECC et deux trois autres babioles au niveau du controleur memoire. Apres tu peux tester la memoire aussi longtemps que tu veux. Les codes des BIOS sont des vieux trucs bien sequentiels qui prennent leur temps et sont tres bon pour faire croire qu'ils font pleins de choses utiles.
[^] # Re: Vitesse
Posté par freem . Évalué à 3.
Donc, pas besoin de passer trop d'infos sur le bus de la cm? j'ai tendance.a supposer que c'est la le plus gros goulot?
[^] # Re: Vitesse
Posté par vejmarie (site web personnel) . Évalué à 5.
Il n'y a plus vraiment de bus sur les machines, chaque chip sur un serveur a son controleur memoire et la coherence de cache et le traffic systeme est assure par QPI. Si le code initialise correctement la machine en parallele, il n'y a pas de raison que ca ne puisse pas aller vite.
[^] # Re: Vitesse
Posté par freem . Évalué à 2.
Merci pour le mot cle qpi, va falloir que j'etudie "un peu" cette technologie, histoire de pas etre trop idiot quant au fonctionnement des acces ram. Sur ce, m'en vais jouer a choper des infos par le suivi de sources wikipedia :D (en esperant que ce soit pas trop obsolete, mais au pire ca sera moins pire que mon obsolescence actuelle)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1. Dernière modification le 03 juillet 2017 à 13:39.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Vitesse
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Ils sont électriquement point à point, mais au niveau typologique, ce sont des anneaux. Et niveau logique, il s'agit de "network on chip", c'est à dire que des messages circulent. Un read est coupé en 2, pour éviter de geler les communications entre l'aller et le retour.
"La première sécurité est la liberté"
[^] # Re: Vitesse
Posté par yoyz . Évalué à 3.
s/chip/socket/g
Précision, c'est les sockets qui ont chacun une bande passante mémoire de l'ordre de plus de 50GB/s pour haswell et 65GB/s pour broadwell pour 4xDIMM.
[^] # Re: Vitesse
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Je ne pensais même pas un vrai teste de ram mais au reste.
Les testes de bios ne faisait pas de tests complet. Pour mémoire, un bit mémoire peut être coller à zéro, coller à un, ou en court-circuit avec un voisin (qui peut donc être sur une autre adresse)
"La première sécurité est la liberté"
# Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
# Chtite question
Posté par Raoul Volfoni (site web personnel) . Évalué à 7.
Bon d'abord bravo, à la fois pour le journal/dépêche et tout le boulot effectué en amont.
Ensuite m'étant un tout petit peu intéressé à coreboot il y a qq mois de cela j'avais cru comprendre que le Management Engine donnait à Intel les pleins pouvoirs sur la machine et qu'il était dès lors illusoire d'imaginer un serveur totalement libre. Aussi j'avoue ne pas avoir totalement saisi dans ta dépêche si le M.E. était toujours d'actualité avec ce nouveau projet ou s'il était carrément remplacé ?
[^] # Re: Chtite question
Posté par vejmarie (site web personnel) . Évalué à 8.
On est assez violent sur le ME, on efface le code ME de la flash. Il existe plus, il est tue comme on dit. Bon apres faut trouver un moyen de le re-implementer, mais avec l'approche Open Hardware c'est jouable
[^] # Re: Chtite question
Posté par eingousef . Évalué à 5.
De ce que j'ai compris ME Cleaner permet de faire subir une cure d'amincissement au ME, à défaut de l'éliminer complètement. Ça exploite une faille dans la vérification de la signature du ME. Dans l'exemple de la news on passe de 5 Mo de blobs à 300 Ko. Ces 300 Ko ne peuvent pas être éliminés ou désactivés, sauf à trouver une autre faille qui permettrait de le faire.
*splash!*
[^] # Re: Chtite question
Posté par vejmarie (site web personnel) . Évalué à 10.
Le chip ME ne redemarre pas apres un coup de ME cleaner. On est oblige de conserver des entry point avec des call return afin que la machine boot quand meme. Mais globalement, le code de la stack IP ne tourne plus, ce qui est le plus gros trou de securite du merdier.
[^] # Re: Chtite question
Posté par bubar🦥 (Mastodon) . Évalué à 4. Dernière modification le 30 juin 2017 à 11:41.
Les machines/cartes sur lesquelles cette op est faite ne rebootent pas toutes seules après 30mn ? (Il me semblait que le code contenu dans le processeur Arc implémenté dans un des deux bridges (et qui contient la clef privé du me) faisait rebooter la carte après un certain laps de temps s'il n'avait rien reçu du me. C'est obsolète ?)
[^] # Re: Chtite question
Posté par vejmarie (site web personnel) . Évalué à 5.
On a pas trop ce probleme pour le moment. C'est sur les ME serveur ou AMT?
[^] # Re: Chtite question
Posté par bubar🦥 (Mastodon) . Évalué à 4. Dernière modification le 01 juillet 2017 à 09:49.
Sur des machines personnelles, non-amt (ni même lms, d'ailleurs) comme des acer chromebook c710 & c720, c720p par exemple.
C'est l'effet le moins pire, parfois c'est la brique si tout (ex: la partition fptr) du me est retiré ('tout' entend : la partie dans le spi).
[^] # Re: Chtite question
Posté par bubar🦥 (Mastodon) . Évalué à 10. Dernière modification le 01 juillet 2017 à 09:14.
On ne peut pas tout remplacer du ME, à moins d'être fondeur, et du moins pour le moment, car le service se découpe en deux parties distinctes : celle dans la puce spi (puce contenant le chargeur, ses payloads comme une interface bios et une init vga, et le ME [et à côté un grub et/ou directement un noyau s'il reste de la place]) et une partie encore plus obscure que le me spi dans une puce d'architecture arc (argonaut risc proco) contenant une clef privé pour le me. Cette dernière partie n'est pas atteignable pour ré-écriture par des moyens habituels. Par analogie on entends donc souvent "me = code me dans le spi", car c'est la partie essentielle, celle dans laquelle on trouve toutes les goodies (accès dma / oob, réseau, etc ..)
Ensuite ce service se découpe en 2 options : une version 2Mo, une ~6Mo. Ces 2 types/options offrent différent niveaux de possibilités, allant de "pas grand chose" jusqu'à "contrôle total distant", en passant par un "lms" (local management service). Les laptops (et les ordis de bureau), tous, ont à minima la version 2Mo. Certains laptops de classe entreprise ont la version ~6Mo, et les serveurs aussi. Désolé de ne pas être plus précis, je ne maitrise pas le sujet, vejmarie corrigera peut être si grosse bourde.
Un peu de lecture (plus récente que des trucs de 2014 :p)
https://mail.coreboot.org/pipermail/coreboot/2016-November/082333.html
https://mail.coreboot.org/pipermail/coreboot/2016-November/082335.html
https://github.com/skochinsky/me-tools
https://github.com/corna/me_cleaner
https://review.coreboot.org/#/c/19849/ (ce lien juste pour signaler les très belles avancées du projet purism)
& le + vieux :
https://www.kernel.org/doc/Documentation/misc-devices/mei/mei.txt
On appréciera particulièrement la possibilité d'un accès total et complet même en état s2 (veille d'un laptop par exemple)
Les deux parties essentielles sont : désactiver toute la stack réseau du me, et désactiver l'accès au me par le noyau.
Pour un laptop de classe 'parano', désactiver en plus tout ce qui permet d'avoir un accès usb/fw/esata/hdmi -> me.
Les pb rencontrés actuellement sur les laptops semblent variés après un me_cleaner : pb de stabilité et de performances sont rapportés. (Sur des acer c7x, aucun pb.)
À noter que chez amd c'est encore pire, puisque plutôt que d'avoir un proco arc dans un bridge, ils ont carrément foutu un proco arm lambda dans le cpu, dans leur dernière génération, qui semble t il fourni le même type de services (clef privée dans le proco arm, avec lequel l'équivalent du me dans le spi discute au pré-boot)
Il n'est pas illusoire d'avoir un serveur totalement libre :-)
# Pourquoi X86 (Intel)
Posté par abriotde (site web personnel, Mastodon) . Évalué à 4.
Personnellement je pense que si l'on veux se lancer dans un tel projet (et quel beau projet), il ne faut pas viser les processeurs X86 pour la bonne et simple raison qu'ils sont propriété d'Intel (AMD en a une licence a vie). On sera comme évoqué tyrop dépendant des embûches que mettra Intel. En même temps le besoin est réel de disposer d'un serveur vraiment libre (A défaut de A à Z avec le plus de garantis notamment dans l'armée). Pour moi il vaudrait mieux se baser sur une architecture ARM bien mieux spécifié (même si elle n'est pas libre) ou mieux un processeur libre (Power, RISC-V ou autre). Même si les performances sont inférieur dans 10, 20 ou même peut-être 30 ans on aura beaucoup mieux à l'image de Linux. rappelons que Linux a pris pour base UNIX et non Windows car il y avait des chercheurs documentant un peu UNIX contrairement à Windows/Mac.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Pourquoi X86 (Intel)
Posté par SwordArMor (site web personnel) . Évalué à 1.
Certes, mais compare le nombre de serveurs tournant avec des processeurs x86 et ceux tournant sur autre chose. Tu vas vite te rendre compte que si tu veux toucher un peu plus que les chercheurs, il faut supporter le x86.
[^] # Re: Pourquoi X86 (Intel)
Posté par abriotde (site web personnel, Mastodon) . Évalué à 2.
Non ce n'est pas un argument pour toucher du monde il faut un produit intéressant, pas un produit qui soit certain d'être toujours à la traîne. Linux touchait beaucoup de monde a ses début? Et UNIX ne touchait que les chercheurs et quelques rarissimes expert informatiques.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Pourquoi X86 (Intel)
Posté par ZeroHeure . Évalué à 7.
Il y a au moins deux énormes différence :
Corollaire logique, Linux a vite touché pas mal de monde (je le sais, j'y étais), la première grosse installation a été sur des machines de tri du courrier à la poste américaine vers 1993.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Pourquoi X86 (Intel)
Posté par vejmarie (site web personnel) . Évalué à 4.
Ca depend a combien tu valorises ton bras ;). Treve de plaisanterie on propose des serveurs bi xeon, avec 64 GB de RAM et un SSD a moins de 750$. Ok c'est chere mais c'est pas non plus la fin du monde.
[^] # Re: Pourquoi X86 (Intel)
Posté par freem . Évalué à 3.
tu compares avec linux, qui a ete code par un etudiant. Je doute qu'il pouvait lacher autant juste pour jouer. 750€ c est pas rien a l echelle d'un projet volontaire (ou de petites boites. en fait, faudrait savoir quels sont leurs soutiens economiques), surtout s'il faut en acheter plusieurs…
[^] # Re: Pourquoi X86 (Intel)
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Faut arreter à l'époque du lancement de Linux, pour 1500€, le PC était de l'entrée de gamme. un "gros" PC coutait 3000€.
"La première sécurité est la liberté"
[^] # Re: Pourquoi X86 (Intel)
Posté par ZeroHeure . Évalué à 3.
Je ne critique pas le prix, il est normal pour un serveur. Je critique abriotde qui fait la comparaison avec le noyau Linux, en oubliant qu'on ne peut pas tester des serveurs aussi facilement. Pour toucher du monde, le prix ça compte.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Pourquoi X86 (Intel)
Posté par whity . Évalué à 2.
Où ?
64 GiB de RAM ça coûte pas loin des 750$, et encore, pas en ECC. Il manque pas un chiffre devant ou derrière ?
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Pourquoi X86 (Intel)
Posté par vejmarie (site web personnel) . Évalué à 5.
En recertifie en DDR3, avec des chips 2680v2 (2). On propose des racks complets 20 serveurs, dual Xeon 2680v2, 64GB de RAM, 10Gbps ethernet, 2TB de stockage a 15 500 $, ca te fais le serveur aux alentours de 750 $US. (avec le rack c'est plus chere, y a le rack et les cables).
Pour faire du dev ou de l'infra s'est juste de la balle.
[^] # Re: Pourquoi X86 (Intel)
Posté par whity . Évalué à 4.
Ok, ce n’est pas du neuf.
Ça reste complètement imbattable comme tarif (750$, c’est même pas le prix du processeur). Vous avez récupéré un stock tombé du camion, ou bien ? :)
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Pourquoi X86 (Intel)
Posté par vejmarie (site web personnel) . Évalué à 8.
Nop, on rachete les systemes qui sortent des datacenters hyperscale, et on les demonte et recertifie
[^] # Re: Pourquoi X86 (Intel)
Posté par YvanM (site web personnel) . Évalué à 2.
Je serais moi aussi très heureux de savoir où on peut acheter ce genre de matériel !
[^] # Re: Pourquoi X86 (Intel)
Posté par steph1978 . Évalué à 4.
Ça s'achète où ?
[^] # Re: Pourquoi X86 (Intel)
Posté par YBoy360 (site web personnel) . Évalué à 0.
Plein de monde passe sous arm. ARM est une alternative très serieuse pour les serveurs. Nous nous sommes dessus en phase de test. Les parts de marché actuelles ne signifie rien.
[^] # Re: Pourquoi X86 (Intel)
Posté par Antoine . Évalué à 5.
Plein de monde passe sous ARM mais ce n'est pas visible dans les parts de marché ? Y a une contradiction là…
[^] # Re: Pourquoi X86 (Intel)
Posté par YBoy360 (site web personnel) . Évalué à -3.
Les parts de marché reflètent le passé, pas l'avenir. Je suppose que pour avoir une explication aussi trivial à te fournir, tu dois vendre du Intel…
[^] # Re: Pourquoi X86 (Intel)
Posté par Antoine . Évalué à 4.
Tu as dit « Plein de monde passe sous arm ». Ce n'est pas l'avenir, c'est le présent. Cela donc se voir dans les parts de marché présentes.
[^] # Re: Pourquoi X86 (Intel)
Posté par vejmarie (site web personnel) . Évalué à 10.
Les processeurs Power d'IBM avec OPAL sont deja une alternative. ARM est vraiment pourri comme architecture en ce moment. On travaille sur RISC-V, mais il faut trouver un moyen de lui mettre un controleur memoire correct. Comme je le disais, on va revolutionner le monde, mais pas en un jour malheureusement. Les cycles hardware sont longs, tres longs. Ils sont couteux tres couteux, et complexes.
[^] # Re: Pourquoi X86 (Intel)
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 29 juin 2017 à 18:05.
Pourquoi dis tu qu'ARM est vraiment pourri? C'est pour avoir quelques chose de viable rapidement que je suggère ARM en premier plutôt que les projets libres encore trop en retard (sauf si tu dis le contraire). ARM représente je pense un compromis "négociable". D'autant plus qu'il existe des carte vraiment Open-Source et viable autour de processeur ARM mais pas en x86 pour les mêmes raisons.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Pourquoi X86 (Intel)
Posté par vejmarie (site web personnel) . Évalué à 8.
Le probleme d'ARM s'est qu'il n'y a pas de standard pour les systemes d'interruptions et l'initialisation des chips c'est un vrai cauchemard sans compter les differents mode supportes par les chips.
[^] # Re: Pourquoi X86 (Intel)
Posté par Nicolas Boulay (site web personnel) . Évalué à 9.
Si j'ai bien compris, il est impossible de faire une distribution binaire universelle avec ARM. Chaque SOC a besoin de bidouille particulière pour démarrer, et le Linux doit savoir sur quoi il tourne sous peine de tout bloquer ou de ne pas démarrer.
Ce qui manque à ARM, c'est un standard comme celui du PC : réglage des timing de la RAM, accès standard à la RTC, accès standard à un lien série, moyen de boot standard (copie d'un bout de mémoire depuis un périphérique dans la RAM et démarrage sur ce point), découverte standard des périphériques et autres "Core".
"La première sécurité est la liberté"
[^] # Re: Pourquoi X86 (Intel)
Posté par vejmarie (site web personnel) . Évalué à 4.
Exact tu as tout compris, et c'est sans enoncer les problemes de jeux d'instruction pas toujours super bien standardise etc …
[^] # Re: Pourquoi X86 (Intel)
Posté par Nicolas Boulay (site web personnel) . Évalué à 8.
Là, tu m'étonnes. Pour moi, c'est un petit peu moins le bordel qu'un x86. Tu as les jeux d'instruction ARMv5 ARMv6 ARMv7 … les variantes thumb et thumb2, et le 64 bits. Il y a eu une blague avec les perf du simd neon, mais c'est tout.
Il n'y a pas de groupes d'instruction inclus ou pas comme le fait bêtement intel (résultat ces instructions spécifique sont largement sous utilisé). D'ailleurs, je pense que les OS et logiciel sont resté si longtemps en pure 32 bits, à cause de la bêtise de sortir les atom en 32 bits only, ce qui a fait perdre 10 ans à tout le monde. tout ça pour économiser quelques centimes à la production…
"La première sécurité est la liberté"
[^] # Re: Pourquoi X86 (Intel)
Posté par Anonyme . Évalué à 5.
Les cartes de type Olinuxino, Beagleboard soit-disant Open Source ont trop souvent des limitations de durée de vie ou de fonctionnalité à cause de leurs pilotes propriétaires pas mis à jour (par exemple, c'est le cas de toutes les cartes à base de Allwinner : pas merci Sunxi). Ce sont principalement des problèmes dus au autres composants intégrés dans le SOC (GPU, WiFi, etc.) qui ne sont certes pas toujours utilisés pour un serveur mais qui pourraient l'être selon les projets. En résumé, sur ces cartes il faut choisir entre sécurité et nouveautés d'un noyau récent qui ne contient pas tous les pilotes ou les fonctionnalités complètes fournies par les composants du SOC dont les blobs ne sont pas portés vers les nouveaux noyaux.
C'est d'ailleurs l'un des gros problèmes d'ARM et du modèle SOC : Si un des maillons n'offre plus de support c'est toute la chaine de MÀJ qui est cassée en aval. C'est récurrent dans les appareils nomades, embarqués ou tous les appareils dédiés à la domotique. C'est une grosse faille de l'internet des objets et des appareils mobiles utilisant une quelconque connexion extérieure.
Note qu'on a déjà eu le coup dans l'archi x86 avec certains SOC Intel contenant un GPU PowerVR complètement inutilisable de par l'instabilité de ses pilotes. Ces SOC sont dans des ordi portables ou des cartes mini ITX et sont inutilisables en bureautique ou multimédia.
De ce que je connais, ce qui se rapproche le plus d'une carte ARM "vraiment Open-source" c'est le Raspberry Pi et ce n'est qu'une marque, avec des SOC bien particulier et des cartes très peu évolutives qui ne sont pas vraiment conçues pour un usage professionnel en rack serveur ou des opérations critiques.
[^] # Re: Pourquoi X86 (Intel)
Posté par Tangi Colin . Évalué à 7.
je m'insurge sur le fait de dire que la carte la plus ""Open-source" c'est la Raspberry PI, ce SOC est une infamie, c'est un gpu sur lequel ils ont collé un bout de cpu, le système d'init est complètement custom, y a pas de Global interrupt controller mais un truc custom qui passe par le gpu. Il a fallut super longtemps avant d'avoir un bootloader libre pour ce SOC.
Y a juste eu une énorme buzz autour de cette carte et donc une grosse traction de la communauté derrière mais je préfère mille fois le boulot fait par TI avec ses beagleboards si on veut comparer ceux qu'y ont l'approche la plus "Open-source".
[^] # Re: Pourquoi X86 (Intel)
Posté par Anonyme . Évalué à 2.
Je suis d'accord avec toi pour le premier RPi, c'est une horreur. Les deux suivants sont un peu plus propres mais c'est pas encore ça.
C'est au bon vouloir de Broadcom et il a fallu du temps pour qu'ils lâchent enfin les specs du VideoCore IV (et encore, c'était même pas pour le modèle des RPi). Le fait qu'il y ait une grosse communauté permet d'assurer une pérennité de l'ouverture sur les prochaines itérations.
Pour la Beagleboard (ou même OpenPandora/Pyra) le problème est que TI utilise des GPU PowerVR dont la situation est pire que les Mali. Alors OK c'est standard pas comme chez Broadcom et ça peut être utilisé dans l'industrie sans soucis dans du headless parce que TI est bien plus sérieux que Allwinner mais toute la partie GPU reste une boite noire dont le support dans le temps dépend entièrement de Imagination. Comme je le disais, Intel a déjà fait les frais d'utiliser des GPU PowerVR dans ses SOC.
[^] # Re: Pourquoi X86 (Intel)
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
Concernant le contrôleur mémoire, cela vaut peut être le cout de contacter l'auteur du projet http://opencores.org/project,hpdmc c'est un français (Sébastien Bourdeauducq), la NASA a réutiliser son contrôleur mémoire. J'imagine qu'il doit pouvoir le modifier pour des bus mémoires récents, voir même l'intégrer dans le pipeline d'un cpu.
"La première sécurité est la liberté"
[^] # Re: Pourquoi X86 (Intel)
Posté par vejmarie (site web personnel) . Évalué à 7.
Bonne idee je vais regarder
[^] # Re: Pourquoi X86 (Intel)
Posté par cedric . Évalué à 6.
Tu ne penses pas que la license GPL peut etre problematique pour faire un ASIC, car la plus part des usines viennent avec leurs propres blocs et bonne chance pour avoir ca sous GPL :-)
[^] # Re: Pourquoi X86 (Intel)
Posté par vejmarie (site web personnel) . Évalué à 5.
salut cedric, si ca risque. A mon avis va falloir tout refaire :(, ce qui est un exercice au combien complexe quand tu ne maitrise pas la techno de gravage. Les IP Block I/O vont etre les plus chiants a gerer. Qui veut se lancer la dedans ?
[^] # Re: Pourquoi X86 (Intel)
Posté par Nicolas Boulay (site web personnel) . Évalué à 4. Dernière modification le 03 juillet 2017 à 10:12.
La GPL ne s'applique pas sur un résultat hardware mais sur les plans/code et autres. Il y a aussi une exception pour tout ce qui est considéré comme du "système", de l'OS. J'imagine que des bloc d'IO bas niveau peuvent être vu de cette façon.
Ensuite, le principe de la GPL est d'utilisé la loi sur les licences dérivés (traduction, interprétation habituellement). Pour que NVIDIA puisse sortir un drivers proprio dans linux, ils utilisent le fait que Linux n'a pas besoin de ce drivers pour fonctionner (indépendance) et idem pour le drivers qui fonctionne sous windows.
Avec un core qui utilise une interface bien définie, il n'y a pas de raisons que cela ne marche pas de la même façon.
"La première sécurité est la liberté"
[^] # Re: Pourquoi X86 (Intel)
Posté par Franck Routier (Mastodon) . Évalué à 1.
Il me semble qu'OpenPOWER est à l'heure actuelle la meilleure alternative à Intel (cf. https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstation par exemple)
Pourquoi ne pas la mettre plus en avant ?
[^] # Re: Pourquoi X86 (Intel)
Posté par Anonyme . Évalué à 2.
vejmarie avait aussi lancé un financement participatif pour un serveur OpenPower avec Coreboot.
Le soucis d'OpenPower c'est le prix de IBM face au tentaculaire Intel et à x86 qui prend beaucoup de part de marché. Même en étant supérieur sur beaucoup de points, le faible volume implique des prix élevés.
[^] # Re: Pourquoi X86 (Intel)
Posté par Kerro . Évalué à 2.
Des prix élevés du genre 30% plus cher, ou 300% plus cher ?
[^] # Re: Pourquoi X86 (Intel)
Posté par Anonyme . Évalué à 5.
Le Talos c'était plus de 1000$ pour un octocore de 2013, auquel il faut ajouter le barebone à 4000$, de la RAM, le stockage, etc.
Ça n'est même pas un serveur, à ce prix tu aurais eu une grosse machine de travail sur une carte au format ATX.
Avec ce qui sort maintenant du côté x86 (Ryzen, SkylakeX, Threaddripper, EPYC) c'est près du triple du prix à puissance égale pour du Power8.
Power8 c'est une archi bien meilleure en terme de performance par cœur mais hors de prix pour un particulier et souvent obsolète pour une entreprise.
Et pour un Power9 qui sera essentiellement tourné vers le gros serveur bi/quadri-processeur le tarif va s'envoler. La stratégie de IBM est de reprendre le marché des serveurs à Intel, le desktop et l'embarqué ne les intéresse pas donc c'est pour ça que travailler sur la libération de x86 n'est pas vain même si cette archi est une voie de garage.
[^] # Re: Pourquoi X86 (Intel)
Posté par Franck Routier (Mastodon) . Évalué à 3.
Je ne suis pas un spécialiste du matériel, mais la dernière fois que j'ai monté un serveur pour un client, il est sorti autour de 10000 €, pour un bi-xeon, 128Go de RAM et disques SSD.
Ce n'est guère moins cher que ce que proposait la Talos Workstation, et du même acabit en terme de puissance. Surtout, le serveur n'est pas libre, il embarque les backdoor Intel, etc…
[^] # Re: Pourquoi X86 (Intel)
Posté par Anonyme . Évalué à 3.
Ici tu parles d'un serveur bi-processeur tout équipé comparé à un barebone mono-processeur au format ATX, les usages et la capacité sont très différents. Vu le prix de la mémoire qui ne cesse de grimper, la quantité de RAM et de SSD impacte fortement le total. Talos est à comparer avec une autre workstation et là le prix d'une solution x86 est bien en deça.
Pour le côté libre, les autres fabricants n'utilisent pas forcément un système totalement libéré même pour Power8. C'est ce qui a motivé le lancement de Talos ainsi que le serveur Barreleye de Rackspace.
Power8 est gravé en 22nm, consomme et coûte le même prix qu'un Xeon neuf possédant les jeux d'instruction AVX2 (donc extrêmement rapide dans les programmes qui l'exploite) et de virtualisation avancée. Aussi, Intel a beau augmenter ses tarifs sur les dernières générations, AMD est plus abordable et ses nouveaux CPU sont au même niveau qu'un Power8 de 2013/2014.
Encore une fois, c'est pas déconnant de bosser sur la libération des solutions x86.
# u-root
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
u-root semble vraiment à un projet dingue. Cela pourrait être la base d'un linux un peu simplifié (pour VM par exemple).
"La première sécurité est la liberté"
[^] # Re: u-root
Posté par vejmarie (site web personnel) . Évalué à 6.
L'ensemble du projet est un truc de "malade". Ca ouvre vraiment des portes sur des sujets sur lesquels on avait aucune chance de travailler comme le provisionning rapide de systeme
[^] # Re: u-root
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
J'ai toujours été un fan du développement du noyau. J'ai lu avec passion les débats sur les ordonnanceurs de disques, les ordonnanceurs de taches, les systèmes de fichiers, et un peu récemment sur les "buffers madness" du réseau. Mais depuis 5 ans, je trouve que les fonctionnalités se résument à plus de drivers, et rien de bien passionnant.
Le seul truc marrant qui manque, c'est la migration de taches entre PC, ce qui implique des migrations de socket entre autre truc marrant. Bref, ce qui manque c'est une intégration plus grande entre machine, quand on en a plein ensemble. Le cloud est un pourtant un concept qui transforme une grappe de PC, en une seul entité.
Peut être que ce genre de projet va rendre à nouveau le dev kernel intéressant :)
"La première sécurité est la liberté"
[^] # Re: u-root
Posté par freem . Évalué à 2.
Pas faux. Et wayland est/sera moins cloud que X11, en plus, si je me trompe pas… a moins que ça aie changé, la dernière fois (qui remonte) que j'avais regardé un peu, il me semble que wayland n'est pas conçu avec l'aspect réseau à l'esprit (point sur lequel je n'ai pas vraiment d'opinion technique, me doute que ça amène pas mal de problèmes).
[^] # Re: u-root
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
X11 posent d'énorme problème de sécurité qui n'ont jamais été pensé en amont. A priori, faire la transparence réseau avec wayland de façon efficace, est possible mais pas prioritaire (tout le monde s'en fout)
"La première sécurité est la liberté"
[^] # Re: u-root
Posté par xcomcmdr . Évalué à 5.
De toutes façons la transparence réseau de X11 n'a jamais été efficace.
RDP est bien plus efficace.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# GG
Posté par steph1978 . Évalué à 6.
J'ai franchement tripé en lisant le journal.
J'avais été très frustré de ne pas pouvoir appliquer coreboot sur du matos moderne.
Si le travail abouti, on aura beaucoup progressé.
Juste deux remarques de forme qui me sont venues à la lecture :
* le titre "Le premier, un peu bébête mais super complexe : faire rentrer notre code de BIOS dans une NVRAM ridiculement petite" est trop long et on aurai dit une faute de mise en forme sur une phrase. Il faudrait le faire commencer à "faire", en supprimant le début.
* le terme téléverser est une traduction de "upload". Un wget a plutôt tendance à télécharger (= "download") dans le cas qui nous occupe.
[^] # Re: GG
Posté par ZeroHeure . Évalué à 3.
C'est moi (le modérateur) qui suis coupable de ces défauts, quand j'ai transformé le billet de vejmarie en article.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.