mardi 07 octobre
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

Dépêche éditée par

: Pilotes binaires dans Linux: quel est le problème ?

Posté par Thomas Petazzoni (page perso, ). Modéré le 08 décembre 2005.
0
Aujourd'hui, le nombre de périphériques nécessitant des pilotes binaires dans le noyau Linux s'accroît. Du côté des cartes graphiques, NVidia a toujours livré des pilotes binaires pour Linux. ATI, qui à l'origine fournissait des pilotes libres a rejoint NVidia et livre maintenant des pilotes binaires. De nombreux chipsets Wifi ne disposent pas non plus de pilotes libres, et les utilisateurs doivent passer par ndiswrapper, une couche de compatibilité permettant d'utiliser sous Linux des pilotes prévus pour Windows.

Ces pilotes binaires posent un certain nombre de problèmes, qui ont poussé Arjan van de Ven, développeur du noyau Linux, à publier une petite fiction intitulée « Linux dans un monde binaire, une hypothétique débâcle ». Cette petite fiction, dont une traduction rapide et non-officielle est proposée dans le corps de l'article, pourrait bien devenir réalité si les pilotes binaires venaient à se généraliser. Le traducteur a ajouté des notes de bas de page à l'histoire afin de faciliter sa compréhension par des non-spécialistes.

Pour résumer, voici quelques-uns des problèmes posés par les pilotes non-libres:
  • Il est impossible de mettre à jour son noyau si le constructeur n'a pas sorti de nouvelle version de son pilote. Si le constructeur décide que le matériel ne vaut plus le coup d'être supporté, alors il n'y a tout simplement plus de pilote ;
  • Pour que les pilotes binaires fonctionnent bien, il faut une interface avec le noyau qui ne change pas. Cela est une aberration technique, car une interface gelée freinerait grandement le développement du noyau (voir ce document de Greg Kroah-Hartman) ;
  • Le fait d'utiliser des pilotes binaires implique d'avoir du code qui s'exécute en mode privilégié et qu'on ne peut pas auditer ou étudier. Il est alors impossible de savoir si ce code n'effectue rien de malveillant (l'histoire du rootkit Sony n'est pas si lointaine). Les bugs qu'il comporte peuvent entraîner des corruptions de données ou des plantages qui affecteront la totalité de la machine, et pas simplement un programme individuel. C'est d'ailleurs la raison pour laquelle les développeurs du noyau refusent aujourd'hui de corriger des « oops » signalés par un utilisateur lorsque des modules binaires sont chargés ;
  • L'utilisation de pilotes binaires, ou de pilotes Windows au travers de ndiswrapper réduit la pression sur les constructeurs pour qu'ils mettent à disposition des pilotes libres ou les spécifications de leur matériel, et réduit la pression sur les développeurs de Logiciels Libres pour qu'ils développement des pilotes compatibles et libres.
En cette époque de fin d'année et d'achats pour Noël, choisissez donc bien votre matériel !

> Lire la suite (200 commentaires, moyenne: 3).   [dépêche : 14531 caractères]

Linux dans un monde binaire

Que se passerait-il si demain les développeurs du noyau Linux acceptaient que les modules binaires sont une bonne chose et qu'ils sont essentiels au progrès de Linux ?

Une hypothétique débâcle, par Arjan van de Ven

L'hypothèse principale sur laquelle est basé ce scénario ne va évidemment pas se produire, mais toutes les affirmations qui suivent sont basées sur des éléments tangibles.

Le 6 décembre 2005, les développeurs du noyau décident en masse que les modules binaires sont légaux [1] et qu'ils sont souhaitables pour le progrès de Linux. Au départ, le processus de développement du noyau Linux ne change pas vraiment, à part le fait que de nouveaux symboles sont exportés, et que EXPORT_SYMBOL_GPL [2] est supprimé.

Trois semaines plus tard, des distributions comme Red Hat Enterprise Linux et SuSE SLES commencent à inclure de nombreux modules binaires dans leurs CD d'installation. Debian s'y refuse et reste fidèle à sa cause, ainsi que les autres distributions ouvertes comme Fedora Core ou openSuSE.

Les distributions professionnelles n'incluent pas seulement les modules NVidia et ATI, mais incluent également les modules fakeraid et les différents pilotes wifi, winmodem, windsl et TCP-offloading. À l'inverse de NVidia et ATI, la plupart des constructeurs livrant des pilotes binaires ne proposent pas de couche d'abstraction [3] dont le code source est disponible: ils proposent seulement la version binaire finale.

Plusieurs constructeurs de matériel qui avaient jusqu'à présent été coopératifs avec la communauté du Logiciel Libre voient leurs concurrents livrer uniquement des pilotes binaires. Chez eux, la pression monte pour que la « propriété intellectuelle » soit sauvegardée. Certaines fonctionnalités de leurs matériels ne sont pas exploitées par les pilotes parce que leurs départements juridiques estiment que le risque de divulgation de leur « propriété intellectuelle » est beaucoup trop important. Par conséquent, ils considèrent que les pilotes binaires de leurs concurrents ont un avantage concurrentiel, ou au moins que leurs propres pilotes pourraient y gagner en étant fermés, parce qu'ils pourraient alors utiliser ces quelques fonctionnalités supplémentaires afin de dominer la compétition. [4] Le 1er février 2006, environ la moitié des constructeurs de matériel ont recentré leur travail sur les pilotes pour Linux autour de la création de valeur ajoutée dans des pilotes binaires qu'ils distribueront en plus des pilotes libres qui existent déjà. Certains constructeurs ont même stoppé le support des pilotes libres parce qu'ils n'ont pas assez de ressources pour maintenir deux versions en parallèle.

Premier mars. Toutes les nouvelles gammes de serveurs des plus grands constructeurs embarquent la nouvelle génération de matériel réseau et de stockage. Ce matériel est livré avec des pilotes binaires pour les deux dernières versions des distributions RHEL et SLES, et ces pilotes sont déjà intégrés dans les mises à jour de février de ces distributions. L'un des constructeurs livre son pilote sous la forme d'un binaire et d'une couche d'abstraction, les autres n'y attachent pas d'importance et livrent uniquement des pilotes binaires pour ces deux distributions. Deux des constructeurs de cartes réseau publient une mise à jour de leur pilote libre avec un support réduit des nouvelles cartes. Les autres constructeurs ne le font pas. Le matériel grand public n'est pas vraiment affecté: la plupart des chipsets des produits grand public sont basés sur le standard AHCI pour le stockage SATA, et conservent les fonctionnalités existantes dans les chipsets réseau.

Premier avril. Deux des constructeurs de chipsets ont mis à jour leurs puces pour inclure une nouvelle fonctionnalité audio intéressante qui permet une lecture améliorée des DVD, mais malheureusement, cela les oblige à dévier de l'interface audio "standard" i810. L'un des constructeurs publie un pilote binaire pour quelques distributions, les autres ne considèrent pas Linux intéressant pour le desktop et ne jugent pas utile de faire un pilote pour Linux pour le moment.

Premier mai. Tous les serveurs que l'on peut acheter demandent au moins un, mais souvent deux ou trois modules binaires pour fonctionner. Bien que certains de ces pilotes soient disponibles sous la forme d'un « blob binaire » et d'une couche d'abstraction, plusieurs sont seulement disponibles pour RHEL3, RHEL4 et SLES 9 et parfois pour la nouvelle distribution SLES10. Les utilisateurs de Linux sur ces serveurs n'ont d'autre choix que ces quatre noyaux, sans le moindre espoir de pouvoir exécuter un noyau « vanilla » [5] provenant de kernel.org. La communauté d'Ubuntu est sérieusement agacée, et essaie, avec un succès mitigé, d'inclure des pilotes libre sa distribution. Grâce au demi-succès de ce lobbying, environ 50% de ces serveurs pourront fonctionner avec le noyau Ubuntu.

Premier juin. Une énorme « flamewar&nsbp;», la quatrième sur ce sujet depuis janvier, a lieu sur la liste de diffusion du noyau Linux. Les utilisateurs et quelques développeurs demandent à ce que les développeurs du noyau officiel (kernel.org) adoptent l'ABI module [6] existante dans la distribution RHEL ou la distribution SLES. Après investigation, il apparaît que cela n'est pas possible, et le fil de discussion s'oriente vers un débat entre la définition d'une nouvelle ABI, ou le gel de l'ABI actuelle. De nombreux développeurs du noyau ont le sentiment que l'ABI existante ne convient pas pour devenir une ABI stable, et qu'une nouvelle ABI et API, conçue de manière à pouvoir rester stable plus facilement est la bonne solution. D'autres disent que cela prendra trop de temps et que cela ne servira à rien pendant les deux prochaines années, tant que RHEL et SLES n'auront pas adopté cette ABI. Ils demandent au moins un gel immédiat de l'ABI du noyau « vanilla » de façon à ce que la prochaine RHEL5 l'utilise et livre des pilotes écrits pour cette ABI. Les utilisateurs utilisent généralement la RHEL ou la SLES pour les serveurs de productions, ou des clones comme CentOS qui disposent d'une compatibilité binaire au niveau du noyau.

Premier juillet. Il devient de plus en plus difficile de faire fonctionner Linux sans modules binaires sur la plupart des nouveaux PCs grand public. Alors qu'un an plus tôt, les gens devaient pour cette raison abandonner l'accélération 3D, maintenant même la 2D ne fonctionne plus sans pilotes binaires, pas plus que le réseau (aussi bien filaire que sans fil) ou le son. Pour la moitié des machines, il n'y a pas de support Linux, tandis que 20% des machines utilisent des systèmes de traduction comme NdisWrapper pour faire fonctionner les pilotes son et réseau conçus pour Windows sous Linux. Le projet Debian, qui ne peut maintenant plus fonctionner sur la plupart des machines, perd une énorme quantité d'utilisateurs qui migrent vers Ubuntu, ou des hybrides Ubuntu-Debian. La liste Debian-legal et d'autres listes du projet sont monopolisées par ce sujet, déclenchant de vifs débats. La plupart des constructeurs qui livraient encore des pilotes libres plus à moins à jour ont tout simplement arrêté de le faire.

Quartorze juillet. Linus Torvalds déclare que l'ABI du noyau est maintenant stable, mais crée en même temps la branche 2.7 du noyau, et annonce que le noyau 2.8 aura une ABI différente. En pratique, seules les personnes qui ont encore accès à leurs vieilles machines peuvent désormais aider au développement du noyau 2.7, puisqu'aucun pilote fourni par les constructeurs, même ceux qui ont encore une couche d'abstraction ne peuvent suivre l'arbre de développement du noyau dans lequel les changements sont "trop rapides" pour être suivi par les constructeurs.

Vingt-et-un août. Une faille de sécurité sérieuse est découverte dans les noyaux de la série 2.6. Cette faille de sécurité s'avère être liée à un problème de conception d'une API importante du "sysfs" [7]. Corriger cette faille nécessiterait de casser l'ABI des modules, et donc en pratique tous les modules binaires disponibles, alors que la non-correction de cette faille laisserait ouvert un trou de sécurité dont l'exploitation permet de passer "root". Un correctif est rapidement publié sous la forme d'une option de configuration, mais les utilisateurs ayant besoin de pilotes binaires n'ont pas d'autre choix que de laisser leurs systèmes vulnérables [8]. Les trolls sur la liste de diffusion du noyau recommencent et Linus est accusé d'avoir commis une erreur en gelant l'ABI existante plutôt qu'en créant une nouvelle ABI destinée à être gelée. Le développement du 2.7 est quasiment à l'arrêt et un patch est proposé afin de disposer dans le 2.7 d'une ABI similaire à celle du 2.6, patch nécessitant de retirer de nombreuses améliorations importantes du sous-système de gestion de mémoire virtuelle ainsi que les patchs de gestion du temps réel d'Ingo [9].

Vingt-six août. Un exploit prêt à l'emploi pour le trou de sécurité arrive sur BugTraq et est identifié comme étant utilisé par différents rootkits. Un exploit PHP l'utilise pour passer de l'utilisateur httpd à root. Les utilisateurs mettent la pression sur les distributeurs de modules pour qu'ils mettent à jour ceux-ci avec la nouvelle ABI, et plusieurs d'entre eux le font dans les trois semaines qui suivent. Les autres, principalement les constructeurs fabriquant du matériel grand public, disent que la matériel en question n'est plus construit et qu'ils ne sont pas prêts à dépenser du temps ou de l'argent pour produire des pilotes compatibles avec la nouvelle ABI.

Maintenant, ce scénario peut vous sembler improbable. Et fort heureusement la principale hypothèse (l'évènement du 6 décembre) est effectivement très peu probable.

Malheureusement, plusieurs des autres faits ne sont pas si improbables. En fait, certains de ces faits sont même très probables, comme en témoignent les trolls sur la liste de diffusion du noyau concernant la rupture de l'API et l'ABI des modules, ou l'effet « ndiswrapper » sur les constructeurs qui disent maintenant « nous supportons Linux, parce que ndiswrapper permet d'utiliser notre pilote Windows ». J'espère que cela n'aura pas lieu. Une partie de cet espoir est un espoir silencieux, mais je crois que les avantages de la liberté sont suffisamment importants pour surmonter les forces contraires.

Notes du traducteur, pour faciliter la compréhension de l'histoire à des non-spécialistes

[1] Aujourd'hui, les modules binaires sont plus ou moins tolérés. Il n'y a pas réellement de position officielle à ce sujet, et les débats sont souvent vifs sur la liste de développement du noyau. Tout le débat repose sur l'interprétation de la notion de « travail dérivé », tel que défini par la licence GPL.

[2] Dans le noyau Linux, pour que des modules externes puissent appeler des fonctions du coeur du noyau, il faut que ces fonctions soient « exportées ». Pour cela, les développeurs du noyau peuvent utiliser les instruction EXPORT_SYMBOL() ou EXPORT_SYMBOL_GPL(). EXPORT_SYMBOL() rend la fonction utilisable dans les modules libres et propriétaires, tandis que, en principe, EXPORT_SYMBOL_GPL() rend la fonction utilisable uniquement dans les modules sous licence GPL. Cette différence n'a pas de valeur juridique, mais elle est une indication du fait que les développeurs considèrent que l'utilisation de telle ou telle fonction du noyau constitue un travail dérivé de celui-ci.

[3] NVidia livre ses pilotes binaires sous une forme un peu particulière. Ils sont constitués d'une partie binaire, le coeur du pilote, et d'une partie dont les sources sont disponibles, qui sert de couche d'abstraction entre le noyau et la partie binaire. En anglais, la couche d'abstraction est souvent appelée « glue layer ». Ce fonctionnement permet de recompiler son noyau et la glue, tout en conservant la même partie binaire. Sans ce mécanisme, il faudrait à chaque fois qu'un nouveau noyau sort où que l'on recompile son noyau, que NVidia sorte une nouvelle version de ses pilotes.

[4] À ce sujet, ATI livrait auparavant des pilotes libres et les spécifications de leur matériel. Depuis que NVidia met à disposition des pilotes binaires, ATI fait de même.

[5] Le noyau dit « vanilla » est le noyau officiel disponible sur kernel.org. Il est dit « vanilla » par opposition aux noyaux fournis par les distributions (Fedora, Debian, Ubuntu, Mandriva, etc.) qui incluent des patches qui les font dériver de la version officielle.

[6] ABI désigne l'« Application Binary Interface », c'est-à-dire l'interface binaire entre deux sous-systèmes. Un changement d'ABI a lieu lorsque des structures de données changent, ou lorsque des prototypes de fonction changent. Un changement d'ABI nécessite une recompilation, ce qui pose problème aux constructeurs souhaitant livrer des modules propriétaires. Ils font donc pression pour disposer d'une ABI stable pour programmer des modules noyau. Pourtant, c'est une aberration technique, voir ce document de Greg Kroah-Hartman.

[7] « sysfs » est un des sous-systèmes du noyau Linux 2.6 permettant à des applications d'interagir avec les pilotes de périphériques en mode noyau.

[8] En effet, la correction de la faille de sécurité entraînant un changement d'ABI, il n'est plus possible d'utiliser les pilotes binaires: il faut attendre que le constructeur publie une nouvelle version de son pilote. Aujourd'hui, les utilisateurs de routeurs personnels Linksys WRT54 ne peuvent pas migrer leur petite machine vers le noyau 2.6: ils sont bloqués, car le pilote Wifi Broadcom 43xx n'est disponible qu'en module binaire pour le noyau 2.4. Heureusement deux équipes de fous très compétentes se sont lancées dans la rétro-ingénierie du pilote binaire avec des résultats intéressants, mais est-ce véritablement une solution viable ?

[9] En référence à Ingo Molnar qui travaille sur des patches pour le noyau Linux améliorant la latence de celui-ci, le rendant plus adapté à des applications audio très sensibles aux temps de réponse.

Un grand merci à Gaël Utard et Colin Leroy pour la relecture et les corrections.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

C'est parti ..

Posté par Xavier Bestel (Jabber id, page perso, ) le 08/12/2005 à 06:59. (lien). Évalué à 10.

Je vois d'ici les commentaires du genre "ben moi je trouve que les drivers nvidia sont au top, bien mieux que les drivers libres" ou "les développeurs du kernel sont des dictateurs, les utilisateurs ont le droit de faire ce qu'ils veulent" ou encore "une ABI stable pour les drivers ça serait quand même beaucoup plus pratique".
La situation est pourtant simple: en autorisant les drivers binaires on se retrouve comme sous Windows à la merci du bon vouloir du constructeur, qui s'arrête là où les clients de payent plus.
Pourquoi n'y a-t'il plus de Windows sous processeur Alpha ?
Pourquoi Win64 ne démarre-t'il pas ?
Parceque tous les drivers sont sous Windows IA32 et que les constructeurs ne vont pas faire l'effort de les porter sur d'autres architectures si ça ne génère pas de ventes significatives.

Le but de Linux c'est d'avoir un système d'exploitation libre, pas gratuit.

OpenBSD

Posté par Nicolas Bernard (page perso, ) le 08/12/2005 à 07:08. (lien). Évalué à 10.

Notons en passant que pour toutes ces raisons avec en plus un "le système doit être libre pour tous les usages", l'équipe d'OpenBSD refuse farouchement toute inclusion de pilote binaire dans leur système.

Dans cette même politique, ils mènent régulièrement des campagnes de lobbying auprès des constructeurs pour qu'ils fassent des pilotes libres ou publient les spécifications permettant d'en faire. En cas de refus, soit le driver closed source est déassemblé pour en refaire un open source (ex: cartes wifi avec chipset atheros) soit, si le matériel n'est pas prioritaire vis-à-vis des objectifs d'OpenBSD, il est déclaré non supporté et il est suggéré de ne pas l'acheter.

Linuxfr a déjà relayé certaines des campagnes pour la publications des spécifications:
http://linuxfr.org/2005/03/19/18549.html

Oui, mais que faire ?

Posté par Arthur Accroc () le 08/12/2005 à 07:31. (lien). Évalué à 10.

Voilà un article utile !

J'ai souvent fait des remarques de ce genre... et je me suis souvent fait moinser dessus. Il faut dire que je les ai faites en commentaire sur des annonces de nouveaux pilotes binaires ATI/nVidia et que ça gâchait peut-être la fête du nouveau pilote (buggé) de la mort pour la dernière carte 3D qui coûte le prix d'une console complète.

Maintenant, quelles sont les possibilités pour se sortir de cette situation ?

Si les développeurs du noyau refusaient totalement les pilotes binaires à partir de demain, ça pourrait limiter plus la diffusion de Linux que celles des matériels coupables...
Peut-être pourraient-ils déjà afficher au démarrage un message du genre "Attention, en raison de la présence d'un pilote propriétaire fermé (closed source) pour tel matériel dans votre noyau, l'intégrité de votre système ne peut être garantie" ?
Il faudrait peut-être utiliser le terme "non-certifié". Si ça pouvait déjà garantir que les constructeurs ne vendent pas comme "certifiées Linux" des machines contenant du matériel ne fonctionnant qu'avec des pilotes propriétaires, ce serait déjà un premier pas.

Une page sur kernel.org ou directement dans la doc du noyau avec la liste des matériel supportés par le kernel officiel pourrait fournir une véritable référence pour le choix de matériel (ce qui existe actuellement manque un peu de visibilité). En demandant aux constructeurs qui fournissent leurs spécs de fournir une table de conversion entre le type technique de leur matériel (vu par les pilotes) et les dénominations commerciales de ses variantes compatibles, ça pourrait être faisable.

En attendant, au niveau de LinuxFr, pourquoi ne pas déjà arrêter de passer les annonces de pilotes propriétaires, en tout cas en première page ?

Et le "nerf de la guerre", c'est qu'au niveau de chaque utilisateur, il est important d'acheter préférentiellement du matériel dont les spécifications sont disponibles plutôt que du matériel supporté uniquement par des pilotes binaires.
Nous votons avec notre argent : si nous achetons sans réticence du matériel supporté uniquement par des pilotes binaires, uniquement sur les plateformes les plus classiques et sans garantie que le support continuera une fois que le modèle ne sera plus produit, c'est un signe clair pour les constructeurs qu'ils n'ont pas à faire d'effort pour faire mieux. C'est comme cela qu'ATI a interprété le succès de nVidia y compris sur Linux...
Et les petits ruisseaux formant les grandes rivières, il faut prendre conscience que vous êtes responsable du futur (ça ne vaut pas que pour Linux, d'ailleurs).

--
Berlin 1936, Moscou 1980, Pékin 2008.
Jeux Olympiques, sponsor officiel de la dictature.
Mexico 1968, Pékin 2008.
Jeux Olympiques, sponsor officiel de la répression.

Oui, mais....

Posté par Martyanoff Nicolas (Jabber id, page perso, ) le 08/12/2005 à 08:04. (lien). Évalué à 9.

Le problème, c'est qu'en ce qui concerne l'accélération 3D, on a pas réellement le choix.
Si je veux faire de la prog OpenGL avancée (shaders...), il me faut l'accélération 3D sur une carte récente.
Il n'existe pas de pilotes libres efficaces pour une Radeon 9800pro (en fait pour toute carte postérieure à la Radeon 9200 chez ATI), donc je n'ai pas le choix, même si cela m'énerve pas mal.

Et le "je n'ai pas le choix", cela arrive aussi pour ceux qui ont un portable, et qui ont un chipset wi-fi non supporté par des drivers libres.

Bref, a quand des cartes graphiques modernes, performantes, avec un support OpenGL 2.0 complet, ET des pilotes libres ?