El núcleo Linux-libre 6.12 está disponible. Solucionados los problemas de licencia con los controladores de Tuxedo

La Fundación Latinoamericana de Software Libre ha publicado una versión completamente libre del núcleo Linux 6.12 — Linux-libre 6.12-gnu, eliminando elementos de firmware y controladores que contienen componentes no libres o fragmentos de código cuya área de aplicación está limitada por el fabricante. Además, Linux-libre desactiva las funciones del núcleo para cargar componentes externos no libres que no están incluidos en la entrega del núcleo y elimina la mención del uso de componentes no libres de la documentación.

Para limpiar el núcleo de partes no libres, el proyecto Linux-libre ha creado un script shell universal que contiene miles de plantillas para detectar la presencia de inserciones binarias y excluir falsos positivos. También están disponibles para descargar parches listos, creados a partir del uso del script mencionado anteriormente. Se recomienda el núcleo Linux-libre para su uso en distribuciones que cumplan con los criterios de la Fundación FSD para construir distribuciones completamente libres de GNU/Linux. Por ejemplo, Linux-libre se utiliza en distribuciones como Dragora Linux, Trisquel, Dyne:Bolic, gNewSense, Parabola, Musix y Kongoni.

En la versión Linux-libre 6.12-gnu se ha añadido código para limpiar blobs en controladores para SoC CPM/QE QMC, chips inalámbricos Realtek 8852BE-VT, adaptadores bluetooth Amlogic, adaptadores de red amcc qt2025, sensores aw96103/aw96105 y codecs TI TLV320AIC31XX. Se ha realizado una limpieza adicional de blobs en controladores para los controladores xHCI de Renesas e Intel ISH (Integrated Sensor Hub) HID. Se ha actualizado el código de eliminación de blobs en controladores y subsistemas MHI PCI host, Adreno 620/621, r8169, Qualcomm q6v5 remoteproc, rtw8852c, rtw8922a, así como en archivos dts para chips ARM54 TI PRU y Qualcomm. Se ha detenido la limpieza de controladores para tarjetas inalámbricas ks7010 y el subsistema de audio Intel SkyLake, ya que estos controladores han sido eliminados del núcleo.

Se destaca la identificación en los textos fuente de uno de los controladores de código objeto ejecutable, generado a partir de textos fuente no publicados e integrado en forma de una secuencia de números hexadecimales. El controlador problemático no se menciona explícitamente, pero a juzgar por los cambios, se trata de la presencia de microcódigo del shader en el archivo gfx_v9_4_3_cleaner_shader.h, que forma parte del controlador AMDGPU. La primera inserción de este tipo fue identificada en el núcleo 6.11 y luego propuesta por uno de los desarrolladores para su eliminación, ya que los textos fuente no fueron proporcionados (se generó una situación de entrega bajo la licencia GPL de un programa disponible solo en forma binaria). Sin embargo, en el núcleo 6.12, dicho código binario se mantuvo, y se añadió otra inserción similar al mismo controlador.

Además, en el anuncio de Linux-libre 6.12 se mencionan otros dos eventos:

  • Se ha propuesto una corrección para incluir en el núcleo que bloquea el acceso de los controladores para ordenadores portátiles Tuxedo a los subsistemas del núcleo, disponibles solo para el código bajo licencia GPLv2 (EXPORT_SYMBOL_GPL). La posibilidad de bloqueo se introdujo originalmente para restringir la vinculación de controladores propietarios con componentes del núcleo de Linux, exportados solo para módulos bajo licencia GPLv2, pero se elude con éxito a través de la creación de módulos intermedios que traducen el acceso del controlador propietario a las API necesarias del núcleo. En el caso de los controladores Tuxedo, la situación es inversa: a pesar de que los controladores Tuxedo se desarrollan independientemente del núcleo, se suministran bajo licencia GPLv3, que, por un lado, no es compatible con GPLv2, pero, por otro lado, defiende más libertades, por ejemplo, protege contra la tivoización.

    Se observa que la empresa Tuxedo ha estado sugiriendo durante mucho tiempo cambiar la licencia de sus controladores, pero continuó suministrando el código bajo licencia GPLv3 y, además, indicaba en el código del controlador el macro ‘MODULE_LICENSE(«GPL»)’ en lugar de ‘MODULE_LICENSE(«GPL v3»)’ para obtener acceso a todos los subsistemas del núcleo. La empresa Tuxedo aceptó la crítica y cambió la licencia a GPLv2+ para parte de sus controladores. El cambio se aplicó a los controladores gxtp7380, ite_8291, ite_8291_lb, ite_8297, ite_8297, stk8321, tuxedo_compatibility_check, tuxedo_nb02_nvidia_power_ctrl y tuxedo_tuxi. Más de una docena de controladores aún no han sido relicenciados, ya que cambiar la licencia de ellos requiere obtener el consentimiento de desarrolladores externos.

    El representante de Tuxedo explicó el uso en el código de ‘MODULE_LICENSE(«GPL»)’ en lugar de ‘MODULE_LICENSE(«GPL v3»)’ por la falta de una explicación clara en la documentación del núcleo, que indique que el marcador «GPL» no se puede utilizar para la licencia GPLv3. También comentó que la empresa tiene la intención de transferir sus controladores al núcleo principal de Linux y, para ello, está trabajando en su reescritura completa bajo licencia GPLv2, teniendo en cuenta los requisitos de los componentes del núcleo.

  • Los desarrolladores del núcleo están discutiendo la iniciativa de agregar la bandera X86_BUG_OLD_MICROCODE, que señala que se está utilizando una versión de microcódigo de CPU no actualizada en el sistema. Al establecer esta bandera, se sugiere considerar el sistema como potencialmente vulnerable a fallos no solucionados. Los intentos de igualar el estado del sistema con microcódigo no actualizado con la situación de tener vulnerabilidades reales sin solucionar en el código han llevado a críticas por parte de uno de los mantenedores del proyecto Linux-libre.

    Según el mantenedor de Linux-libre, el núcleo no debería restringir el derecho de los usuarios a no instalar firmware y microcódigo propietario no verificados en su propio dispositivo. La discusión sobre la existencia de vulnerabilidades se propone hacerla en relación con correcciones específicas en versiones determinadas del firmware, en lugar de clasificar como vulnerables todos los sistemas que no tienen el microcódigo más reciente, sin examinar si hay vulnerabilidades en dicho sistema y si el firmware actualizado contiene correcciones para fallos.

Fuente: opennet.ru

Compra un hosting fiable para sitios web con protección contra DDoS, servidores VPS VDS 🔥 Compra un hosting fiable para sitios web con protección contra DDoS, servidores VPS VDS | ProHoster