建议阻止提供对Linux内核的GPL调用的访问权限的驱动程序

克里斯托夫·海尔维格（Christoph Hellwig） 一位著名的Linux内核开发人员，他曾经是Linux基金会技术指导委员会的成员，并在针对VMware的GPL诉讼中提起诉讼。

他建议加强保护措施 反对绑 专有驱动程序 导出Linux内核组件 仅适用于根据GPL许可的模块。

为了避免限制 导出GPL符号， 专有控制器制造商使用分层模块， 其代码是开源的，并根据GPLv2许可进行分发， 但是功能归结为将所有者控制器访问权传递给API 内核文件，专有代码直接禁止使用这些文件。

为了阻止这种动作， Christoph Helwig为Linux内核准备了可确保继承的补丁 与GPL符号导出相关的标志。

从第一天开始，我们的_GPL模块解析就有错误，
也就是说，一个模块可以声称已获得GPL许可并使用_GPL导出，同时还依赖于非GPL模块符号。 通过使用使用_GPL导出功能和其他功能的小型填充程序模块，可以将其用作_GPL导出的规避方法。

提案归结为继承指标 TAINT_PROPRIETARY_MODULE 在所有使用此标志导入模块符号的模块中。

因此，如果GPL中间层模块尝试从非GPL模块导入符号，则GPL模块将继承TAINT_PROPRIETARY_MODULE标签，并且即使先前导入的模块也无法访问仅GPL许可模块可用的内核组件。来自“ gplonly”的符号。

Hellwig的补丁程序现在正试图解决这个问题。 导入专有符号的模块被标记为专有，并且无法访问GPL符号。 

提出此更改是为了响应发布的一系列补丁 由一名Facebook工程师实施了一个新的netgpu子系统，该子系统允许在网卡和GPU之间进行直接数据交换（零复制DMA），同时由CPU执行协议处理。

这样可以避免Jonathan Lemon最初计划的方法 为您的补丁程序，并会使得中间层的开发省略GPL符号 困难得多，即使仍然有很小的差距，如所示。

在讨论中，他们目前有 各种Linux内核开发人员 建议反向封锁： 如果模块导入EXPORT_SYMBOL_GPL符号，则该模块导出的符号不应由未明确要求GPL兼容性的模块导入。

那些不带模块的组件将导入EXPORT_SYMBOL_GPL符号，所有其导出的符号都应视为EXPORT_SYMBOL_GPL。

克里斯托夫·海尔维格（Christoph Helwig）写道，他100％同意该建议， 但是Linus Torvalds不会错过这一更改，因为它将使大多数内核子系统对专有驱动程序不可用，这是因为在开发驱动程序时，基本符号是根据GPL导出的

对于仅通过专有驱动程序提供的GPL层为专有NVIDIA驱动程序提供的实现，开发人员并不满意。

为了回应批评， 该补丁的作者指出该子系统未链接到NVIDIA 除了其他功能外，它还可以为AMD和Intel GPU的软件接口提供支持。

结果，在无法获得基于免费驱动程序（例如AMDGPU，Intel i915或Nouveau）的工作支持之前，无法在内核中提升netgpu。

你要记得过去，Linux内核社区拥有 实施了各种变更 有意地或作为副作用， 阻碍了专有模块的开发 或与许可证不兼容。

最后 如果您想了解更多，您可以通过以下方式查看详细信息： 到以下链接。

数据来源： https://lkml.org/