Proposal for Blocking Driver Interfaces Providing Access to GPL Kernel Calls

Christoph Hellwig, a renowned Linux kernel developer who was once a member of the technical oversight committee at the Linux Foundation and served as a plaintiff in a case related to GPL litigation against VMware, proposed which aims to tighten the protection against linking proprietary drivers with Linux kernel components that are exported only for modules under the GPL license. To bypass the restriction on exporting GPL symbols, proprietary driver manufacturers use a wrapper module, the code of which is open and distributed under the GPLv2 license, but its functions are limited to relaying access from the proprietary driver to the necessary kernel APIs that are prohibited for direct use from proprietary code.

To block such maneuvers, Christoph Hellwig prepared has proposed patches for the Linux kernel that ensure the inheritance of flags related to exporting GPL symbols. The proposal involves inheriting the TAINT_PROPRIETARY_MODULE flag in all modules that import symbols from modules marked with this flag. Thus, if a GPL wrapper module attempts to import symbols from a non-GPL module, the GPL module will inherit the TAINT_PROPRIETARY_MODULE label and will not be able to access kernel components available only to modules under the GPL license, even if the module had previously imported symbols from the 'gplonly' category.

During the discussion, there was also a proposal for reverse blocking — if a module imports EXPORT_SYMBOL_GPL symbols, any symbols exported by this module should not be imported by modules that do not explicitly state compatibility with GPL. That is, if a module imports EXPORT_SYMBOL_GPL symbols, all its exported symbols should be treated as EXPORT_SYMBOL_GPL. Christoph Hellwig , stated that he fully agrees with this proposal, but such a change will not pass Linus Torvalds, as it would render most of the kernel subsystems inaccessible to proprietary drivers because fundamental symbols exported under GPL are used in driver development. wroteThe change was proposed in response to

an engineer from Facebook's series of patches implementing a new netgpu subsystem that allows direct data exchange (DMA publication zero-copy) between the network card and GPU, while processing the protocol with CPU resources.
Dissatisfaction among developers was caused by the proposed changes. availability implementations only for proprietary NVIDIA drivers through the GPL layer provided by those drivers. In response to criticism the author of the patches indicated, which means that the subsystem is not tied to NVIDIA and its support could also be provided for software interfaces to AMD and Intel GPUs. As a result, the promotion of netgpu into the kernel was deemed impossible until working support based on free drivers, such as AMDGPU, Intel i915, or Nouveau, becomes available.

Source: opennet.ru