Christoph Hellwig, een prominente Linux-kernelontwikkelaar die ooit lid was van de technische stuurgroep van de Linux Foundation en die een GPL-rechtszaak tegen VMware heeft aangespannen.
Hij heeft voorgesteld de beveiligingen aan te scherpen tegen koppelverkoop eigen stuurprogramma's naar geëxporteerde Linux-kernelcomponenten alleen voor modules die zijn gelicentieerd onder de GPL.
Om beperking te vermijden om GPL-symbolen te exporteren, eigen controllerfabrikanten gebruiken een laagmodule, waarvan de code open source is en wordt verspreid onder de GPLv2-licentie, maar de functies komen neer op het doorgeven van de toegang van de eigenaarcontroller tot de API's kernelbestanden, waarvan het gebruik rechtstreeks vanuit de eigen code is verboden.
Om zo'n manoeuvre te blokkeren, Christoph Helwig heeft patches voorbereid voor de Linux-kernel die overerving garanderen van de vlaggen die zijn gekoppeld aan de export van GPL-symbolen.
We hebben sinds de eerste dag een fout opgetreden in onze _GPL-module-resolutie,
dat wil zeggen, een module kan claimen GPL-gelicentieerd te zijn en _GPL-exports gebruiken, terwijl hij ook vertrouwt op niet-GPL-modulesymbolen. Dit wordt gebruikt als een omzeiling van _GPL-exports door een kleine shim-module te gebruiken die _GPL-exports en andere functionaliteit gebruikt.
Het voorstel komt neer op het erven van de indicator TAINT_PROPRIETARY_MODULE in alle modules die modulesymbolen importeren met deze vlag.
Daarom, als een GPL-middenlaagmodule symbolen probeert te importeren van een niet-GPL-module, zal de GPL-module de TAINT_PROPRIETARY_MODULE-tag erven en zal hij geen toegang hebben tot de kernelcomponenten die alleen beschikbaar zijn voor GPL-gelicentieerde modules, zelfs als de module eerder is geïmporteerd symbolen van "gplonly".
Hellwig's patch probeert dit nu moeilijk te maken. Modules die propriëtaire symbolen importeren, zijn gemarkeerd als propriëtair en hebben geen toegang tot GPL-symbolen.
De wijziging werd voorgesteld als reactie op een reeks vrijgegeven patches door een Facebook-engineer met de implementatie van een nieuw netgpu-subsysteem, dat directe gegevensuitwisseling (zero copy DMA) tussen de netwerkkaart en de GPU mogelijk maakt, terwijl de protocolverwerking door de CPU wordt uitgevoerd.
Dit zou de methode vermijden die oorspronkelijk was gepland door Jonathan Lemon voor uw patches en zou ervoor zorgen dat de ontwikkeling van de tussenlagen het GPL-symbool weglaat veel moeilijker zijn, zelfs als er nog een kleine opening is, zoals aangegeven.
In de discussie die ze momenteel voeren verschillende Linux-kernelontwikkelaars omgekeerd blokkeren werd voorgesteld: Als een module EXPORT_SYMBOL_GPL-symbolen importeert, mogen de symbolen die door die module worden geëxporteerd, niet worden geïmporteerd door modules die niet expliciet aanspraak maken op GPL-compatibiliteit.
Degenen zonder een module importeren EXPORT_SYMBOL_GPL-symbolen, al hun geëxporteerde symbolen moeten worden behandeld als EXPORT_SYMBOL_GPL.
Christoph Helwig schreef dat hij het 100% eens is met dit voorstel, maar Linus Torvalds zal die wijziging niet missen, omdat hierdoor de meeste kernelsubsystemen niet beschikbaar zijn voor propriëtaire stuurprogramma's, vanwege het feit dat bij het ontwikkelen van stuurprogramma's de basissymbolen worden geëxporteerd onder de GPL
De ontwikkelaars waren niet tevreden met de beschikbaarheid van de implementatie alleen voor de eigen NVIDIA-stuurprogramma's via de GPL-laag die door deze stuurprogramma's wordt geleverd.
Als reactie op kritiek, de auteur van de patch gaf aan dat het subsysteem niet is gekoppeld aan NVIDIA en de ondersteuning ervan kan onder andere worden geleverd voor software-interfaces voor AMD- en Intel-GPU's.
Als gevolg hiervan werd de promotie van netgpu in de kernel onmogelijk geacht totdat er werkende ondersteuning beschikbaar was op basis van gratis stuurprogramma's zoals AMDGPU, Intel i915 of Nouveau.
Dat moet je in het verleden onthouden, heeft de Linux-kernelgemeenschap verschillende veranderingen doorgevoerd dat bewust of als bijwerking, hebben de ontwikkeling van propriëtaire modules belemmerd of niet compatibel met licenties.
Eindelijk als je er meer over wilt wetenkunt u de details bekijken door te gaan naar de volgende link.
bron: https://lkml.org/
Misschien is het beter om het artikel in het Engels te plaatsen in plaats van een vertaler te gebruiken. Er zijn veel onderdelen die voor mij onbegrijpelijk zijn.