Proponen bloquear los controladores que proporcionan acceso a llamadas GPL al kernel de Linux

Christoph Hellwig, un destacado desarrollador de kernel de Linux que alguna vez fue miembro del comité de dirección técnica de la Fundación Linux y demandó en un litigio de GPL contra VMware.

Ha propuesto reforzar las protecciones contra la vinculación de controladores propietarios a componentes de kernel de Linux exportados solo para módulos licenciados bajo la GPL.

Para evitar la restricción de exportar símbolos GPL, los fabricantes de controladores propietarios usan un módulo de capa, cuyo código es de código abierto y se distribuye bajo la licencia GPLv2, pero las funciones se reducen a transmitir el acceso del controlador propietario a las API de kernel necesarias, cuyo uso está prohibido directamente desde el código propietario.

Para bloquear tal maniobra, Christoph Helwig preparó parches para el kernel de Linux que aseguran la herencia de las banderas asociadas con la exportación de símbolos GPL.

Hemos tenido un error en nuestra resolución de módulos _GPL desde el primer día,
es decir, un módulo puede reclamar tener licencia GPL y usar exportaciones _GPL, mientras que también depende de símbolos de módulos que no son GPL. Esto se usa como una elusión de las exportaciones _GPL mediante el uso de un pequeño módulo de calce que utiliza las exportaciones _GPL y la otra funcionalidad.

La propuesta se reduce a heredar el indicador TAINT_PROPRIETARY_MODULE en todos los módulos que importan símbolos de módulos con este indicador.

Por lo tanto, si un módulo de capa intermedia GPL intenta importar símbolos de un módulo que no es GPL, el módulo GPL heredará la etiqueta TAINT_PROPRIETARY_MODULE y no podrá acceder a los componentes del núcleo disponibles solo para módulos con licencia GPL, incluso si el módulo importó previamente símbolos de «gplonly «.

El parche de Hellwig ahora está tratando de hacer esto difícil. Los módulos que importan símbolos propietarios están marcados como propietarios y no tienen acceso a los símbolos GPL. 

El cambio se propuso en respuesta a una serie de parches publicados por un ingeniero de Facebook con la implementación de un nuevo subsistema netgpu, que permite el intercambio directo de datos (copia cero DMA) entre la tarjeta de red y la GPU, mientras realiza el procesamiento del protocolo por parte de la CPU.

Esto evitaría el método originalmente planeado por Jonathan Lemon para sus parches y haría que el desarrollo de las capas intermedias para omitir el símbolo GPL sea mucho más difícil, incluso si todavía hay una pequeña brecha, como lo indica.

En la discusión que actualmente están tendiendo diversos desarrolladores del Kernel de Linux también se sugirió el bloqueo inverso: si un módulo importa símbolos EXPORT_SYMBOL_GPL, los símbolos exportados por ese módulo no deben importarse por módulos que no reclamen explícitamente la compatibilidad GPL.

Aquellos sin un módulo importa símbolos EXPORT_SYMBOL_GPL, todos sus símbolos exportados deben tratarse como EXPORT_SYMBOL_GPL.

Christoph Helwig escribió que está 100% de acuerdo con esta propuesta, pero Linus Torvalds no se perderá ese cambio, ya que hará que la mayoría de los subsistemas del núcleo no estén disponibles para los controladores propietarios, debido al hecho de que al desarrollar controladores, los símbolos base se exportan bajo GPL

Los desarrolladores no estaban satisfechos con la disponibilidad de la implementación solo para los controladores NVIDIA patentados a través de la capa GPL proporcionada por estos controladores.

En respuesta a las críticas, el autor del parche indicó que el subsistema no está vinculado a NVIDIA y su soporte se puede proporcionar, entre otras cosas, para interfaces de software para GPU AMD e Intel.

Como resultado, la promoción de netgpu en el núcleo se consideró imposible hasta la disponibilidad de soporte de trabajo basado en controladores gratuitos como AMDGPU, Intel i915 o Nouveau.

Hay que recordar que en el pasado, la comunidad del kernel de Linux ha implementado una variedad de cambios que, a sabiendas o como efecto secundario, han dificultado el desarrollo de módulos propietarios o no compatibles con licencias.

Finalmente si quieres conocer mas al respecto, puedes consultar los detalles dirigiéndote al siguiente enlace.

Fuente: https://lkml.org/