Si le logiciel libre est devenu au fil du temps, et grâce à votre passion, un élément majeur de l’informatique moderne, il n’en va pas de même pour le matériel. Toute personne qui a essayé de libérer son ordinateur de bureau jusqu’au micrologiciel (firmware) de la carte mère, ou qui s’est intéressée à l’évolution du projet Coreboot ces dernières années, le sait : la situation des quatre libertés sur nos stations de travail est actuellement très mauvaise du point de vue matériel. Cette dépêche propose un état des lieux de cette situation.
Sommaire
La situation actuelle
État des firmwares
Le wiki du projet Coreboot (projet visant à analyser le fonctionnement des micrologiciels (firmwares) non libres embarqués sur les cartes mères et à les remplacer, totalement ou en partie, par un firmware libre) détaille cette situation dans un article listant les programmes non libres que Coreboot peut être amené à charger pour permettre le fonctionnement correct de la carte mère. Le site du projet Libreboot (modification de Coreboot visant à se passer totalement de l’exécution de code non libre, sur un nombre de modèles évidemment beaucoup plus restreint) donne des détails sur certains firmwares. Selon le cas, le programme en question peut être optionnel ou absolument nécessaire, son remplacement difficile ou complètement impossible, son potentiel de contrôle sur l’informatique de l’utilisateur négligeable, gigantesque ou simplement inconnu.
Rappelons que la conception de la cartes mères dépend principalement du processeur qui y est rattaché, et que le marché du processeur sur les ordinateurs de bureau est en gros partagé entre deux géants : Intel et AMD. Aperçu de la situation :
Sur les plates‐formes Intel :
le firmware GBE (Gigabit Ethernet) : c’est un petit binaire de 8 Kio, qui contient des informations d’initialisation de la puce Ethernet intégrée à la carte mère. Il ne contient pas de code exécutable et il est possible de s’en passer si on n’utilise pas le port Ethernet intégré à la carte. Sur les plates‐formes GM45/GS45 (génération de processeurs Penryn, chez Lenovo cela correspond à la génération « *00 » : X200, T400, T500, etc., apparus aux alentours de 2008), le GbE a été libéré par rétro‐ingénierie grâce aux efforts du projet Libreboot.
le VBIOS (VGA BIOS, ou VGA Option ROM) : c’est un firmware de quelques dizaines de Kio qui s’exécute sur le processeur principal et permet d’initialiser l’affichage vidéo lors des premières étapes du démarrage de l’ordinateur. Il est possible de s’en passer sous GNU/Linux, le système d’exploitation initialisant lui‐même l’affichage vidéo lors du chargement du noyau. Cependant, l’écran restera noir durant les premières secondes de l’amorçage, avant que le noyau ne prenne le relai. Il est possible de contenir l’exécution du VBIOS avec Coreboot, au moins en partie (celui‐ci peut encore accéder à des sections arbitraires de la RAM directement). Comme pour le contrôleur Ethernet, il n’est pas utilisé si l’on utilise un autre processeur graphique que celui intégré à la carte mère. Dans ce cas, c’est un autre VBIOS, présent dans la carte graphique et probablement lui aussi non libre, qui sera utilisé. Sur les ordinateurs Thinkpad T60 (plates‐formes i945, génération de processeurs Yonah et Merom, apparus aux alentours de 2006) utilisant les processeurs graphiques Intel GMA 950, le VBIOS a été libéré par rétro‐ingénierie grâce aux efforts du projet Libreboot.
le microcode processeur : c’est un petit firmware qui sert à mettre à jour le microcode interne du processeur. En effet, les microprocesseurs Intel embarquent une mémoire morte (ROM) contenant un microcode nécessaire au bon fonctionnement du processeur. Ce microcode est historiquement considéré comme acceptable par la FSF, car en lecture seule et non mis à jour, il peut être considéré comme du matériel. Depuis la fin des années 1990 cependant, Intel distribue des mises à jour de ces microcodes pour résoudre des défauts dans les microcodes embarqués. Ces mises à jour sont placées dans les BIOS par les constructeurs de cartes mères. Depuis quelques années, on commence même à voir des mises à jour distribuées au niveau du système d’exploitation lui‐même (si vous utilisez Debian, par exemple, vous avez peut‐être constaté qu’on vous recommandait d’installer un paquet non libre avec un nom du style « intel-microcode »), car les mises à jour du constructeur via le BIOS ne sont plus toujours suffisantes. On pense qu’il est possible de se passer des mises à jour du microcode processeur si l’on exclut les générations de processeurs les plus récentes. Il est difficile cependant de donner une date précise, car cela dépend de la génération, des bogues que le microcode est supposé corriger, peut‐être aussi du numéro de série. Des gens ont signalé des bogues mineurs sur certains processeurs de 2008, alors que d’autres ont dit n’avoir pas constaté de bogue avec des processeurs de générations plus récentes. Il est donc théoriquement possible de se passer de ce microcode, mais il est généralement admis que les microcodes embarqués dans les processeurs au sortir de l’usine sont de plus en plus bogués au fil des générations, et que la probabilité d’être dépendant d’une mise à jour de microcode est de plus en plus grande. Notons que les microcodes Intel sont signés avec une signature RSA 2048 bits, et ne seront donc probablement jamais libérés. Notons aussi que ce microcode effectue des tâches extrêmement basiques (décomposer des instructions en sous‐instructions plus simples à traiter par le matériel), et la probabilité qu’il contienne des fonctionnalités pouvant compromettre le système est extrêmement faible (elles seraient trop difficiles à mettre en place à ce niveau).
le ME (Management Engine) : la bête noire des développeurs de Coreboot. C’est un très gros micrologiciel, pouvant aller jusqu’à 5 Mio, s’exécutant sur un processeur ARC situé dans le PCH (Platform Controller Hub, équivalent moderne du north bridge) des jeux de puces Intel et séparé du processeur principal. Ce micrologiciel est constamment en fonctionnement lorsque l’ordinateur est allumé. Le but annoncé de ce micrologiciel est d’implémenter la technologie AMT (Intel Active Management Technology), qui permet notamment de retrouver son ordinateur lorsqu’on se l’est fait voler, en permettant d’effectuer toute sorte d’opérations dessus, à distance, indépendamment du système d’exploitation, pour peu que celui‐ci soit branché au réseau au moins une fois. On peut, par exemple, éteindre, redémarrer ou réveiller la machine à distance, capturer les paquets du réseau, lire les fichiers ouverts, accéder aux programmes en cours d’exécution, faire des captures d’écran, enregistrer la frappe au clavier, utiliser la webcam et le micro, rendre l’ordinateur définitivement inopérant, etc. Une liste un peu plus étoffée des fonctionnalités et des applications possibles est disponible. Pour ce faire, le ME doit bien évidemment avoir un accès aux adaptateurs réseau, à la gestion de l’énergie, au contenu de la mémoire vive en lecture et en écriture, et ce sans que le système d’exploitation hôte ne puisse le savoir. C’est grosso‐modo un petit système d’exploitation, totalement sous le contrôle d’Intel, tournant à côté du système d’exploitation principal, de façon totalement transparente. Le ME serait aussi le siège de la technologie Intel Boot Guard introduite plus récemment, dont le but est d’empêcher toute modification des micrologiciels embarqués en vérifiant leur signature à l’amorçage, rendant impossible le remplacement de l’UEFI par un micrologiciel non approuvé par Intel. Boot Guard n’est apparemment pas activé par défaut sur les plates‐formes actuelles. Les emmerdes volant toujours en escadrille, c’est aussi dans le ME qu’on trouve la technologie PAVP (Protected Audio‐Video Path), un équivalent de HDCP, mais plus robuste (en gros les flux vidéo et audio déchiffrés sont transmis directement au processeur graphique sans que le processeur central n’ait connaissance de quoi que ce soit, rendant impuissant les applications de capture audio‐vidéo). Ce petit bout de BIOS génère tant d’inquiétudes sur le plan des libertés numériques que certains développeurs lui ont créé un site dédié. Bien évidemment, ce micrologiciel est signé depuis la génération Penryn (≈ 2008) et nécessaire au fonctionnement du système depuis les ordinateurs de la génération Nehalem (fin 2008 à début 2009), pour lesquels le système se gèle 30 minutes après l’amorçage si le ME n’est pas présent. Sur les générations post‐Nehalem (Sandy Bridge et postérieures), l’ordinateur ne démarre simplement pas. Sur les plates‐formes i945 (Yonah et Merom, ≈ 2006), il n’y avait pas de PCH, le ME était donc présent dans le contrôleur Ethernet. Il était non signé, optionnel, plus petit (1,5 Mio) et ne contenait probablement que des données d’initialisation (le matériel n’étant pas capable de charger du code exécutable depuis le contrôleur). Sur les plates‐formes Penryn, les développeurs de Libreboot ont pu désactiver le chargement du ME, bien que celui‐ci soit signé, via une bidouille du descripteur de fichier du BIOS. Bien que certains passionnés essayent cependant d’en faire une rétro‐ingénierie partielle afin de connaître son fonctionnement, il est pratiquement sûr que le ME ne sera jamais libéré.
le MRC (Memory Reference Code) : c’est un micrologiciel présent dans les UEFI des plates‐formes Intel à partir de la génération Sandy Bridge (≈ 2011). Il tourne sur le processeur principal et permet d’initialiser la mémoire vive et l’USB. Apparemment, ce blob est non signé et pourrait potentiellement être remplacé un jour par rétro‐ingénierie.
Sur les plates‐formes AMD :
NIC firmware : c’est le micrologiciel de la puce Ethernet (Network Interface Controller) embarqué, équivalent du GBE chez Intel. Apparemment ce blob ne concernerait que les puces Broadcom intégrés, relativement rares. Il pourrait en théorie être remplacé assez facilement.
VBIOS (VGA BIOS / VGA Option ROM) : mêmes caractéristiques que sur les plates‐formes Intel. Notons que celui‐ci n’a pas été libéré sur les Thinkpad dotés d’un processeur graphique AMD : les modèles T60p et assimilés présentent donc des soucis d’initialisation vidéo au niveau du BIOS à l’heure actuelle. Notons aussi qu’AMD ne fabriquant pas que des processeurs graphiques embarqués, le VBIOS d’AMD est également présent dans des cartes graphiques. Une tentative de libération de ceux‐ci par rétro‐ingénierie avait d’ailleurs été tentée il y a quelques années dans le projet open radeonbios, mais celui‐ci n’était pas allé très loin (juste une initialisation du port VGA et de la 2D sur certaines vieilles cartes).
le microcode processeur : mêmes fonctions et mêmes caractéristiques que celui d’Intel. Dans Debian, on a pu voir arriver le paquet amd-microcode quelques mois après le paquet intel-microcode. Là aussi, des utilisateurs rapportent des bogues nécessitant d’appliquer les mises à jour du microcode sur des plates‐formes récentes. Comme pour Intel, il est signé en RSA 2048 bits et ne sera probablement jamais libéré.
AMD IMC (Integrated Microcontroller) : il s’agit d’une sorte d’EC (Embedded Controller) présent dans le south bridge des cartes mères AMD depuis au moins 2007 (et peut‐être même bien avant). Pour rappel, l’EC est un petit micrologiciel présent sur les cartes mères (mais généralement en‐dehors du BIOS, sur une puce dédiée) et prenant en charge les fonctions basiques de gestion de l’énergie. Il est possible de s’en passer au moins sur certaines cartes (qui utilisent l’EC classique à la place). Il est possible que l’IMC soit libéré par rétro‐ingénierie dans un futur proche.
AMD XHCI (eXtensible Host Controller Interface) : c’est le micrologiciel du contrôleur USB 3.0. Il est apparu lorsque AMD a commencé à implémenter l’USB 3.0 dans ses cartes mères (probablement au moment de la sortie de la plate‐forme Bulldozer / Fam15h et du jeu de puces AM3+, donc aux alentours de 2011). Il est possible de s’en passer, mais alors il faut accepter de perdre les fonctionnalités USB 3.0 de la carte mère. Non signé, il est théoriquement possible de le remplacer par rétro‐ingénierie.
SMU (System Management Unit) : le SMU se présente comme un EC subsidiaire présent dans le north bridge des cartes de la génération Fam15h et postérieures, prenant en charge la gestion de l’énergie des composants PCI et notamment des processeurs graphiques, et gérant peut‐être d’autres choses essentielles au système (avec un accès au moins partiel à la mémoire vive). Il implémente notamment un petit processeur tournant par‐dessus le processeur principal, les fonctions du SMU étant exécutées sur ce processeur secondaire. Le SMU est un blob signé, mais une faille de sécurité y a été découverte en 2014, permettant d’injecter du code dans une petite section non concernée par la signature. AMD a corrigé la faille dans une mise à jour du SMU, mais la clé de chiffrement (symétrique, HMAC) reste la même. Il a ensuite été découvert qu’on pouvait récupérer la clé HMAC du SMU sur des plates‐formes non mises à jour via cette faille, ce qui a été fait et il est désormais théoriquement possible de libérer le SMU sur les plates‐formes AMD actuelles. Il est fort probable que la clé de chiffrement soit changée sur les futures plates‐formes.
Note : cette architecture à base de processeurs virtuels tournant sur le processeur principal est en fait une architecture assez courante des blobs du BIOS (c’est apparemment aussi comme ça que sont implémentés l’IMC, le XHCI, le ME d’Intel et le PSP d’AMD) et le hacker Rudolf Marek qui a présenté une analyse du micrologiciel SMU au 31e Chaos Communication Congress en 2014 a proposé de les baptiser Matroshka processors (processeurs poupées russes).
- PSP (Platform Security Processor) : l’équivalent du Management Engine, mais côté AMD. Il est apparu dans les cartes AMD Fam15h de 4e génération, correspondant à la plate‐forme Excavator / Carrizo, sorties en 2015. Comme le ME, il implémente son propre microprocesseur (un Cortex A8) et fait tourner un petit système d’exploitation par‐dessus, indépendamment du système hôte et de façon totalement transparente. On n’a pour l’instant pas beaucoup d’informations précises sur ce qu’il fait : probablement des choses liées à la gestion numérique des droits (DRM), à l’image de PAVP chez Intel et à la sécurité (TPM, accélération cryptographique, générateur de nombres aléatoires). Les fonctionnalités du ME non liées à la sécurité seraient absentes du PSP pour le moment, mais il n’est pas exclu qu’elles y soient intégrées un jour. Apparemment, il aurait accès à la mémoire vive, comme le ME. La carte mère ne démarre pas si le PSP est absent. Le PSP est un peu plus documenté que le ME (on connaît l’algorithme de compression) et AMD fournit au projet coreboot un PSP « minimaliste » qui ne ferait qu’initialiser les composants de la carte mère au démarrage. On suppose que les futures versions du PSP intègreront des fonctionnalités actuellement gérées par d’autres parties du BIOS ou de l’EFI (comme initialiser la mémoire).
Pour résumer : si vous avez un ordinateur Intel acheté entre 2005 et 2008, vous ferez face à un GBE, un VBIOS, un petit ME « passif » et non signé, et peut‐être un microcode processeur. Pour un ordinateur post‐2008, vous aurez un GBE, un VBIOS, un ME signé désactivable et peut‐être un microcode. Après 2009, vous aurez un GBE, un VBIOS, un ME signé non désactivable et peut‐être un microcode. À partir de 2011, vous devrez faire face un GBE, un VBIOS, un ME signé nécessaire à l’amorçage, un MRC et très probablement un microcode. Si vous avez un ordinateur AMD acheté avant 2007, vous ferez face à un VBIOS et peut‐être un microcode et un microcode pour votre puce réseau. Après 2007, vous aurez un VBIOS, un IMC, peut‐être un microcode et un microcode pour votre puce réseau. À partir de 2011, vous aurez un VBIOS, un IMC, un XHCI, un SMU signé et peut‐être un microcode et un microcode pour votre puce réseau. Après 2015, vous devrez faire face à un VBIOS, un IMC, un XHCI, un SMU signé, un PSP signé, peut‐être microcode pour votre puce réseau et probablement un microcode.
Au fil des années et des générations de processeurs, on observe bien une tendance : le nombre de blobs non libres dans nos cartes mères augmente, leur taille augmente, la probabilité qu’ils soient nécessaires au fonctionnement du système augmente également, de même que la probabilité qu’ils soient signés et donc irremplaçables et, enfin, le nombre de choses qu’ils sont capables de faire sur le système s’étend également. Les ordinateurs Intel qui donnent à l’utilisateur un degré de liberté raisonnable et validés RYF par la FSF datent, au mieux, de 2008. On constate aussi qu’AMD finit toujours plus ou moins par faire les mêmes bêtises qu’Intel, avec quelques années de retard. Le comportement d’AMD vis‐à‐vis d’Intel fait un peu penser à celui du Parlement européen vis-à-vis du Sénat américain sur les lois liées au numérique : il suffit que le second décide de faire une connerie pour que le premier lui emboîte le pas quelque temps après.
La situation de la liberté de l’utilisateur sur les stations de travail modernes n’est donc guère radieuse et on a de bonnes raisons de penser qu’elle ira de mal en pis dans les années qui viennent.
État du marché
Se pose alors logiquement la question suivante : comment en est‐on arrivé là ?
Difficile de répondre objectivement à cette question sans avoir une connaissance exhaustive de l’histoire des ordinateurs personnels au cours du dernier quart de siècle, mais on peut déjà avoir des éléments de réponse en observant le marché actuel.
D’abord, il faut savoir que lorsqu’on parle des ordinateurs personnels, on parle presque exclusivement de plates‐formes x86. x86 est un jeu d’instructions (ISA : Instruction Set Architecture) mis au point par Intel à la fin des années 70, qui est peu à peu devenu le standard de fait dans les ordinateurs personnels, les serveurs et même plus récemment les supercalculateurs. Cette architecture est presque totalement contrôlée par Intel : tous les développements faits par Intel sur l’architecture x86 depuis la sortie de l’Intel 80486 en 1989 sont la propriété exclusive du fabricant. L’autre gros fabricant de processeurs compatibles x86, AMD, fait figure d’exception puisqu’il a obtenu d’Intel une licence x86 sur les processeurs 8086 et 8088, en 1982, à une époque ou Intel en accordait à ses concurrents. Il a tout de même fallu une bataille juridique pour qu’AMD puisse, en 1995, continuer à faire concurrence à Intel en développant ses propres améliorations sur x86. Malgré cela, Intel garde un contrôle très fort sur le marché, avec une supériorité technologique reconnue (le rapport performances/consommation fait qu’Intel possède une quasi‐exclusivité sur le marché des portables) et une part dominante tournant autour de 80 %.
En théorie, le BIOS ou UEFI est indépendant du microprocesseur, car il est situé sur la carte‐mère et est développé par le fabricant de la carte. Cependant, la carte‐mère est conçue pour accueillir un processeur d’une certaine marque et d’une certaine génération, et doit donc disposer d’un emplacement (socket) et d’un jeu de puces (chipset) compatibles, dépendants du fabricant du processeur, qui est alors en mesure de dicter ses conditions au fabricant de la carte‐mère. Dans le cas d’Intel et AMD, ces conditions incluent l’intégration obligatoire au sein du BIOS d’un paquetage logiciel contenant les micrologiciels décrits plus haut. Ce paquetage s’appelle FSP dans le cas d’Intel (Firmware Support Package) et AGESA dans le cas d’AMD (AMD Generic Encapsulated Software Architecture).
Note : Au moment où j’écris ces lignes, AMD essayerait de sous‐licencier sa licence x86 à un constructeur chinois, ce qui laisserait a priori espérer qu’un nouveau concurrent puisse apparaître sur le marché du x86 dans les prochaines années. Cependant, il n’y a pas grand chose à espérer de cette tentative : clarifier la situation ne serait‐ce que sur le plan juridique va prendre énormément de temps, il y a fort à parier qu’Intel ne laissera pas un nouveau concurrent émerger aussi facilement, que l’État américain mettra tout son poids dans la balance pour que la souveraineté américaine sur le marché des ordinateurs personnels et des serveurs ne soit pas mise à mal et, même si AMD réussit, on ne sait pas du tout sous quelles conditions cette licence sera vendue, ni si ce concurrent vendra des produits conçus dans l’intérêt de l’utilisateur (peut‐être qu’ils seront simplement limités au marché chinois et assortis d’un paquetage logiciel PRC‐compliant).
Il existe d’autres architectures que x86 utilisées dans les ordinateurs personnels. Richard Stallman est connu pour avoir longtemps utilisé un netbook Lemote Yeeloong dépourvu de BIOS, afin de ne pas dépendre de logiciels non libres. Cet ordinateur utilisait un processeur Loongson utilisant l’architecture MIPS, aux performances médiocres, mais visiblement assez puissant pour permettre à Richard d’y faire tourner GNU/Linux‐libre et sans doute EMACS. Certains constructeurs commencent à vendre des ordinateurs portables utilisant l’architecture ARM et donc non soumis aux conditions d’Intel et d’AMD. Certains Google Chromebook notamment utilisent un processeur ARM et sont vendus avec un BIOS coreboot au moins partiellement libre. Bien que nettement plus puissants que les ordinateurs MIPS, les ordinateurs ARM restent significativement limités au niveau du matériel et en termes de puissance, comparativement aux ordinateurs x86 de génération équivalente.
On le voit, la situation en termes de concurrence sur le marché des ordinateurs personnels est, elle aussi, très mauvaise. Le marché est soumis à un quasi‐monopole d’Intel ou un oligopole Intel‐AMD, suivant comment on voit les choses. Il n’y a grosso‐modo pas de concurrence et la situation sur x86 est complètement bloquée. Cette situation génère beaucoup d’inquiétude, tant en termes de conséquences sur les droits du consommateur qu’en termes d’évolution du marché.
Proposition no 1 : le matériel libre
Un nouveau regard
Le concept de matériel libre est difficile à définir. Théoriquement, il s’agit d’appliquer au matériel électronique et, par extension, aux autres objets physiques, les quatre libertés fondamentales du logiciel libre. Aujourd’hui, ce concept se heurte encore aux limites de notre technologie : il n’existe pas actuellement de moyen abordable, rapide et peu coûteux de copier du matériel électronique et donc d’assurer la liberté no 2. Pour cette raison, Richard Stallman et la FSF ne reconnaissent pas le concept de matériel libre et ont longtemps refusé de donner une analyse détaillée de la question. Pourtant, le matériel libre constitue pour certains libristes l’ultime espoir face à l’écueil principal du logiciel libre : la compatibilité avec le matériel. En effet, si le matériel est libre, on sait comment il fonctionne et on peut donc facilement écrire des logiciels pouvant l’exploiter.
Les années 2000 et 2010 ont vu se développer de nombreux projets de matériel électronique pouvant s’apparenter, du moins en partie, au concept de matériel libre et regroupés sous la bannière de l’open hardware.
Le terme open hardware n’a lui non plus pas de définition précise. Selon les projets, il désigne tantôt du matériel libre, tantôt des circuits imprimés (PCB) libres sur lesquels se greffent des composants pas nécessairement libres. À l’heure actuelle, la très vaste majorité des projets dits open hardware appartiennent à la deuxième catégorie. Ce sont des PCB, dont les schémas sont publiés sous licence libre, reliant entre eux des composants (microprocesseurs, contrôleurs, puces diverses) non libres. Pire encore, ces composants non libres ne sont pas nécessairement documentés et les projets pouvant se vanter de n’intégrer que du matériel parfaitement documenté se comptent sur les doigts d’une main.
En mars 2015, Richard Stallman a finalement publié un article détaillant ses réflexions sur le sujet et définissant les positions officielles de la FSF concernant le matériel libre. Dans cet article, il réaffirme son rejet du terme « open hardware » ainsi que son scepticisme quant à la possibilité factuelle d’exercer la liberté no 2. Mais il introduit également quelques points nouveaux dans son discours :
- on ne peut pas copier le matériel pour l’instant, mais on peut copier les fichiers qui le décrivent : il faut donc parler de « schémas de conception libres » (Free Hardware Designs) ;
- les schémas de conception libre pourraient un jour devenir le seul moyen pour un utilisateur de faire son informatique librement ;
- pour l’instant, il n’est pas nécessaire de rejeter le matériel non libre, mais un jour, cela le sera peut‐être. En attendant, les schémas de conception libres doivent être soutenus et encouragés ;
- il existe différents niveaux de conception pour le matériel. Les circuits électroniques des circuits imprimés sont un premier niveau, les circuits des puces embarquées sur ces circuits imprimés sont un second niveau, les cellules internes d’un FPGA en sont un troisième, etc. Il est probable qu’un jour on ait à libérer tout le matériel pour pouvoir faire son informatique librement, mais dans l’état où progressent les choses, nous devrons probablement libérer le matériel un niveau après l’autre ;
- avec des schémas de conception libres, on reste dépendant du fabriquant du matériel. Pour que la liberté sur le matériel soit effective, il faudra une démocratisation des moyens de production correspondant à ce niveau de conception de matériel.
Cet article a également fait l’objet d’un journal de whygee sur LinuxFr.org, introduisant un site récapitulatif de certains projets de schémas de conception libres. L’occasion de jeter un œil sur les efforts entrepris dans le domaine jusqu’à maintenant.
La situation actuelle
On l’a bien vu et les contributeurs du projet Purism s’en sont mordus les doigts : dans l’état actuel des choses, il n’est pas possible de faire un ordinateur dépourvu de logiciels non libres basé sur x86.
Le projet Purism, décrit dans une dépêche de 2015, dont les fondateurs ont tenté de faire croire à qui voulait les entendre qu’ils fabriqueraient un ordinateur portable doté d’un processeur Intel x86 dernière génération dépourvu de blobs signés et autres micrologiciels non libres, a bien évidemment échoué, pour toutes les raisons décrites plus haut.
Malgré tout, il existe quantité de projets de schémas de matériel libres sérieux. La plupart sont des circuits imprimés basés sur des processeurs ARM ou MIPS, intégrant quelques contrôleurs (Ethernet, USB…) documentés et une ou deux puces non documentées ne présentant pas ou peu d’alternatives, comme un processeur graphique et parfois une puce Wi‐Fi. La situation déplorable des processeurs graphiques embarqués sur ARM a été décrite dans une dépêche en 2013 et n’a pas vraiment changé depuis. Quelques projets cependant essayent ou ont essayé de rester aussi loin que possible du matériel nécessitant des logiciels non libres, comme le défunt Ben Nanonote, basé sur un processeur MIPS, et le Novena Laptop, utilisant un processeur ARM et un processeur graphique Vivante dont le micrologiciel non libre peut être désactivé. Ceux‐ci sont, bien évidemment, bien en‐dessous des Thinkpad x86 certifiés RYF par la FSF en termes de performances.
À un niveau de conception plus haut, on a les projets de microprocesseurs. Les projets cités par whygee dans son journal sont F-CPU et YASEP, mais il en existe d’autres, notamment le fameux projet OpenCores (qui semble maintenant être remplacé par LibreCores ), dont le sous‐projet le plus avancé semble être OpenRISC, un microprocesseur basé sur l’architecture libre RISC-V. Les communautés de concepteurs de schémas de microprocesseurs libres semblent s’orienter dans deux principales directions, les FPGA, qui offriraient de grandes possibilités techniques, mais auraient des performances encore médiocres, et l’architecture RISC-V. Dans les deux cas, la communauté se heurte au problème de la dépendance au fabricant évoqué précédemment. Il est bien beau de concevoir des microprocesseurs, encore faut‐il trouver quelqu’un prêt à les fabriquer et, qui plus est, à les fabriquer en respectant les spécifications. De ce côté, la situation est au point mort depuis toujours, même si un mince espoir commence à affleurer.
La question « Comment faire fonctionner aujourd’hui un système totalement libre sur une machine répondant aux exigences d’une station de travail moderne, notamment en termes de performances ? » reste en suspend.
Une solution à court terme
Situation de différentes architectures
Timothy Pearson (tpearson) est un important contributeur du projet coreboot. Par le biais de son entreprise Raptor Engineering, il a aidé à porter coreboot sur des cartes‐mères AMD pour serveurs et a développé un logiciel d’automatisation de tests de la version de développement de coreboot sur ces cibles.
En avril 2016, il publie sur la liste de diffusion de la FSFE un courriel intitulé Uncorrectable freedom and security issues on x86 platforms, dans lequel il détaille les problèmes de liberté des plates‐formes x86 rencontrés par les développeurs de coreboot et de Libreboot et donne un aperçu de la situation des différentes architectures non x86 comme alternatives possibles pour des stations de travail utilisant un système libre, dans un futur immédiat. Les architectures possibles sont :
ARM : l’architecture ARM est la propriété d’ARM Holdings, une compagnie britannique qui conçoit des microprocesseurs et en vend des licences d’exploitation, mais n’en produit pas. Actuellement, plus d’une quinzaine de fabricants disposeraient d’une licence ARM, ce qui témoigne d’un marché relativement ouvert. Le nombre de projets open hardware utilisant des processeurs ARM laisse penser que ces processeurs sont ensuite vendus sous des termes relativement libéraux. Les processeurs ARM courants sont généralement peu puissants, avec une puissance comparable aux x86 bas de gamme, très peu chers, presque imbattables en termes d’efficacité énergétique et atrophiés de beaucoup des fonctionnalités importantes de x86 (support d’hyperviseur, ECC, SATA, PCIe…). Pour cette dernière raison les ARM courants sont inenvisageables pour une station de travail digne de ce nom. Il existe cependant des processeurs ARM haut de gamme qui ont une puissance comparable au milieu de gamme x86 et disposent des fonctionnalités de ces derniers, mais qui sont très chers.
MIPS : l’archiecture MIPS est développée par MIPS Technologies, qui comme ARM vendait des licences d’exploitation à différents fabricants. MIPS Technologies appartient depuis 2013 à Imagination Technologies (qui n’est pas vraiment l’ami du logiciel libre), mais quelques compagnies continuent à produire des processeurs MIPS. La plus connue est sûrement le chinois Lemote. Les processeurs MIPS sont généralement peu chers, bien en dessous des ARM en termes de puissance et d’une efficacité énergétique légèrement supérieure. Théoriquement suffisants pour faire fonctionner un netbook de bas de gamme, ils sont surtout utilisés dans l’embarqué et ne sont pas vraiment envisageables pour une station de travail libre.
POWER : l’architecture POWER est développée par IBM, qui vend des licences d’exploitation à quelques fabricants. En 2013, IBM fonde l’OpenPOWER Foundation avec quelques autres acteurs et propose ses nouveaux processeurs milieu et bas de gamme POWER8 sous des termes très libéraux, allant même jusqu’à fournir un paquetage de micrologiciels libres pour faire fonctionner les cartes embarquant ces processeurs. Les processeurs POWER8 haut de gamme ne sont pas concernés, mais ceux‐ci sont avant tout destinés au marché des serveurs à haute fiabilité et ne sont pas pertinents pour un ordinateur personnel. Les POWER8 de milieu et bas de gamme, en revanche, offrent des performances équivalentes aux processeurs de dernière génération x86, offrent toutes les fonctionnalités qu’on peut attendre d’une station de travail, consomment beaucoup d’énergie et sont encore très chers.
RISC-V : l’architecture RISC-V (risc-five) est développée par l’Université de Berkeley et est librement disponible sous licence BSD. Personne ne fabrique de processeurs RISC-V actuellement. Les processeurs RISC-V sont théoriquement peu puissants et peu efficaces énergétiquement. Selon les sources, ils pourraient être légèrement inférieurs ou légèrement supérieurs aux actuels MIPS en termes de performances. Cette architecture n’est pour l’instant pas envisageable pour une station de travail libre, mais comme elle est entièrement libre, elle pourrait devenir une solution pour le logiciel libre à très long terme.
SPARC : l’architecture SPARC est développée par Sun Microsystems, qui appartient depuis 2010 à Oracle (pas vraiment ami du Libre lui non plus). L’architecture du processeur SPARC T2 a été libérée sous licence GPL en 2007 et a vu naître quelques modifications libres, mais n’a pas vraiment évolué depuis et n’est pour l’instant pas envisageable pour une station de travail libre (elle n’est même pas mentionnée dans le courriel de tpearson).
En résumé, les seules architectures constituant pour l’instant de bons candidats pour une alternative à x86 à court et moyen termes sont les haut de gamme ARM et les bas de gamme POWER8.
ARM
Regardons un peu plus attentivement les opportunités du côté des processeurs ARM haut de gamme. Ceux‐ci, on l’a vu, possèdent toutes les fonctionnalités qu’on peut attendre d’un processeur équipant un ordinateur personnel moderne (PCIe, ECC, SATA, USB 3, prise en charge d’hyperviseur, etc.). Parmi les acteurs développant des plates‐formes ARM haut de gamme, on trouve NXP Semiconductors, surtout connu sous son ancien nom : Freescale. Leur LS2085A NPU (Network Processing Unit) est probablement ce qui se rapproche le plus d’une station de travail moderne dans le monde ARM haut de gamme.
Le NXP LS2085A est une carte mère équipée de 8 cœurs ARM 64 bits Cortex-A57, avec emplacements de mémoire vive DDR 4, connecteurs PCIe, SATA 3, USB 3, Gigabit Ethernet, etc. La carte utilise un format inhabituel, peut‐être BTX et est apparemment pensée pour équiper des boîtiers horizontaux rackables.
Côté inconvénients, les processeurs n’ont pas de cache de niveau 3, la carte embarque au moins un micrologiciel non libre dont l’élimination désactive les ports Ethernet intégrés (mais il est possible d’utiliser une carte réseau PCI) et, bien évidemment, elle sera très chère (apparemment, elle n’est pas encore disponible à la vente au moment où j’écris ces lignes).
POWER
Jetons maintenant un œil du côté des opportunités concernant les processeurs POWER8 milieu et bas de gamme. Les processeurs POWER8 forment une gamme de processeurs basée sur la spécification Power ISA v2.07 d’IBM. Comme les ARM haut de gamme, ils proposent toutes les fonctionnalités intéressantes qu’on retrouve chez les processeurs x86 modernes. Les POWER8 bas de gamme actuels affichent des performances supérieures aux ARM haut de gamme actuels.
Contrairement aux x86, qui sont little‐endian (petit‐outistes), les processeurs POWER sont historiquement big‐endian (gros‐boutistes), mais les générations actuelles comme POWER8 sont bi‐endian (bi‐boutistes).
Les processeurs POWER8 mettent l’accent sur la bande passante : contrairement à l’ARM A57 ils possèdent des caches de niveau 3 et même des caches de niveau 4 pour certains modèles, offrent une importante bande passante pour les entrées‐sorties et la mémoire. Ils proposent une interface additionnelle à PCIe appelée CAPI (Coherent Accelerator Processor Interface) supposée plus avantageuse en termes de latence.
IBM fournit, via l’OpenPOWER Foundation, des micrologiciels libres pour faire fonctionner les cartes‐mères à base de POWER8. Contrairement aux ordinateurs sous ARM, les micrologiciels relatifs aux contrôleurs de puce réseau et processeur graphique intégrés sont libres, la seule exception étant le microcode du processeur central. Cependant ce microcode est très différent de celui présent dans les processeurs d’Intel et d’AMD : il fait beaucoup moins de choses, effectue des tâches bien plus basiques, est stocké sur un module du processeur et n’est pas chargé depuis le système d’exploitation. Il pourrait même être considéré comme acceptable par la FSF. IBM ne publie pas le code pour des raisons techniques, mais prévoit de résoudre ces problèmes et de libérer le microcode processeur de la prochaine génération de microprocesseurs (POWER9).
Bien évidemment, aucun des binaires nécessaires au fonctionnement de la carte‐mère n’est signé. Il existe cependant un mécanisme de signature dans les plates‐formes POWER8, mais celui‐ci est totalement sous le contrôle de l’utilisateur : l’utilisateur peut ajouter sa propre clé, signer ses binaires et faire en sorte que l’ordinateur vérifie les signatures au boot. C’est un système de sécurité similaire à celui présent dans les Chromebook ARM de Google.
Du côté des inconvénients, rappelons que les processeurs POWER8 bas et milieu de gamme sont chers et qu’ils ont une consommation entre 130 et 190 W, ce qui exclut toute possibilité de les utiliser pour remplacer les x86 dans des ordinateurs portables. Cependant, ils restent de bons candidats pour des stations de travail fixes.
Malheureusement, les constructeurs de machines POWER ne proposent en général pas de produits pouvant faire office d’ordinateur personnel pour libristes : les cartes mères haut de gamme sont excessivement chères, les cartes mères bas de gamme n’utilisent pas les micrologiciels OpenPOWER, mais de vieux micrologiciels non libres et généralement leur format les rend inadaptées aux stations de travail.
C’est pourquoi Raptor Engineering a décidé de produire une carte‐mère ATX bas de gamme basée sur POWER8, appelée Talos. Celle‐ci aurait un socket POWER8 pouvant accueillir un processeur 130 W ou 190 W au choix et serait dotée d’une connectique impressionnante : 8 slots de RAM DDR3 (jusqu’à 256 Gio), 8 connecteurs SATA 3, 1 slot PCI, 4 emplacements PCIe 8x, 2 emplacements CAPI/PCIe 16x, 1 emplacement mPCIe, 2 connecteurs USB 3.0 internes, 4 ports USB 3.0 externes, 2 ports eSATA externes, 1 port HDMI, 2 connecteurs RS-232 externes, 1 connecteur GPIO, 2 ports Gigabit Ethernet. La carte‐mère devrait également intégrer des interrupteurs physiques pour activer et désactiver la puce réseau intégrée et l’écriture des puces hébergeant les micrologiciels du BIOS et les clés de sécurité. Le processeur graphique intégré sera un ASpeed AST2400 BMC, un simple contrôleur vidéo 2D sans accélération graphique. Pour tout usage allant au‐delà de la simple bureautique (jeux, rendu 3D, etc.), Raptor Engineering recommande une carte graphique, par exemple une NVIDIA GK104 de la génération Kepler qui, couplée avec le pilote nouveau, constitue une des dernières cartes de NVIDIA pouvant fonctionner sans binaire signé. Ainsi, il serait possible de constituer un ordinateur personnel capable de faire tourner des jeux comme Xonotic, sur un système totalement libre (si on exclut le microcode processeur et sans doute aussi le micrologiciel du disque de stockage).
Actuellement, la carte mère Talos est en développement et Raptor Engineering essaie d’évaluer la demande pour ce produit. Pour un prix attendu d’environ 3700 $, Raptor Engineering proposera la carte‐mère Talos, un processeur POWER8 octocœur de 130 W, et la quasi‐totalité des schémas des circuits de la carte‐mère. Ces derniers ne seront pas sous licence libre.
Il est probable que seuls les plus riches des libristes poilus achèteront une carte mère POWER8 Talos, mais il est aussi probable que cette initiative amorce l’émergence d’un nouveau marché de niche dans le monde des processeurs POWER et fasse naître un nouvel espoir chez ceux qui voudraient utiliser une station de travail moderne, puissante et ouverte, pour programmer, travailler, créer, jouer librement, ou tout simplement faire leur informatique loin de la surveillance des autres, au cours des 5 à 10 prochaines années.
L’invasion de micrologiciels intelligents, de microcodes de plus en plus évolués, voire de micro‐systèmes en dessous des systèmes d’exploitation sur les matériels modernes, suit l’évolution des capacités de la moindre des puces. Cela force aussi à remettre en perspective nos définitions de micrologiciels et à considérer beaucoup d’entre eux comme du logiciel devant être libéré.
Complément : même si POWER8 semble être le meilleur candidat pour une station de travail fixe, il fait peu de doute qu’on devra lui préférer ARM sur les ordinateurs portables. Ceux qui suivent le blog de la FSF ou la lettre d’information de ThinkPenguin ont été notifiés de l’existence d’un nouveau projet : le dispositif EOMA68 de Rhombus Tech. Je n’ai pas regardé en détail, mais apparemment ce serait une carte‐mère à base d’ARM embarquée dans un boîtier, qui pourrait ensuite être couplé à d’autres éléments pour former soit un ordinateur fixe, soit un portable, soit un routeur, etc., au choix de l’utilisateur. Je n’ai pas regardé ce projet très en détail et j’ai quelques doutes sur les possibilités techniques de faire un truc puissant et moderne avec un tel objectif de modularité, mais le fait que le projet soit déjà bien avancé et que la certification RYF fasse partie des objectifs mérite qu’on y jette un œil.
Aller plus loin
- Journal à l’origine de la dépêche (445 clics)
- Explications de la situation Intel chez Libreboot (210 clics)
# Mise en page
Posté par esdeem . Évalué à 4.
N'y a-t-il pas un soucis de mise en page ?
Parce que les longs passages en citation avec des puces ou le bloc de code, ça passe vraiment pas.
Sinon, merci à eingousef pour son journal.
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: Mise en page
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
Corrigé, merci. Il y a un souci de rendu entre la vision en rédaction/modération et le rendu final apparemment.
# Manger sa propre nourriture
Posté par Zenitram (site web personnel) . Évalué à -4.
Si la personne qui râle sur le non libre pour les autres fait du non libre quand c'est lui qui fait, ça casse quand même pas mal sa "pub".
Sur un système avec des logiciels totalement libres, aucun matériel (y compris celui fait par le vendeur) ne semblant être libre, ou est-ce que j'ai loupé un épisode?
Perso j'ai du mal à faire la différence entre "matériel" et "logiciel" (c'est une séparation arbitraire sur ce qu'on fait en soft ou en hard, pour des questions souvent de coût), donc que mon BIOS soit libre alors que ma carte-mère ne l'est pas me fait "pshit" (si il y a une back-door, elle sera dans le matériel de toutes façons).
Question : en quoi pour vous ce genre de projet, avec une petite avancée dans du micro-code sans avancées dans la matériel, est-il une avancée du libre qui mérite 3700$/unité?
[^] # Re: Manger sa propre nourriture
Posté par rewind (Mastodon) . Évalué à -4.
… dit le gars qui développe un soft libre sur un OS non-libre (alors que là, pour le coup, il y a le choix).
[^] # Re: Manger sa propre nourriture
Posté par Chuck #1 . Évalué à 10.
Je rejoins Zenitram sur la distinction purement arbitraire entre matériel et logiciel. Un ami qui travaille dans une entreprise qui conçoit des processeurs m'a expliqué que l'électronique est entièrement générée par un compilateur. La conception en elle-même consiste à écrire du code qui ressemble à du code système.
Ainsi, dans le cas de processeurs ARM, on peut acheter soit une licence pour le jeux d'instructions (ISA ARM), soit une licence pour une implémentation qui est fournie sous forme compilée. Il est alors possible d'intégrer ce "binaire" au sein de sa propre puce en ajoutant ses propres composants autour.
Il est ainsi tout à fait possible de coder des fonctionnalités en dur dans les processeurs. De ce que j'ai compris, le nombre de lignes de code très important et les cycles de développement très courts font qu'il y a quantité de bugs dans le "matériel". Le firmware/micro-code est un moyen de corriger ces bugs, soit en le contournant, soit en le masquant.
La différence entre code logiciel et code matériel est donc purement arbitraire.
Cette signature est publiée sous licence WTFPL
[^] # Re: Manger sa propre nourriture
Posté par Renault (site web personnel) . Évalué à 9.
Tout à fait, le matériel, du moins les puces logiques, sont programmés en VHDL ou Verilog pour l'essentiel. Car d'un point de vue mathématiques il y a stricte équivalence entre un logiciel ou du matériel (numérique du moins).
La question de savoir ce qui est mis en matériel ou logiciels vient :
Ceci est d'autant plus visible avec les FPGA qui sont du matériel configurables à souhait. Et tout ceci est obtenu via du VHDL également.
Seulement les FPGA ont des limitations :
Mais pour certaines fonctionnalités, le gain de performance est intéressant, et plus flexible que ce que propose le matériel (par exemple concernant le traitement vidéo).
[^] # Re: Manger sa propre nourriture
Posté par gringonz . Évalué à 10.
Je crois qu'il y a une confusion qui provient des termes utilisés. On ne fait pas un "programme" pour un FPGA. Le VHDL n'est pas un langage de programmation, mais un langage qui permet de decrire un circuit numérique. ensuite ce circuit numérique peut être un processeur sur lequel tournera un programme, mais pas forcément.
Les FPGA sont effectivement limités en performances (nombre de portes) et ca n'a rien à voir avec la complexité du programme qu'on peut ensuite faire tourner dessus. Avec un FPGA on sera toujours un train de retard par rapport à un "vrai" processeur, qui lui est fait sur mesure.
Pour faire un processeur, il faut le concevoir, on peut toujours imaginer
que ca soit libre, qu'un groupe de personne le fasse en VHDL…
Et la fabrication ?
Soit vous achetez une salle blanche et ca sera un (deux ?) milliard d'euros, soit vous demandez a un fondeur de vous le fabriquer, mais le ticket d'entrée ce chiffre en millions d'euros, donc faut être sur d'en vendre beaucoup.
C'est sans doute pour ca qu'il y a des os libres mais pas des processeurs libres.
Pour moi il y a donc un grosse différence en logiciel et matériel même si au départ il y a un code source. Pour produire un circuit, on ne compile pas le VHDL on fait une synthèse, ca n'a rien à voir avec compiler un code.
[^] # Re: Manger sa propre nourriture
Posté par Renault (site web personnel) . Évalué à 3.
Et alors ?
Cela restera un programme, un système qui aura des entrées et sorties, probablement numériques avec du traitement numérique dedans. Que ce soit exploité sous forme de jeu d'instruction d'un processeur ou d'un câblage en dur des portes logiques revient en soit au même.
Un algorithme reste un algorithme, un logiciel c'est de l'algorithmie et faire du FPGA ou de la conception de puces numériques également. Même si en général l'exécution de cet algorithme va différer niveau support, d'un point de vue mathématiques et logiques c'est la même chose.
Bah si, comme la surface et le nombre de portes sont limités, tu ne pourras pas tout faire avec en même temps sans changer on architecture interne (dans le sens câblage produit par la synthèse) contrairement à un processeur qui reste fixe et dont seulement les commandes logicielles changent.
Sinon quel serait l'intérêt des FPGAs avec une grande surface et de nombreuses portes ?
Ça c'est une autre question, essentielle mais qui n'a pas grand chose à voir avec ce dont je parle.
En soit si, tout est identique sauf le support final (l'un est purement matérielle, faut le construire, l'autre faut juste le copier sur un support numérique et le lancer). Cela change beaucoup de choses sur le coûts, la complexité du développement, etc. Mais d'un point de vue purement logique, mathématique ou algorithmie, le matériel et le logiciel sont strictement équivalents question fonctionnel. Tu ne peux pas concevoir un matériel que le logiciel ne peut pas reproduire et inversement.
[^] # Re: Manger sa propre nourriture
Posté par Antoine . Évalué à 7.
Le gros malentendu est sur le sens du mot "programmer".
Un ordinateur est une machine programmable… avec du logiciel. Le logiciel permet de programmer et reprogrammer à l'envi un ordinateur. Il n'y pas d'équivalent dans le monde matériel (changer à l'envi les fonctions matérielles d'une puce électronique) sauf dans le cas plutôt marginal des FPGA.
Dire que le matériel informatique est programmé sous prétexte que l'on écrit du code VHDL pour décrire son fonctionnement, c'est un peu comme dire qu'un pont à haubans est programmé sous prétexte que l'on écrit du code informatique pour simuler le comportement des structures du pont. À ce compte, toutes les productions de l'industrie moderne sont programmées et le mot ne veut plus rien dire.
[^] # Re: Manger sa propre nourriture
Posté par Maclag . Évalué à 3.
C'est quand même plus près que ça de la programmation:
Il y a des instructions de bas niveau bien sûr, mais aussi des bibliothèques pour abstraire les descriptions, et ça mouline comme un compilateur. Plus personne ne compte les transistors au niveau dév du processeur.
À une époque, il y avait même une tentative pour utiliser un langage proche du C et exploiter une base de dévs plus large. Si on peut faire un proco en C, c'est qu'o' n'est pas si loin de la programmation.
Par contre, c'est clairement différent d'un algo classique.
[^] # Re: Manger sa propre nourriture
Posté par flagos . Évalué à 6.
La tentative n'a pas été abandonnée, pas besoin d'en parler au passe, c'est clairement utilise aujourd'hui. Les outils de développement dit HLS (High Level Synthesis) permettent de décrire matériellement bon nombre de choses en C.
L'avantage, c'est pas vraiment une histoire de plus de développeurs C: decrire un bloc materiel que ce soit en C ou en VHDL, reste tres different de developper un programme informatique. Il faut clairement avoir conscience que ce que l'on va generer est un bout de silicium, pas un binaire, bref ce sont des compétences tres différentes de toutes manières.
Les vrais avantages sont clairement:
- un temps de simulation plus court, on peut tester fonctionnellement a la vitesse du C, impensable dans le cas du VHDL/Verilog
- une vraie non adhérence a la technologie visée. Il suffit de changer de techno, on regenere le code VHDL, et hop le portage est realise.
J'ai pas de stats pour affirmer combien de projets sont fait en HLS vs en VHDL, mais pour l'avoir pratique, c'est aujourd'hui utilise en milieu industriel sur des projets qui sortent avec du volume.
[^] # Re: Manger sa propre nourriture
Posté par gringonz . Évalué à 5.
Il existe un langage (ou plus exactement une surcouche à C++) qui s'appelle systemC, qui est normalisé et qui est dédié à la description de matériel. Mais à ma connaissance pas de synthèse efficace (c'est à dire passer du code source à des porte logique automatiquement).
[^] # Re: Manger sa propre nourriture
Posté par flagos . Évalué à 3.
Tout a fait.
On se sert du systemC pour modeliser les blocs fonctionnels. Cela permet d'avoir un bloc qui repond aux mêmes requêtes et aux memes transactions que le bloc final. C'est particulierement utile d'avoir un modele comme ca pour les tests ou pour developper un driver sans etre sur le systeme embarque. Malheureusement, le systemC ne permet pas d'etre synthetise.
Du coup, lorsqu'on designe le bloc, on passe plutot sur des outils HLS qui se basent sur du C et non du C++.
[^] # Re: Manger sa propre nourriture
Posté par Thomas Douillard . Évalué à 5.
La notion d'algorithme peut s'étendre assez facilement pour tout système physique. Genre on a une méthode systématique pour prendre la plus grande spaghetti en les mettant verticalement, posant sa main dessus et tout lacher.
Si tu considères la réalité comme une matrice et que le jeu d'instruction c'est les lois de la physique, tu "programmes" le réel tout comme tu programmes un simulateur de console - sauf que dans le simulateur de console, le jeu d'instruction ce n'est plus les lois de la physique, c'est le microprocesseur ou l'abstraction/VM que tu codes par dessus.
Théoriquement : on peut implémenter une machine de Turing (enfin presque) physiquement, donc une machine Turing-complète, ensuite tout se réduit à la notion de Turing-complétude.
[^] # Re: Manger sa propre nourriture
Posté par gringonz . Évalué à 4.
Ok alors si pour toi c'est pareil de ton point de vue, je le conçois très bien. Tu restera avec un processeur de génération n-1 (voire n-2) implémenté sur un FPGA récent, et tu aura un processeur libre mais dépassé, ou bien tu aura le code libre d'un processeur tip top, mais tu n'auras pas les moyens de le faire fabriquer, ce qui limite quand même à mon sens l'intéret du matériel libre, sauf besoin particulier ou tu accepte d'avoir un processeur dépassé.
[^] # Re: Manger sa propre nourriture
Posté par Thomas Douillard . Évalué à 2.
Ne pas se contenter d'évacuer la question des performances par le Théorème d'accélération linéaire, c'est sale /o\.
[^] # Re: Manger sa propre nourriture
Posté par claudex . Évalué à 10.
Oui et non, ton matériel, une fois que tu as la puce, il est fixe, tu ne peux pas le mettre à jour, contrairement au logiciel (et au firmware de ta puce). Cela implique qu’un malware peut se mettre dans le logiciel mais pas dans le matériel. De plus, il y a assez peu de chance d’avoir un logiciel espion1 dans le matériel, même s’il est gouvernemental, car il a besoin de paramètres qui changent régulièrement2
C’est exactement le principe de toutes les extensions MMX, SSE, NEON…
Voir, par exemple, la mémoire transactionnelle sur Intel Haswell désactivée via une mise à jour du microcode.
par contre, une backdoor… mais même pour ça, il peut être intéressant de changer les paramètres de contact ↩
par exemple, on peut pas se permettre d’avoir une adresse IP ou un domaine à contacter coder en dur dans la puce, sinon, une fois le point de contact découvert, il devient trivial de le bloquer via un firewall. ↩
« 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: Manger sa propre nourriture
Posté par octane . Évalué à 6.
Et pourtant dans les papiers de la NSA il y a pleins de hack de matériels: firmwares de disque durs, firmwares d'appliances réseaux etc..
Il existe aussi le computrace: c'est un firmware de BIOS qui va patcher ton OS à la volée et appeler au besoin une IP, ça sert dans le cas de vol d'ordinateurs.
Ensuite, tu n'as pas toujours besoin que ce soit la machine qui contacte un serveur: ça peut être un service en écoute qui attend un "magic packet" pour s'activer (cas des CISCO trojanisés par la NSA). Ca peut être une requête DNS innocente, comme par exemple allsportfootball.com. C'est légitime? Malicieux? Qui peut répondre?
Et si un malware s'implante dans le firmware de ta carte réseau, bonne chance pour toi pour 1/ t'en apercevoir, 2/ l'éradiquer
Donc oui, un trojan dans le matériel a beaucoup, beaucoup d'intérêt.
Il faut le découvrir (c'est pas gagné, ça peut durer des années). Pour les noms de domaines, ils peuvent être générés dynamiquement (c'est ce que font déjà une pléthore de malwares). Donc, si si, on peut utiliser des @IP ou des noms de domaines dans des malwares, matériels ou logiciels.
[^] # Re: Manger sa propre nourriture
Posté par claudex . Évalué à 9.
C'est exactement ce que je dis, le hack est dans la partie logiciel, pas dans le matériel. Quand on parle d'avoir des firmwares libres, c'est justement pour pouvoir lutter contre ça.
Donc, une backdoor, c'est aussi ce que je dis. Mais l'exemple que tu donne via du firmware, pas du matériel.
Tu ne parle que d'attaques sur le logiciel…
Si ta puce a des circuit dédiés pour la génération de nom de domaine, ça devient un sacré changement dans l'architecture. Et donc, un coût/une consommation différente.
Ça peut aussi arriver tout de suite et ce serait un sacré risque que d'avoir une attaque aussi coûteuse qui ne marche que pendant les 3 premiers mois du lancement du produit.
« 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: Manger sa propre nourriture
Posté par Benoît Sibaud (site web personnel) . Évalué à 9. Dernière modification le 29 août 2016 à 11:19.
Encore des exemples (récents) dans le logiciel :
http://news.softpedia.com/news/this-chinese-router-is-depressingly-insecure-and-downright-evil-507518.shtml
http://news.softpedia.com/news/smart-electrical-socket-leaks-your-email-address-can-launch-ddos-attacks-507448.shtml
http://motherboard.vice.com/read/hackers-could-break-into-your-monitor-to-spy-on-you-and-manipulate-your-pixels
http://arstechnica.com/security/2016/08/microsoft-secure-boot-firmware-snafu-leaks-golden-key/
…
Et côté matériel :
http://www.computerworld.com/article/3079417/security/researchers-built-devious-undetectable-hardware-level-backdoor-in-computer-chips.html et https://www.wired.com/2016/06/demonically-clever-backdoor-hides-inside-computer-chip/
(2014) http://hardware-libre.fr/2014/03/une-backdoor-materielle-dans-les-samsung-galaxy/
[^] # Re: Manger sa propre nourriture
Posté par reynum (site web personnel) . Évalué à -2.
Le logiciel par son essence même est plus proche d'une idée, une vue de l'esprit.
Le matériel contient des atomes structurés en molécules elles même pouvant former en une multitude de structures complexes.
Pour moi la différence entre logiciel et matériel est à peut près du même ordre que l’alcoolique qui voit un éléphant rose voler et créer un éléphant rose qui vole.
kentoc'h mervel eget bezan saotred
[^] # Re: Manger sa propre nourriture
Posté par Zenitram (site web personnel) . Évalué à -4.
Pour faire du AES de nos jours, j'ai le choix entre du code (logiciel) et des atomes structurés (c'est en dur dans le CPU). du coup, ta différence fait plouf.
AES (et d'autres : SHA-1 etc) sont des exemples pour démontrer que logiciel ou matériel, ce n'est pas un fantasme d'éléphants roses, juste un choix (qui dépend de contraintes par exemple économiques).
en fait, ce que tu décries est la différence entre logiciel et hardware, youpi mais ça n'aide en rien le débat sur pourquoi les gens trouvent "trop génial" d'avoir du 100% logiciel libre (tiens, je mets en atomes le driver pour la CG, vous serez heureux d'avoir du code 100% libre? OK, mais la backdoor est simplement dans le silicium, c'est tout, en plus d'être économiquement inutile)
[^] # Re: Manger sa propre nourriture
Posté par barmic . Évalué à 4.
Du coup, tu t'es acheter un ordinateur 100% soft histoire de ?
Qu'il y ait du choix à faire faire un traitement par le matériel ou le logiciel est effectivement une question de choix, mais la distinction est tout de même trivial pour l'utilisateur averti. La compilation du matériel n'a rien avoir avec celle du logiciel. Tu raisonne vraiment comme un ingénieur qui joue avec des cases sans chercher à comprendre ce que ça représente. Pour le matériel l'OpenHardware ne décrit pas les même libertés que le logiciel libre (même s'il cherche à s'en approcher).
Bizarre ce jusqueboutisme, tu prends de haut tes clients sous windows ou macos parce qu'ils utilisent ton logiciel libre sur un système non libre par exemple ?
Pour moi ça n'en vaut pas la peine.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Manger sa propre nourriture
Posté par Zenitram (site web personnel) . Évalué à 0. Dernière modification le 29 août 2016 à 16:14.
C'est fou comme on peut s'amuser à déformer les propos pour réussir à se persuader que la personne pense le contraire de ce qu'il pense réellement. Parce que là tu me vois "prendre de haut" les gens sous Windows ou Mac alors que je "prend de haut" les gens qui refusent d'installer un driver non libre "car le libre rulez hors de question d'avoir du non libre chez moi pour des question de sécurité" (sic) sur leur machine avec BIOS et CPU pas libre.
Bref, c'est triste que les gens n'essayent même pas de comprendre avant de "ne pas aimer" quelqu'un qui n'est pas "100% avec".
quand à mon "La compilation du matériel n'a rien avoir avec celle du logiciel", je t'invite à te renseigner en commençant par exemple à lire les commentaires ici (bref : logiciel ou matériel, c'est bien des cases à cocher car le but est exactement le même, juste la méthode qui change suivant des contraintes, et les bacdoors / virus ça marche autant en logiciel que matériel)
# Open Compute Project
Posté par Spack . Évalué à 5.
Que peux-t-on espérer du projet Open Compute lancé par Facebook ? J'imagine que c'est un peu pour combattre la situation actuelle.
# risc V
Posté par hurdman . Évalué à 3.
Sinon, je suis tombé là dessus il n'y a pas longtemps :
https://www.sifive.com/
C'est une bonne base de départ pour faire du hardware full libre, non ?
[^] # Re: risc V
Posté par karteum59 . Évalué à 3.
Yep, le journal suivant de vejmarie sur RISC-V en parlait justement. A suivre :)
# 2-3 remarques
Posté par karteum59 . Évalué à 10. Dernière modification le 29 août 2016 à 03:32.
Super journal ! Peu de personnes ont conscience du souci posé par le Management Engine :-/
Bon, j'ai quand même 3-4 remarques (sans grande importance, juste pour pinailler :)
Premier truc : je suis surpris par la phrase suivante dans le journal
Je pense (je peux me tromper) que OpenRISC est antérieur et n'utilise pas l'ISA RISC-V. "RISC" est un terme générique (même "ARM" signifiait "Acorn RISC Machine" !)
Tant que j'y suis, on lit aussi
Rappelons quand même que des coeurs comme MIPS24k sont utilisés dans un nombre considérables de SoCs pour routeurs chez Atheros/Mediatek/Realtek (par exemple l'AR9331, mais c'est juste un exemple)
Bon OK, on parlait d'un usage Desktop… On pourrait dans ce cas parler des SoC Ingenic, et justement comme le journal parle de EOMA68, Rhombus-Tech a justement envisagé de recourir à un processeur MIPS32 Ingenic JZ4775, qui était d'ailleurs apparemment le "meilleur" candidat d'un point de vue théorique/ouverture (là où Allwinner n'a pas spécialement bonne réputation…) mais malheureusement s'est finalement avéré irréaliste dans leur contexte (Initially, two EOMA68 Computer Cards were developed: one using an Ingenic jz4775, the other with an Allwinner A20. We planned to apply for RYF Certification on the jz4775 card because not only is there no GPU (there’s a Vector FPU similar to AltiVec), but the video processor’s source code is entirely GPL compliant, making it a seemingly perfect candidate for RYF Certification. However, upon close investigation, the only FSF-endorsed operating systems available for MIPS32 were so horribly-out-of-date that the resulting device would be pretty much unsaleable even to FSF supporters. Reluctantly we had to drop the jz4775 from immediate consideration), donc ça veut dire que "MIPS" ne signifie pas nécessairement "pas sympa avec le libre" :)
(N.B. je pense que cette réputation "pas cool avec le libre" vient surtout des GPU PowerVR et pas de la partie "MIPS", et j'avais discuté avec des personnes de Imagination Technologies il y a qq temps. J'ai retenu que des ingénieurs souhaitent faire bouger les choses en interne, mais c'est apparemment pas simple et ça prend du temps - notamment quand ils ont eux-même sous-traité / acheté du code à d'autres fournisseurs sous licence…)
Dernière chose - un peu hors-sujet : en ce qui me concerne sur le non-x86, mon premier souci est que beaucoup de fabricants de SoC et/ou OEMs se contrefichent généralement de la GPL (suffit de chercher "GPL violation" ou de demander les sources du kernel à à peu près n'importe quel OEM asiatique à base de Allwinner/Rockchip/ActionSemi/Mediatek/…), ceci alors même que ARM ne permet pas "one kernel to rule them all", et que le côté monolithique (+ l'idéologie "stable API nonsense") de Linux ne permet pas de découpler les parties dépendantes du HW du reste (pour recompiler facilement les parties génériques du kernel et combler une faille de sécurité par exemple). Bref, aujourd'hui le x86 reste encore la seule manière d'avoir une machine qui ne soit pas "jetable" au bout de 3 ans… (OK, j'exagère peut-être un peu : des fabricants de SoC comme NXP/TI s'engagent sur du support à long terme, ainsi que sur le support du device-tree, donc peut-être que j'accuse injustement ARM dans son ensemble. Mais c'est un fait que aujourd'hui tu peux booter une clé USB Linux générique sur n'importe quel PC du monde, alors qu'il faut une distro spécifique pour chaque machine ARM, réduisant sa durée de vie à celle du support)
Purism s'y est cassé les dents, mais ce ne sont pas les seuls (et ça fait peur) : Google engineers have tried for many years to get source code from Intel, and to reverse engineer the blobs that Intel provides. So far, they have been unsuccessful. Google is also one of the companies that funds the coreboot project, and they hire a lot of the core developers, so it's not like they don't have vast resources at their disposal. Smaller companies have no chance.
En dehors de Freescale, il me semble que nvidia a plutôt bien progressé en matière d'ouverture (d'après ce que je comprends, je n'ai pas été vérifier dans le détail), et ils n'utilisent évidemment pas de GPU Mali. M'enfin bon, y'a toujours plein de blobs et c'est sûrement un peu moins ouvert que NXP/Vivante, n'empêche que:
[^] # Re: 2-3 remarques
Posté par karteum59 . Évalué à 6.
Dans le cas des Cortex-A, c'est 249 ! :)
(Je me disais bien aussi qu'une quinzaine ça faisait peu… Par exemple, au delà des plus connus comme NVidia/NXP/TI/Qualcomm/Mediatek/Broaadcom/Samsung/Allwinner/Rockchip, il y a aussi HiSilicon (Huawei), Realtek, ST, Marvell, Apple, Toshiba, et plein d'autres moins "connus" comme Leadcore (Datang), ActionSemi, Spreadtrum, Ambarella, ZTE, AmLogic, Cavium, etc.)
[^] # Re: 2-3 remarques
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
Le problème de ARM est qu'ils ne définisse pas une "plateforme de base" comme le fait un "compatible PC" (x86+bios+…).
Linux a besoin au minimum d'une liaisons série de la rtc,, et de la RAM configuré. Si un bios ne le fait pas, il faut un bout de kernel spécifique. Idem pour la découverte des modules hardware : sous arm, rien n'est prévus pour déclarer l'existence de module HW, comme il en existe pour le PCI-e.
Pour faire un seul kernel pour arm, il faudrait un bloc minimum utilisable par linux + des tables de description. Arm devrait inclure RTC + liaison série de base + un moyen de boot simple + description du HW.
"La première sécurité est la liberté"
[^] # Re: 2-3 remarques
Posté par eingousef . Évalué à 4.
Effectivement, c'est moi qui me suis trompé, OpenRISC est antérieur et est basé sur RISC, pas RISC-V.
Je n'ai pas trop détaillé cette partie parce que c'est ce que je connais le moins (en atteste cette bourde :$ ), mais apparemment beaucoup des ISA en dehors de x86 sont des descendants de RISC : ARM, MIPS, POWER (Performance Optimization With Enhanced RISC), SPARC…
En fait le problème avec ARM c'est qu'il n'y a pas de support de PCIe, donc on ne peut pas éviter d'utiliser un GPU nécessitant du logiciel non-libre. J'ai parlé de cette initiative parce qu'elle fait parler d'elle dans le monde des libristes concernés par les firmwares, mais elle ne constitue pas vraiment une alternative pour un ordinateur personnel. Il n'y a que les ARM haut de gamme et ceux-ci sont nettement moins puissants que les POWER8 pour un prix probablement similaire.
J'en profite pour faire un appel à dépêche : si ceux qui s'y connaissent bien en RISC sur linuxfr (il y a l'air d'en avoir un certain nombre) pouvaient faire une dépêche pour expliquer aux béotiens ce qu'ils savent de cette ISA, couvrir les avancées de la communauté dans ce domaine, et combler les lacunes de mon article, ce serait grandement apprécié :)
*splash!*
[^] # Re: 2-3 remarques
Posté par karteum59 . Évalué à 6. Dernière modification le 29 août 2016 à 17:32.
Je ne suis même pas sûr que "descendants" soit le terme approprié : RISC est un terme générique désignant une approche (avoir un jeu d'instruction simple) et pas le nom d'un jeu d'instruction précis. Donc il y a plein d'ISA RISC qui ne sont pour autant pas descendants d'un ancètre commun initial et qui sont bien sûr incompatibles !
[^] # Re: 2-3 remarques
Posté par Eiffel . Évalué à 0.
Je confirme vos dires : RISC est un type de processeur (comme un diesel est un type de moteur).
La grande majorité des processeurs sont aujourd'hui des processeurs RISC (ARM, MIPS).
Il n'y a qu'Intel qui reste CISC et je pense que c'est essentiellement pour des questions "d'héritages" (être compatible avec d'anciennes plateformes/logiciels).
[^] # Re: 2-3 remarques
Posté par xcomcmdr . Évalué à 3.
Euh pas vraiment. Ça fait longtemps que les processeurs x86 sont plus proches du RISC qu'autre chose, et que CICSC/RISC ne veulent plus dire grand chose.
http://sunnyeves.blogspot.fr/2009/07/intel-x86-processors-cisc-or-risc-or.html
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: 2-3 remarques
Posté par reno . Évalué à 6.
xcomcmdr: RISC = Reduced Instruction Set Computer, donc le RISC est une propriété des ISA, des jeux d'instructions. Le jeux d'instruction x86 n'a PRESQUE PAS évolué vers un jeu d'instruction type RISC (load/store, décodage simple, etc).
Le seul point sur lequel on peut dire qu'ils ont évolué c'est le nombre de registre accessible dans l'ISA qui a augmenté lors du x86-64 (bien que restant très inférieur aux 32 registres entiers classique des ISA RISC).
Les implémentations des x86 et des RISCs se sont rapprochés oui, les ISA non.
[^] # Re: 2-3 remarques
Posté par Eiffel . Évalué à 2. Dernière modification le 30 août 2016 à 13:07.
Je suis tout à fait d'accord avec cette affirmation (qui est en opposition avec une partie de l'article blogspot).
En effet si on compare une ISA ARM avec une ISA MIPS il y a des différences (notamment la gestion des flags ARM) mais si on compare une ISA ARM ou MIPS avec une ISA Intel là les différences sont frappantes et les codes ne sont absolument pas pareils.
[^] # Re: 2-3 remarques
Posté par Nicolas Boulay (site web personnel) . Évalué à 8.
Pour mémoire, les 2 premiers jeu d'instruction RISC était SPARC et MIPS. Ils étaient très simple, donc rapide, et petit. Ils sont fait leur effets à leur sorti. Avec l'arrivé du superscalaire, l'avantage de leur taille a disparu (le gain dû à un décodeur simple étant masqué par la gestion des unités multiples).
RISC était à l'opposé du CISC qui avait des instructions tellement complexes qu'un compilateur ne savait pas les utilisé. Donc, ces instructions ont été vu comme inutiles.
De plus, le RISC a une "architecture load/store", cela veut dire que tout se faire depuis et/ou vers un registre. Cela veut dire que l'unité de mémoire est au même niveau que l'ALU dans le pipeline, dans un CISC, on peut faire des accès mémoire, puis une opération, puis une opération mémoire, cela signifie un pipeline très long. Donc, une grosse latence potentielle entre 2 instructions dépendantes, et tout ça, pour des opérations pas si courantes.
"La première sécurité est la liberté"
# Comment bookmark de gens optimistes
Posté par Colin Pitrat (site web personnel) . Évalué à 2.
Une (longue) présentation par Dave Patterson:
https://www.usenix.org/sites/default/files/conference/protected-files/fast14_asanovic.pdf
dont un passage (slide 20-27) prédit que la fin de la loi de Moore vers 2020 devrait entrainer une baisse du coût des "custom chips" (puces personalisées ?).
Plus que quelques années à attendre donc ?
[^] # Re: Comment bookmark de gens optimistes
Posté par Maclag . Évalué à 7.
Ça fait 20ans que la loi de Moore va s'arrêter dans les 5 prochaines années.
On fera autre chose que du silicium, on empilera verticalement à gogo, mais les coûts ne vont pas se casser la gueule comme ça. Regarde un peu combien ça coûte encore de fonder rien qu'en 90nm.
[^] # Re: Comment bookmark de gens optimistes
Posté par reno . Évalué à 8.
Tu retardes: je considère que la loi de Moore s'est déjà arrêtée..
[^] # Re: Comment bookmark de gens optimistes
Posté par Antoine . Évalué à 2.
On peut considérer ce qu'on veut, mais la "loi de Moore" est un énoncé précis (le doublement du nombre de transistors dans une puce tous les deux ans) qui, jusqu'à présent, ne colle pas trop mal à la réalité…
cf. https://fr.wikipedia.org/wiki/Loi_de_Moore
[^] # Re: Comment bookmark de gens optimistes
Posté par reno . Évalué à 3.
Et la version Anglaise dit "Intel stated in 2015 that the pace of advancement has slowed, starting at the 22 nm feature width around 2012, and continuing at 14 nm. Brian Krzanich, CEO of Intel, announced that "our cadence today is closer to two and a half years than two.”
C'est ce que je disais: la loi de Moore a du plomb dans l'aile..
[^] # Re: Comment bookmark de gens optimistes
Posté par Kerro . Évalué à 5.
2,5 ans au lieu de 2, tu ne vas tout de même pas faire croire que cela implique que cette règle empirique et approximative devient totalement fausse, sérieusement ?
Dans le passé il y a eu des périodes plus rapides et des moins rapides.
Je ne sais pas quel âge tu as, mais je suis aussi témoin du fait que depuis au moins 1990 chaque année « on » annonce que la loi de Moore est HS dans un futur plus ou moins proche. L'article Wikipedia n'est qu'un n-ième remake de ce marronnier.
Il y aura forcément une fin à cette « loi ». Mais jusqu'à présent 100 % des défaitistes se sont plantés.
[^] # Re: Comment bookmark de gens optimistes
Posté par cedric . Évalué à 6.
Elle a du plomb dans l'aile et c'est la même logique que pour les pics pétroliers et miniers. Il existe un point dans le temps où l'investissement en capitale nécessaire pour le prochain saut technologique dépasse les gains potentiels. Du coup, les investissements ralentissent au cours du temps.
Aujourd'hui il n'y a que deux constructeur à avoir la dernière techno de finesse de gravure. Intel et Samsung. Il y a 4 ans, ils étaient 4. Il y a dix ans, on avait du mal à les compter sur nos 10 doigts. Les usines de cette génération a coûté plus chère qu'un EPR et devra être remboursé en 2 ans…pour pouvoir construire la génération d'après… Qui coutera encore plus chère. En fait depuis 10 ans le coup de fabrication des usines à microprocesseur suit aussi une loi exponentielle, et ca, c'est pas bon.
Du coup, oui, ca ralentit. De la,à dire que ca s'arrête, on n'y est pas encore. Probablement une ou deux décennies avant que cela n'arrive (si on continue de fabriquer autant de Smart Phone, tablette et laptop pour justifier la prochaine génération).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Comment bookmark de gens optimistes
Posté par eingousef . Évalué à 3.
Quelques décennies.
Même avec un arrêt de la loi de Moore concevoir un CPU RISC-V capable d'atteindre les performances et l'efficacité énergétique d'un CPU Intel actuel nécessiterait un tel travail que la moitié des lecteurs de linuxfr sera à la retraite et l'autre moitié mangera les pissenlits par la racine avant de pouvoir en profiter.
(Ça ne veut pas dire qu'il ne faille pas y travailler, juste qu'il ne faut pas compter dessus à court terme)
*splash!*
[^] # Re: Comment bookmark de gens optimistes
Posté par karteum59 . Évalué à 5. Dernière modification le 29 août 2016 à 18:07.
Du coup, peut-être qu'un effort de sobriété devra venir des usagers (accepter une machine moins puissante et des clients lourds / des logiciels moins "jolis") et des développeurs (accepter de passer plus de temps dans de l'optimisation et d'utiliser des langages compilés plus contraignants) pour rendre à nouveau utilisable une machine peu performante (
<mode="vieux_con">dans mon jeune temps, j'ai tapé un rapport de stage complet sur un Amiga 1200 de base (68020 avec 2 Mo de RAM), et un autre sur un Psion série 5</mode>:)[^] # Re: Comment bookmark de gens optimistes
Posté par eingousef . Évalué à 6.
Pour la plupart des usages, oui, mais il y a des tâches qui ont légitimement besoin de puissance je dirais. Je sais pas trop quoi dire pour les CPU mais pour les GPU c'est vite vrai dans le monde artistique par exemple. Théoriquement, tu peux prendre les sources de n'importe quel film Blender et les recompiler de A à Z en utilisant uniquement du logiciel libre. En pratique… ben il te faudra des cartes Nvidia avec le driver proprio, si tu veux pouvoir finir le rendu du dernier Caminandes avant la prochaine ère glaciaire.
*splash!*
[^] # Re: Comment bookmark de gens optimistes
Posté par KiKouN . Évalué à 9.
Le pire, c'est que tu risque de retarder la prochaine ère glaciaire en n'utilisant que des CPUs.
[^] # Re: Comment bookmark de gens optimistes
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 3.
On m'aurait menti ?
# Merci pour cet article.
Posté par mlinux . Évalué à 10.
Superbe travail , je me suis régalé, merci !
# Remplacer le chipset pour se débarasser d'Intel ME ?
Posté par galactikboulay . Évalué à 2.
La question est certainement stupide, mais vu qu'il est difficile de se passer des CPU x86, n'est-il pas plutôt envisageable de remplacer la partie Intel PCH par quelque chose de compatible sans la partie vérole Intel ME ?
Si je comprends bien, le PCH gère le SATA, l'USB, le PCI-Express, …, Intel n'est pas le seul à faire ça non ?
En tout cas merci pour l'article, c'est très instructif.
[^] # Re: Remplacer le chipset pour se débarasser d'Intel ME ?
Posté par eingousef . Évalué à 4.
Comme expliqué dans la partie "État du marché", c'est Intel qui mène la danse. Tu veux mettre un socket Intel sur ta carte mère ? Tu acceptes les conditions d'Intel. C'est aussi bête que ça.
*splash!*
[^] # Re: Remplacer le chipset pour se débarasser d'Intel ME ?
Posté par galactikboulay . Évalué à 1.
Ok je pensais que ça ne concernait que la partie purement "firmware" et que si tu n'utilisais pas de chipset Intel, c'était un peu caduque du coup (sachant que si tu veux en utiliser un, de toute façon, sans les firmwares signés, ça ne marche pas ou pas longtemps). Intel empêche donc l'utilisation de chipsets tiers dans ses conditions mais est-ce qu'on connait dans le détail l'ensemble de ces conditions ? J'imagine que les fabricants de cartes mères doivent signer un NDA ?
[^] # Re: Remplacer le chipset pour se débarasser d'Intel ME ?
Posté par eingousef . Évalué à 3.
J'ai pas regardé mais je pense que tu peux facilement obtenir le contrat de licence d'exploitation des chipsets Intel, de même que le FSP et sa licence. Quant aux NDA : la master key d'Intel reste chez Intel, et elle sert à signer les clés des fabricants de cartes mères. Le ME vérifie ensuite si la clé du fabricant a bien été signée avec la master key d'Intel. Chaque entreprise garde sa clé chez elle, il n'y a pas de secret partagé.
*splash!*
[^] # Re: Remplacer le chipset pour se débarasser d'Intel ME ?
Posté par bubar🦥 (Mastodon) . Évalué à 3.
Sur certaines machines tu peux remplacer celui faisant presque 5MO par celui faisant un peu moins de 1,7MO.
# Coquille
Posté par PolePosition . Évalué à 1.
"vous ferez face face à un GBE"
=> "vous ferez face à un GBE"
[^] # Re: Coquille
Posté par palm123 (site web personnel) . Évalué à 2.
corrigé, merci
ウィズコロナ
# AMT / ME = probablement backdoor
Posté par DerekSagan . Évalué à 4.
sans dec ?
le truc bourré ici à la demande voire par la NSA pourrait ne pas être libéré ?
moi ce que j'aime le plus c'est les options des bios qui te propose de désactiver AMT, si tu le fais ça te dit "ayé céfé", mais en fait t'en sais rien: les fonctionnalités officielles sont coupées, mais les autres tu peux pas savoir
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: AMT / ME = probablement backdoor
Posté par Franck Routier (Mastodon) . Évalué à 5.
Ah oui… comme là par exemple https://support.lenovo.com/fr/en/product_security/len_3556 :-)
Donc Lenovo vient de découvrir (06/2016) que le provisioning (déclaration du serveur de prise de contrôle) de l'AMT de certains Thinkpad reste possible même désactivé dans le Bios en cas d'accès physique au port USB…
dès lors, votre machine est contrôlée à distance, sans aucun moyen de savoir ce qui se passe (y compris si elle est éteinte ! (et branchée quand même)).
Sans parler de conspiration, ça fout les chocottes… et en imaginant un tout petit peu de conspiration (et Snowden est passé par là quand même !), il est impossible de faire confiance à ces technos…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
# Intéressant
Posté par Nicolas Chevallier (site web personnel) . Évalué à 3.
Excellent article, très complet. Je ne pensais pas qu'il y avait autant de micrologiciels nécessaires avant le démarrage des PCs. Sur Mac je crois qu'il n'y a qu'un seul firmware non ?
[^] # Re: Intéressant
Posté par eingousef . Évalué à 7.
Les ordinateurs Apple utilisent des CPU Intel depuis 2006, leur cas n'est pas différent de celui des autres plateformes Intel.
*splash!*
[^] # Re: Intéressant
Posté par DerekSagan . Évalué à 3.
A.k.a. les macs c'est des PC avec une pomme dessus et un OS différent.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.