- La communauté du noyau Linux se méfie depuis longtemps des modules noyau propriétaires, et le patch de Christoph Hellwig vise à resserrer encore l’une des échappatoires
- Plutôt que d’interdire le chargement des modules propriétaires en tant que tel, le noyau utilise les exports réservés GPL pour n’autoriser l’accès à certains symboles du noyau qu’aux modules compatibles GPL
- En 2020, une méthode dite GPL condom, dans laquelle un module GPL sert d’intermédiaire entre un module propriétaire et le noyau, a été mise au jour ; depuis, les modules qui utilisent des symboles propriétaires sont eux aussi considérés comme propriétaires
- La nouvelle échappatoire consiste à utiliser
symbol_get()pour récupérer l’adresse de symboles internes d’un module propriétaire sans passer par la procédure normale d’import ; Hellwig estime que NVIDIA a modifié son code pour recourir à cette méthode - Le patch proposé fait en sorte que
symbol_get()échoue lors de la recherche de symboles non marqués GPL-only, ce qui bloque cette échappatoire, mais tant que les modules s’exécutent dans l’espace d’adressage du noyau, il reste difficile de rendre ce contrôle d’accès totalement sûr
Une vieille tension autour des modules noyau propriétaires
- La communauté du noyau Linux n’a jamais eu de relation fluide avec les fournisseurs de modules noyau propriétaires
- Ces modules sont difficiles à déboguer ou à corriger pour quiconque autre que leur auteur
- Beaucoup de développeurs y voient une violation de la licence du noyau et du droit d’auteur sur le code
- Malgré cela, les modules propriétaires ont été tolérés dans une certaine mesure
- Le patch récent de Christoph Hellwig s’inscrit dans une volonté de réduire encore un peu ce périmètre de tolérance
La tentative d’interdiction de chargement en 2006 et les exports réservés GPL
- En 2006, une brève tentative a eu lieu pour interdire totalement le chargement des modules noyau propriétaires
- Linus Torvalds s’y est opposé pour plusieurs raisons
- Le simple fait de charger un module propriétaire dans le noyau Linux ne constitue pas en soi une violation du droit d’auteur
- Les utilisateurs de Linux peuvent le faire
- Torvalds estimait qu’une telle interdiction risquait de signaler un intérêt plus fort pour les querelles de licence que pour l’amélioration technique
- La distribution de modules propriétaires peut en revanche constituer une violation du droit d’auteur si ces modules sont des œuvres dérivées du code du noyau
- Mais la qualification d’œuvre dérivée reste floue, et le noyau lui-même est mal placé pour trancher réellement cette question
- Le noyau dispose depuis longtemps d’un mécanisme destiné à bloquer les modules potentiellement en infraction : les exports réservés GPL
- Pour être utiles, les modules noyau doivent accéder aux fonctions et aux structures de données exportées par le noyau sous forme de symboles
- De nombreux symboles ne sont accessibles qu’aux modules déclarant une licence compatible GPL
- Ce mécanisme écarte les modules propriétaires d’une part importante des fonctionnalités du noyau
L’intention des marquages GPL-only et la réalité
- En théorie, le marquage GPL-only signifie qu’un symbole est si profondément couplé aux internals du noyau que tout code qui l’utilise constitue nécessairement une œuvre dérivée du noyau
- En pratique, les développeurs ne mènent pas ce type d’analyse juridique
- Ils n’en ont généralement pas non plus la compétence
- Dans les faits, marquer un symbole en GPL-only sert souvent surtout à compliquer plus largement la vie des modules propriétaires
La méthode de contournement par intermédiaire révélée en 2020
- Les auteurs de modules propriétaires cherchent depuis longtemps des moyens de contourner les restrictions liées aux exports réservés GPL
- Une méthode consiste à déclarer faussement une licence compatible GPL, mais cela ressemble trop à l’aveu explicite d’un comportement fautif, ce que les entreprises évitent instinctivement
- Une approche plus subtile est apparue en 2020 lors d’une série de patchs sur le DMA peer-to-peer
- Dans cette architecture, un module déclarant une licence compatible GPL sert d’intermédiaire
- Ce module peut accéder à tous les symboles exportés par le noyau
- En important ensuite les symboles du module propriétaire, il permet au code propriétaire d’accéder aux fonctionnalités du noyau dont il a besoin
- C’est une variante de ce qu’on appelle couramment le GPL condom
Le patch de réponse en 2020
- À l’époque, Hellwig a fusionné un patch destiné à compliquer cette méthode
- Dans le noyau actuel, un module qui utilise les symboles d’un module propriétaire est lui aussi traité comme propriétaire
- Il perd immédiatement la capacité d’accéder aux symboles réservés GPL
- S’il a déjà utilisé des symboles GPL-only, l’import de symboles d’un module propriétaire échoue
- Cette vérification bloque la possibilité pour un module GPL de jouer l’intermédiaire entre un module propriétaire et le noyau
Une nouvelle échappatoire via symbol_get()
- Le noyau fournit la macro
symbol_get(), dont le travail réel est effectué par__symbol_get() - Cette fonctionnalité recherche l’adresse associée à un symbole du noyau
symbol_get()est présent dans le noyau depuis la version 2.5.48, publiée en 2002, et a été ajouté lors d’une refonte majeure du chargeur de modules- Elle comporte aussi des limites importantes
- Elle ne recherche que les symboles fournis par des modules chargeables
- Elle sert à des modules étroitement liés pour gérer le cas où l’un d’eux ne serait pas encore chargé, sans créer de boucle de références
- En apparence, elle ne permet pas de localiser des symboles GPL-only du noyau, et semble donc peu utile aux éditeurs de modules propriétaires cherchant à contourner les règles
Comment symbol_get() contourne la défense de 2020
symbol_get()peut être utilisé pour obtenir l’adresse d’un module propriétaire sans passer par le mécanisme normal d’import et ses restrictions- Cela permet de contourner à nouveau la modification de 2020
- Un module nominalement sous licence GPL peut appeler le module propriétaire
- Ce module propriétaire peut alors accéder aux fonctionnalités du noyau dont il a besoin
- Hellwig estime que NVIDIA a modifié son code pour utiliser cette méthode de contournement
Ce que change la nouvelle série de patchs
- Hellwig a proposé une série de patchs pour reboucher cette faille, puis en a soumis une version révisée
- Le changement central consiste à modifier le comportement de
symbol_get()- Si le symbole recherché n’est pas marqué GPL-only, la recherche échoue
- C’est l’inverse de la vérification habituelle, qui refuse normalement l’accès aux symboles marqués GPL-only
- La raison est que
symbol_get()est à l’origine une fonctionnalité destinée à une coopération bas niveau dans les profondeurs du noyau, où l’on s’attend à ce que tout soit GPL-only - Certains usages existants dans le noyau visaient des symboles qui n’étaient pas marqués GPL-only
- La série de patchs inclut aussi des changements pour marquer ces symboles en GPL-only
Impact attendu et limites
- Cette modification de
symbol_get()rend impossible pour un module noyau sous licence GPL de résoudre, viasymbol_get(), des symboles internes d’un module propriétaire - Si ce changement entre dans une version mainline puis descend jusqu’aux distributions, les développeurs de modules propriétaires devront chercher d’autres moyens d’obtenir les accès internes au noyau dont ils ont besoin
- Comme le mainteneur des modules, Luis Chamberlain, a appliqué ce changement, ses chances d’arriver dans la branche principale semblent assez bonnes
- Ce conflit dure depuis longtemps, et il est loin d’être improbable que les auteurs de modules propriétaires trouvent encore d’autres façons de contourner les intentions de la communauté du noyau
- Qu’ils soient propriétaires ou non, les modules s’exécutent dans l’espace d’adressage du noyau
- La surface d’attaque disponible pour contourner la politique d’accès aux symboles du noyau est vaste
- Il est difficile de protéger complètement cette zone
- En pratique, le mieux que l’on puisse faire est de continuer à rendre la vie inconfortable aux distributeurs de modules noyau binaires afin de les pousser à produire des solutions sous licence libre
- Cette approche n’est pas parfaite, mais elle s’est souvent révélée efficace au fil des années
1 commentaires
Avis sur Hacker News
Le code de l’éditeur de liens du noyau Linux a été conçu pour imposer l’interprétation de Linus Torvalds sur la manière dont la GPL et l’exception des appels système doivent fonctionner ; il semble donc y avoir une marge juridique pour soutenir que Nvidia a contourné une mesure de protection du droit d’auteur (DMCA 1201).
Linus ne le ferait probablement pas en pratique, et ce serait assez terrible pour tout l’écosystème FOSS, mais vu ce que Nvidia a fait jusqu’ici, j’aimerais presque voir ça au moins une fois.
Si même Linux, le gorille de 800 livres dans la pièce, n’a pas la volonté d’aller au tribunal, les perspectives ne semblent pas très bonnes pour les autres projets.
Si Linux se contente d’exercer une pression technique « douce » face aux violations flagrantes de licence et de droit d’auteur par les grandes entreprises, on peut aussi se dire qu’il vaut mieux considérer que la GPL est finie et passer à quelque chose comme BSD3 ou MIT+Apache.
LLVM n’utilise pas de copyleft fort et pousse à la coopération avec l’amont par des moyens purement techniques, comme les changements d’API et un rythme de développement très rapide ; cela fonctionne plutôt bien sans diluer la licence choisie.
Une contre-action susceptible de porter réellement atteinte aux opportunités commerciales de Nvidia pourrait constituer un bon moyen de dissuasion contre de futurs problèmes.
En substance : « symbol_get était à l’origine destiné uniquement à des modules étroitement coordonnés utilisant des symboles très internes ; il est donc logique de le limiter à EXPORY_SYMBOL_GPL et d’éviter à Nvidia un coûteux procès pour contournement de mesures de contrôle d’accès au titre du DMCA ». C’est une très belle pique contre Nvidia, qui ignore ostensiblement l’intention et les égards qu’on lui accorde pour faire ce qu’elle veut.
On peut toujours rêver :)
[1]: https://www.youtube.com/watch?v=tQIdxbWhHSM
Linus n’a pas de pouvoir particulier à cet égard.
Le commentaire laissé par l’auteur de ce patch est vraiment inhabituel.
https://lore.kernel.org/lkml/20230731083806.453036-6-hch@lst...
Il y est écrit, en substance, que « symbol_get était à l’origine destiné uniquement à des modules étroitement coordonnés utilisant des symboles très internes ; il est donc logique de le limiter à EXPORY_SYMBOL_GPL et d’éviter à nvidia un coûteux procès pour contournement de mesures de contrôle d’accès au titre du DMCA ».
C’est littéralement une tentative de revendiquer, pour le noyau Linux qui est un projet open source, la protection des dispositions anti-contournement du DMCA, qui rendent illégal le contournement des DRM.
Cela revient aussi à reconnaître implicitement qu’EXPORT_SYMBOL_GPL est clairement un système de DRM.
Personnellement, je n’aime pas NVIDIA et je n’ai pas spécialement envie de défendre son comportement, mais je trouve surprenant que le projet Linux affirme que les lois anti-contournement des DRM s’appliquent aussi aux projets open source.
C’est l’une des lois auxquelles la communauté open source s’oppose presque universellement, et tout système de DRM semble assez contraire aux valeurs du FOSS.
L’objectif central de la GPL a toujours été d’utiliser le droit d’auteur contre le droit d’auteur, autrement dit le copyleft.
Plus le droit d’auteur se renforce, plus la protection de la GPL se renforce aussi ; utiliser des dispositions supplémentaires du droit d’auteur pour protéger les logiciels open source me paraît donc tout à fait conforme à l’esprit de la GPL.
La GPL n’est pas une licence permissive, mais une licence à copyleft fort, et elle dispose d’une véritable force d’exécution.
Le mécanisme de contamination n’est pas hypocrite : il est open source, et si le code est sous GPL, vous pouvez en faire ce que vous voulez.
C’est littéralement un dispositif qui impose la clause de liaison de la licence GPL.
Quand il faut s’en servir, il faut s’en servir ; cela ne me paraît donc pas du tout étrange.
Si quelqu’un a fait quelque chose de louche et qu’on lui permet de sauver la face aussi doucement, il a de la chance.
Des DRM destinés à empêcher l’appropriation abusive de la GPL semblent être l’étape suivante logique.
Je ne vois pas pourquoi des pilotes propriétaires ne devraient pas interagir avec un noyau libre
Linux implémente littéralement un DRM au niveau du noyau, exactement ce que le logiciel libre avait juré de détruire
À tout le moins, l’exigence empêchant les pilotes propriétaires d’interagir avec du code réservé à la GPL ressemble, de mon point de vue, à un EULA
S’il n’y avait eu que la GPLv2, les modules propriétaires auraient probablement constitué une violation
Mais comme Linus a explicitement indiqué que les appels système ne déclenchent pas le copyleft de la GPL, les symboles du noyau correspondant à des appels système ne le déclenchent pas non plus
Donc, pour éviter une violation de licence selon l’interprétation par Linus de l’exception à la GPL, il faut un chargeur qui consulte les données de licence pour déterminer quels symboles peuvent être liés ou non
C’est bien un DRM au niveau du noyau[0], et Linus pourrait peut-être avancer un argument juridique contre le contournement par Nvidia de cette protection contre la copie
La GPLv3 rejette explicitement toute protection contre la copie dans le code couvert, ce qui pourrait en théorie empêcher ce type de procès, mais cette clause n’a pas été testée devant les tribunaux, et Linus déteste particulièrement la GPLv3 parce qu’elle a ajouté la clause TiVo[1]
Cette fonctionnalité a été implémentée il y a des décennies, et l’objectif initial était d’éviter de recevoir des rapports de bugs indiquant que le noyau Linux plantait à cause de modules propriétaires impossibles à corriger
L’application de la GPL était un effet secondaire
[0] À ne pas confondre avec l’autre DRM dans le noyau, le Direct Rendering Manager
[1] Ce n’est pas tant la clause TiVo elle-même qu’il déteste, mais le fait d’ajouter rétroactivement des conditions à des logiciels en v2 et de modifier les termes de l’échange. Parce que cela lui donne l’impression que Linux est en train d’être accaparé par la FSF
Ils doivent simplement n’utiliser que des fonctionnalités assez générales de système d’exploitation, qu’on retrouve dans plusieurs noyaux similaires
Un tel pilote, qui ne dépend pas de fonctionnalités propres à Linux, ne peut pas être considéré comme une « œuvre dérivée » du noyau Linux et peut donc choisir la licence qu’il veut
À l’inverse, un pilote qui utilise des interfaces propres au noyau Linux, absentes des autres systèmes d’exploitation, y compris d’autres noyaux de type Unix, est par définition plus proche d’une « œuvre basée sur le programme » du noyau, et devrait donc être licencié de façon similaire
Il suffit de regarder le texte de la GPL-2 que suit le noyau
https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
La LGPL existe séparément pour autoriser le lien séparé entre logiciel libre et logiciel propriétaire, ce que la GPL interdit
Mais Linux étant sous GPL-2, cette autorisation supplémentaire ne s’applique pas
Si le pilote Nvidia n’utilisait que des API génériques du noyau, ce serait acceptable, mais en pratique ce n’est pas le cas
Comme il tente d’utiliser, sans être sous GPL, des API spécifiques à Linux marquées comme destinées à des pilotes sous licence compatible GPL, c’est une violation manifeste de la licence de logiciel libre sous laquelle Linux est fourni
Pourquoi le logiciel propriétaire devrait-il profiter de tous les avantages du logiciel libre sans suivre aucune règle, tandis que le logiciel libre devrait simplement l’accepter ?
Même les sociétés démocratiques disposent de mécanismes qui restreignent dans une certaine mesure l’expression afin de se protéger
Il existe déjà beaucoup de systèmes d’exploitation propriétaires, et ils ne se soucient absolument pas de cela
Est-il interdit qu’il existe aussi des systèmes d’exploitation qui se soucient de ces principes ? Tout doit-il forcément être un outil froid et favorable à l’industrie, sans considération humaine ?
L’intention de la licence est que tout ce qui est lié au noyau et chargé dans celui-ci soit distribué sous une licence copyleft compatible
L’exigence selon laquelle du code propriétaire ne doit pas « inclure » du code GPL, c’est la GPL elle-même, et c’est son objectif central
Cela dit, la question de savoir dans quelle mesure le simple fait de lier une API constitue une violation reste discutable
Une décision dans un sens comme dans l’autre semble possible, et un tel jugement aurait un impact important sur la GPL
Comme le code Nvidia tourne en ring0, d’expérience, Nvidia dispose de manœuvres bien plus intéressantes qu’il pourrait utiliser, mais il se retient probablement pour l’instant
Les développeurs Linux aussi
Cette stupide bataille de DRM n’aide personne et ne fait qu’encourager un jeu du chat et de la souris qui fait perdre du temps à tout le monde
« Les gars, essayez de bien vous entendre »
Je ne comprends pas pourquoi Nvidia consacre autant d’efforts à maintenir ses pilotes sous forme de gros blob binaire propriétaire
Le logiciel n’est pas vraiment le cœur de leur défense concurrentielle, et Nvidia est une entreprise de matériel
Ouvrir le module noyau n’aurait non seulement aucun impact sur les ventes de matériel, mais améliorerait aussi la stabilité et leur vaudrait la sympathie des développeurs qui se détournent volontairement vers des GPU AMD
Parce que la banalisation est l’exact opposé de marges élevées
Avec environ 80 % du marché des GPU, pour augmenter encore les marges il est plus facile soit de facturer plus cher, soit de contrôler des couches plus élevées de toute la pile
Par exemple, il est avantageux que les principaux langages GPU généralistes soient conçus autour de l’architecture de ses propres GPU
Ou alors il faut s’étendre dans des domaines complètement différents, et si Nvidia se lance aussi fortement dans l’IA, c’est parce qu’elle peut exploiter sa domination dans les GPU pour y obtenir un avantage précoce
Mais je n’ai aucune preuve
Ce qui est « illégal » reste purement théorique tant que cela n’a pas été prouvé devant un tribunal
Ce dont il est question ici, c’est essentiellement d’un DRM dans le code du noyau, destiné à empêcher les modules noyau chargeables de deviner où se trouvent en mémoire les structures de données du noyau
Sachant que des gens tenteront probablement de repousser les limites, l’idée est de rendre cela aussi difficile que possible à titre de mesure dissuasive
Mais on pourrait aussi soutenir que tous les modules noyau chargeables à source fermée violent la GPL de la même manière, avec ou sans « shim » ; cet argument a d’ailleurs déjà été avancé, mais la plupart l’ont oublié et utilisent cette fiction de DRM comme substitut à une fiction juridique
Ou bien, si les fonctions marquées GPL dans le noyau relèvent d’une API au sens de l’affaire Google contre Oracle, toute cette discussion n’a peut-être pas grand intérêt
La plupart des modules noyau chargeables se trouvent dans l’arborescence des sources du noyau et sont fournis sous licence GPL
L’étape suivante consiste à créer un module chargeable open source contenant une petite machine virtuelle qui charge un bloc binaire en mode utilisateur
Elle n’exécuterait que les blocs binaires signés avec la clé privée détenue par NVIDIA, tandis que la clé publique serait incluse dans le module open source
Ou alors créer un hyperviseur qui virtualise Linux pour contourner la majeure partie du noyau…
Il y a toujours une méthode
Cela ne fait que rendre les choses pénibles et augmenter le coût d’obtention de bons pilotes pour Linux, donc les efforts investis dans ce domaine diminueront
Il n’est pas évident que ce soit une grande perte
J’espère que cette bataille ne finira pas par faire disparaître les pilotes Nvidia pour Linux, ou par les rendre pires
Sans ces pilotes, mon système d’exploitation préféré devient soudain moins utile à cause des jeux et de l’IA
Il y a dix ans, c’était différent
À l’époque, cela concernait surtout une petite minorité de geeks Linux qui voulaient jouer sous Linux, et ils représentaient une faible part du chiffre d’affaires
Aujourd’hui, pratiquement toute la valorisation de NVIDIA repose sur l’IA, et presque tous les grands acteurs qui achètent massivement ce matériel l’utilisent sous Linux
Pour NVIDIA, couper les ponts avec Linux n’est pas une option
Ils feront probablement tout pour éviter que cela arrive
Supprimer toute prise en charge de nVidia jusqu’à ce que ce soit ouvert
Mais aujourd’hui, ce sont les entreprises commerciales, plus que nous, qui ont davantage voix au chapitre sur la manière dont le matériel est utilisé et pris en charge sous Linux
Nvidia a publié en open source ses pilotes, ou une partie d’entre eux, et fournit désormais aussi des binaires de firmware redistribuables
De plus, l’authentification du firmware a été cassée sur certaines anciennes cartes
J’espère donc qu’avec le temps, l’importance des pilotes propriétaires diminuera
Au niveau du noyau, on en est donc arrivé à « quelle est la couleur de tes bits »[1]… pas mal ?
[1] https://ansuz.sooke.bc.ca/entry/23