- La comunidad del kernel de Linux ha visto con recelo desde hace mucho tiempo a los módulos propietarios del kernel, y el parche de Christoph Hellwig es una medida para volver a estrechar esa vía de escape
- En lugar de prohibir directamente la carga de módulos propietarios, el kernel permite que algunos símbolos del kernel sean accesibles solo a módulos compatibles con GPL mediante los GPL-only exports
- En 2020 se hizo visible el método GPL condom, en el que un módulo GPL conectaba un módulo propietario con el kernel, y después se cambió el comportamiento para que los módulos que usan símbolos propietarios también fueran tratados como propietarios
- La nueva vía de escape usa
symbol_get()para obtener la dirección de símbolos internos de un módulo propietario sin pasar por el procedimiento normal de importación, y Hellwig considera que NVIDIA cambió su código para usar este método - El parche propuesto hace que
symbol_get()falle al buscar símbolos que no sean GPL-only, bloqueando esa evasión, aunque sigue siendo difícil hacer que el control de acceso sea completamente seguro mientras los módulos se ejecuten en el espacio de direcciones del kernel
Antigua tensión en torno a los módulos propietarios del kernel
- La comunidad del kernel de Linux no ha tenido una relación fluida con los proveedores de módulos propietarios del kernel
- Estos módulos son difíciles de depurar o corregir para cualquiera que no sea su creador
- Muchos desarrolladores los consideran una infracción de la licencia del kernel y del copyright del código
- Aun así, los módulos propietarios se han permitido dentro de ciertos límites
- El parche reciente de Christoph Hellwig es un intento de reducir un poco más ese margen permitido
El intento de prohibir la carga en 2006 y los GPL-only exports
- En 2006 hubo un intento breve de prohibir por completo la carga de módulos propietarios del kernel
- Linus Torvalds frenó ese intento por varias razones
- Cargar simplemente un módulo propietario en el kernel de Linux no constituye por sí mismo una infracción de copyright
- Los usuarios de Linux pueden hacer eso
- Torvalds consideró que una prohibición así podría verse como una señal de mayor interés en disputas de licencia que en mejoras técnicas
- La distribución de módulos propietarios sí puede constituir una infracción de copyright si ese módulo es una obra derivada del código del kernel
- Pero determinar si es una obra derivada es ambiguo, y al kernel le resulta difícil hacer ese juicio en la práctica
- El kernel cuenta desde hace tiempo con los GPL-only exports como mecanismo para bloquear módulos potencialmente infractores
- Los módulos del kernel necesitan acceder a funciones exportadas por el kernel y a símbolos de estructuras de datos para poder hacer trabajo útil
- Muchos símbolos solo se permiten a módulos que declaran una licencia compatible con GPL
- Este método mantiene a los módulos propietarios alejados de una parte importante de la funcionalidad del kernel
La intención de la marca GPL-only y la realidad
- En teoría, la marca GPL-only significa que cierto símbolo está profundamente acoplado al interior del kernel, por lo que el código que lo use sería necesariamente una obra derivada del kernel
- En la práctica, los desarrolladores no hacen ese análisis legal
- Por lo general, ni siquiera están calificados para hacerlo
- En la realidad, marcar símbolos como GPL-only se usa con frecuencia como una forma de dificultar más el uso general de módulos propietarios
La vía de evasión con intermediario que salió a la luz en 2020
- Los desarrolladores de módulos propietarios llevan mucho tiempo buscando formas de esquivar las restricciones de los GPL-only exports
- Una opción es declarar falsamente una licencia compatible con GPL, pero como eso parece una admisión evidente de conducta incorrecta, las empresas tienden a evitarlo instintivamente
- Una forma más sutil salió a la luz en 2020 durante una serie de parches relacionados con DMA peer-to-peer
- En esa estructura, un módulo que declara una licencia compatible con GPL actúa como intermediario
- Ese módulo puede acceder a todos los símbolos exportados por el kernel
- Luego importa los símbolos del módulo propietario, permitiendo que el código propietario acceda a la funcionalidad del kernel que necesita
- Esto es una variante de lo que suele llamarse GPL condom
El parche de respuesta de 2020
- En ese momento, Hellwig integró un parche para dificultar más este método
- En el kernel actual, un módulo que usa símbolos de un módulo propietario también se considera propietario
- Pierde de inmediato la capacidad de acceder a símbolos GPL-only
- Si intenta importar símbolos de un módulo propietario después de haber usado ya símbolos GPL-only, la operación falla
- Esta comprobación bloquea la posibilidad de que un módulo GPL actúe como intermediario entre un módulo propietario y el kernel
La nueva vía de evasión mediante symbol_get()
- El kernel ofrece la macro
symbol_get(), y el trabajo real lo hace__symbol_get() - Esta función busca la dirección asociada a un símbolo del kernel
symbol_get()existe en el kernel desde la versión 2.5.48 de 2002, cuando se añadió durante una gran sustitución del cargador de módulos- También tiene una limitación importante
- Solo busca símbolos proporcionados por módulos cargables
- Su propósito es manejar casos en que módulos estrechamente conectados deben evitar ciclos de referencia y contemplar la posibilidad de que uno de ellos aún no esté cargado
- A simple vista, no parece muy útil para proveedores de módulos propietarios que quieran saltarse las reglas, porque no puede usarse para localizar símbolos GPL-only del kernel
Cómo symbol_get() evade la defensa de 2020
symbol_get()puede usarse para obtener la dirección de un módulo propietario sin pasar por el mecanismo normal de importación ni por sus restricciones- Por eso, la corrección de 2020 puede volver a esquivarse
- Un módulo con licencia GPL, al menos nominalmente, puede llamar al módulo propietario
- Ese módulo propietario puede entonces acceder a la funcionalidad del kernel que necesita
- Hellwig considera que NVIDIA modificó su código para usar esta vía de evasión
Cambios de comportamiento en la nueva serie de parches
- Hellwig publicó una serie de parches para volver a cerrar este agujero, y después presentó una versión revisada
- El cambio central es modificar el comportamiento de
symbol_get()- Si el símbolo que se quiere buscar no está marcado como GPL-only, la búsqueda falla
- Es una comprobación en la dirección opuesta a la que normalmente niega el acceso a símbolos marcados como GPL-only
- La razón es que
symbol_get()fue pensado originalmente como una función para cooperación de bajo nivel en partes profundas del kernel, donde se espera que todo sea GPL-only - Algunos usos existentes dentro del kernel apuntaban a símbolos que no estaban marcados como GPL-only
- La serie de parches también incluye cambios para convertir esos símbolos en GPL-only
Impacto esperado y límites
- Este cambio en
symbol_get()hace imposible que un módulo del kernel con licencia GPL resuelva símbolos internos de un módulo propietario usandosymbol_get() - Si este cambio entra en una versión mainline y luego llega a las distribuciones, los desarrolladores de módulos propietarios tendrán que buscar otras formas de conseguir el acceso interno al kernel que necesitan
- Como el mantenedor de módulos Luis Chamberlain ya aplicó este cambio, parece bastante probable que termine entrando en mainline
- Este conflicto lleva muchos años, y no es poco probable que los autores de módulos propietarios encuentren otras formas de esquivar la intención de la comunidad del kernel
- Sean propietarios o no, los módulos se ejecutan en el espacio de direcciones del kernel
- La superficie de ataque disponible para módulos que intenten evadir las políticas de acceso a símbolos del kernel es grande
- Es difícil proteger completamente esta área
- En términos prácticos, lo mejor que se puede hacer es seguir haciendo incómoda la vida a los distribuidores de módulos del kernel solo binarios para empujarlos a crear soluciones con licencias libres
- No es un método perfecto, pero a lo largo de los años ha funcionado con frecuencia
1 comentarios
Opiniones de Hacker News
El código del enlazador del kernel de Linux fue diseñado para imponer la interpretación de Linus Torvalds sobre cómo deberían funcionar la GPL y la excepción de llamadas al sistema, así que parece haber margen legal para afirmar que Nvidia eludió una protección de derechos de autor (DMCA 1201).
Linus probablemente no haría eso en la práctica, y hacerlo sería bastante terrible para todo el ecosistema FOSS, pero viendo lo que ha hecho Nvidia todo este tiempo, también dan ganas de verlo al menos una vez.
Si ni siquiera Linux, el gorila de 800 libras en la habitación, está dispuesto a ir a tribunales, el panorama para los demás proyectos no se ve muy prometedor.
Si Linux solo va a usar presión técnica “suave” frente a violaciones descaradas de licencias y copyright por parte de grandes empresas, uno también podría pensar que la GPL ya se acabó y que sería mejor moverse hacia algo como BSD3 o MIT+Apache.
LLVM no usa copyleft fuerte y, mediante medios puramente técnicos como cambios en la API y un ritmo de desarrollo muy rápido, incentiva la cooperación con upstream; funciona bastante bien sin diluir la licencia elegida.
Una contrademanda que pueda causar un impacto real en las oportunidades de negocio de Nvidia podría funcionar bien como elemento disuasorio para evitar problemas futuros.
Dice algo como: “symbol_get originalmente estaba pensado solo para módulos que cooperan estrechamente y usan símbolos muy internos, así que tiene sentido restringirlo a EXPORY_SYMBOL_GPL y evitar que Nvidia enfrente una costosa demanda por eludir controles de acceso bajo la DMCA”; es una forma muy elegante de ironizar sobre cómo Nvidia ignora descaradamente la intención y la consideración y hace lo que quiere.
Se vale soñar :)
[1]: https://www.youtube.com/watch?v=tQIdxbWhHSM
Linus no tiene ningún poder especial.
El comentario que dejó el autor de este parche es realmente peculiar.
https://lore.kernel.org/lkml/20230731083806.453036-6-hch@lst...
Dice: “symbol_get originalmente estaba pensado solo para módulos que cooperan estrechamente y usan símbolos muy internos, así que tiene sentido restringirlo a EXPORY_SYMBOL_GPL y evitar que nvidia enfrente una costosa demanda por eludir controles de acceso bajo la DMCA”.
Esto es, literalmente, un intento de invocar para el kernel de Linux, que es un proyecto open source, la protección de las disposiciones antielusión de la DMCA, que ilegalizan la elusión de DRM.
Al mismo tiempo, también equivale a admitir implícitamente que EXPORT_SYMBOL_GPL es claramente un sistema DRM.
Personalmente no me gusta NVIDIA y no tengo mucho interés en defender su conducta, pero me sorprende que el proyecto Linux afirme que las leyes antielusión de DRM también aplican a proyectos open source.
Es una de las leyes a las que la comunidad open source se opone casi universalmente, y cualquier sistema DRM parece bastante contrario a los valores del FOSS.
El objetivo central de la GPL siempre fue usar la ley de copyright contra la propia ley de copyright, es decir, el copyleft.
Cuanto más fuerte se vuelve la ley de copyright, más fuerte se vuelve también la protección de la GPL, así que usar legislación adicional de copyright para proteger el software open source me parece bastante alineado con el espíritu de la GPL.
La GPL no es una licencia permisiva, sino una licencia de copyleft fuerte, y tiene capacidad real de aplicación.
El mecanismo de contaminación no es hipocresía, es open source, y si el código está bajo GPL, puedes hacer lo que quieras.
Es, literalmente, un mecanismo para hacer cumplir la cláusula de enlace de la licencia GPL.
Cuando hace falta, hay que usarla, así que no me parece nada extraño.
Si alguien hizo algo sospechoso y aun así le permiten salvar las apariencias de manera tan suave, tiene suerte.
El DRM para impedir la apropiación indebida de la GPL parece el siguiente paso lógico.
No entiendo por qué los controladores propietarios no deberían interactuar con un kernel libre.
Linux está implementando literalmente DRM a nivel del kernel, justo aquello que el software libre juró destruir.
Al menos, la exigencia de impedir que los controladores propietarios interactúen con código exclusivo de GPL me parece, desde mi punto de vista, más cercana a un EULA.
Si solo existiera GPLv2, los módulos propietarios probablemente serían una infracción.
Pero como Linus dejó claro que las llamadas al sistema no activan el copyleft de la GPL, los símbolos del kernel que correspondan a llamadas al sistema tampoco activan el copyleft de la GPL.
Por eso, para evitar una violación de licencia según la interpretación de Linus de la excepción de la GPL, se necesita un cargador que revise los datos de licencia para saber qué símbolos se pueden enlazar y cuáles no.
Esto sí es DRM a nivel del kernel[0], y Linus podría incluso tener margen para presentar un argumento legal contra la elusión de la protección anticopia por parte de Nvidia.
GPLv3 rechaza explícitamente cualquier protección anticopia dentro del código cubierto, así que en teoría podría impedir una demanda de este tipo, pero esa cláusula no ha sido probada en tribunales, y a Linus le disgusta especialmente GPLv3 por haber agregado la cláusula TiVo[1].
Esta función se implementó hace décadas, y el objetivo original era no recibir reportes de bugs de que el kernel de Linux se crasheaba por módulos propietarios que no se podían arreglar.
La aplicación de la GPL fue un efecto secundario.
[0] No debe confundirse con otro DRM dentro del kernel: Direct Rendering Manager.
[1] Más que disgustarle la cláusula TiVo en sí, le disgusta que se agreguen condiciones de forma retroactiva al software v2 y se cambien los términos del trato. Porque se siente como si la FSF se estuviera apoderando de Linux.
Solo que deben usar funciones de sistema operativo bastante generales, de las que se encuentran en varios kernels similares.
Un controlador que no dependa de funciones específicas de Linux no puede considerarse una “obra derivada” del kernel de Linux, así que puede elegir la licencia que quiera.
En cambio, un controlador que usa interfaces específicas del kernel de Linux que no existen en otros sistemas operativos, ni siquiera en otros kernels tipo Unix, por definición se parece más a una “obra basada en el programa” del kernel y, por lo tanto, debería licenciarse de una manera similar.
Basta ver el texto de GPL-2 que sigue el kernel.
https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
La LGPL existe por separado para permitir el enlazado separado entre software libre y software propietario; en la GPL eso está prohibido.
Pero como Linux es GPL-2, esa autorización adicional no aplica.
Si el controlador de Nvidia usara solo APIs generales del kernel, estaría bien, pero en la práctica no es así.
Como intenta usar APIs específicas de Linux, marcadas para ser usadas por controladores con licencias compatibles con la GPL, sin estar bajo GPL, eso es una violación clara de la licencia de software libre bajo la cual se distribuye Linux.
¿Por qué el software propietario debería disfrutar de todos los beneficios del software libre sin seguir ninguna regla, y el software libre simplemente tendría que aguantarse?
Las sociedades democráticas también tienen mecanismos que limitan en cierta medida la expresión para protegerse a sí mismas.
Ya hay muchos sistemas operativos propietarios, y a esos no les importa nada de esto.
¿No puede haber también sistemas operativos a los que sí les importen esos principios? ¿Todo tiene que ser una herramienta fría y favorable a la industria, sin consideración humana?
La intención de la licencia es que todo lo que se enlace y se cargue en el kernel se distribuya bajo una licencia copyleft compatible.
La exigencia de que el código propietario no “incluya” código GPL es la GPL misma, y es el propósito central de la GPL.
Dicho eso, hay margen de disputa sobre hasta qué punto enlazar simplemente contra una API constituye una infracción.
Parece posible una decisión en cualquiera de los dos sentidos, y una determinación así tendría un gran impacto en la GPL.
Como el código de Nvidia corre en ring0, por experiencia Nvidia tiene muchos trucos más interesantes que podría usar, aunque probablemente ahora se esté conteniendo.
Lo mismo vale para los desarrolladores de Linux.
Esta tonta pelea de DRM no ayuda a nadie y solo fomenta más un juego del gato y el ratón que les hace perder el tiempo a todos.
“Chicos, llévense bien”.
No entiendo por qué Nvidia se esfuerza tanto en mantener sus controladores como un bloque binario propietario.
El software ni siquiera es el núcleo de su ventaja defensiva; Nvidia es una empresa de hardware.
Abrir el módulo del kernel no solo no afectaría sus ventas de hardware, sino que mejoraría la estabilidad y hasta les ganaría simpatía entre los desarrolladores que hoy se desvían a propósito para comprar GPUs AMD.
La comoditización es lo opuesto a los márgenes gruesos.
Con alrededor del 80% del mercado de GPU, si quiere aumentar aún más sus márgenes, le resulta más fácil cobrar precios más altos o controlar capas superiores de todo el stack.
Por ejemplo, le conviene que el principal lenguaje de GPU de propósito general esté diseñado en torno a su propia arquitectura de GPU.
O, si no, tiene que expandirse a un área completamente distinta, y Nvidia también se está lanzando con fuerza a la IA porque puede aprovechar su dominio en GPU para conseguir una ventaja inicial en ese campo.
Pero no tengo pruebas.
Que algo sea “ilegal” no deja de ser una teoría hasta que se demuestre en un tribunal.
De lo que se habla aquí es, en esencia, de DRM dentro del código del kernel: intentar impedir que los módulos de kernel cargables puedan adivinar en qué parte de la memoria están las estructuras de datos del kernel.
Como saben que la gente probablemente va a intentar llevar las cosas al límite, quieren hacerlo lo más difícil posible como medida disuasoria.
Pero también se podría argumentar que todos los módulos de kernel cargables de código cerrado violan la GPL por igual, con o sin “shim”; de hecho, ese argumento ya se ha planteado, pero la mayoría lo ha olvidado y usa esta ficción del DRM como sustituto de una ficción legal.
O quizá, si las funciones etiquetadas como GPL dentro del kernel son una API en el sentido del caso Google vs. Oracle, toda esta discusión no tenga mucho sentido.
La mayoría de los módulos de kernel cargables están en el árbol de código fuente del kernel y se distribuyen bajo la GPL.
El siguiente paso sería crear un módulo cargable open source que incluya una pequeña máquina virtual que cargue un bloque binario en modo usuario.
Algo como ejecutar solo bloques binarios firmados con una clave privada que tenga NVIDIA, e incluir la clave pública en el módulo open source.
O crear un hipervisor que virtualice Linux y esquive la mayor parte del kernel, o…
Siempre hay una forma.
Esto solo lo vuelve molesto y aumenta el costo de obtener buenos drivers para Linux, así que se reducirá el esfuerzo dedicado a eso.
No está claro que eso sea una gran pérdida.
Espero que esta pelea no termine haciendo que los drivers de Nvidia para Linux desaparezcan o empeoren.
Sin esos drivers, mi sistema operativo favorito se vuelve de repente menos útil por los juegos y la IA.
Hace 10 años era distinto.
En ese entonces les importaba sobre todo a unos pocos geeks de Linux que querían jugar en Linux, y ellos representaban una porción pequeña de los ingresos.
Hoy, prácticamente toda la valuación de NVIDIA está construida sobre la IA, y casi todos los grandes jugadores que compran ese hardware en grandes cantidades lo usan en Linux.
Para NVIDIA, abandonar Linux no es una opción.
Es muy probable que hagan lo que sea para que eso no ocurra.
eliminar todo soporte hasta que nVidia lo abra.
Pero hoy las empresas comerciales, más que nosotros, tienen más peso para decidir cómo se usa y se soporta el hardware en Linux.
Nvidia publicó como open source el driver, o parte de él, y ahora también ofrece binarios de firmware redistribuibles.
Además, en algunas tarjetas antiguas ya se rompió la autenticación del firmware.
Así que espero que, con el tiempo, la importancia del driver propietario disminuya.
A nivel de kernel, esto se convirtió en un “¿de qué color son tus bits?”[1]… ¿bien?
[1] https://ansuz.sooke.bc.ca/entry/23