URL: https://linuxfr.org/news/le-logiciel-libre-au-dela-de-x86 Title: Le logiciel libre au-delà de x86 Authors: eingousef Davy Defaud, Benoît Sibaud, bubar🦥, palm123, Pierre Jarillon et claudex Date: 2016年08月27日T16:03:21+02:00 License: CC By-SA Tags: power, coreboot, libreboot, richard_stallman, intel, amd et arm Score: 108 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](https://www.coreboot.org) 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. ---- [Journal à l’origine de la dépêche](http://linuxfr.org/users/eingousef--2/journaux/le-logiciel-libre-au-dela-de-x86) [Explications de la situation Intel chez Libreboot](https://libreboot.org/faq/#intel) ---- # 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](https://www.coreboot.org/Binary_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](https://libreboot.org/) (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. ![LibreBoot](https://libreboot.org/logo/logo.svg) 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](https://en.wikipedia.org/wiki/Intel_Active_Management_Technology). 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é](http://me.bios.io/Main_Page). 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](http://io.netgarage.org/me/) 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 31^(e) _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 4^(e) 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](https://fr.wikipedia.org/wiki/Gestion_des_droits_num%C3%A9riques "digital rights management")), à l’image de PAVP chez Intel et à la sécurité ([TPM](https://fr.wikipedia.org/wiki/Trusted_Platform_Module "Trusted Platform Module"), 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_](https://fr.wikipedia.org/wiki/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](https://ryf.fsf.org/ "Respect your freedom") 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 n^(o) 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é n^(o) 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é n^(o) 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_](https://linuxfr.org/users/whygee/journaux/free-hardware-designs-le-site), 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](https://linuxfr.org/news/librem-13-l-espoir-d-avoir-un-jour-un-ordinateur-libre), 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](https://linuxfr.org/news/etat-des-pilotes-graphiques-libres-pour-soc) 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_](https://kosagi.com//w/index.php?title=Novena_Main_Page), 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](http://f-cpu.org/) et [YASEP](http://yasep.org/), mais il en existe d’autres, notamment le fameux projet [OpenCores](http://opencores.org/) (qui semble maintenant être remplacé par [LibreCores](http://librecores.org/) ), 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](http://www.lowrisc.org/). 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_](https://www.coreboot.org/). Par le biais de son entreprise [Raptor Engineering](https://www.raptorengineering.com/), 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](http://mail.fsfeurope.org/pipermail/discussion/2016-April/010912.html) 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](https://github.com/open-power) 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_](http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68) de [Rhombus Tech](http://rhombus-tech.net/). 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](https://ryf.fsf.org/) fasse partie des objectifs mérite qu’on y jette un œil.

AltStyle によって変換されたページ (->オリジナル) /