{"id":120601,"date":"2024-11-19T13:09:07","date_gmt":"2024-11-19T11:09:07","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/dostupno-yadro-linux-libre-6-12-reshenie-liczenzionnyh-problem-s-drajverami-tuxedo"},"modified":"2024-11-19T13:09:07","modified_gmt":"2024-11-19T11:09:07","slug":"dostupno-yadro-linux-libre-6-12-reshenie-liczenzionnyh-problem-s-drajverami-tuxedo","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/dostupno-yadro-linux-libre-6-12-reshenie-liczenzionnyh-problem-s-drajverami-tuxedo","title":{"rendered":"\u00c8 disponibile il kernel Linux-libre 6.12. Soluzione ai problemi di licenza con i driver Tuxedo","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
La Fondazione Latinoamericana per il Software Libero ha pubblicato una versione completamente libera del kernel Linux 6.12 \u2014 Linux-libre 6.12-gnu, ripulita da elementi di firmware e driver contenenti componenti o porzioni di codice non liberi, il cui utilizzo \u00e8 limitato dal produttore. Inoltre, Linux-libre disabilita le funzioni del kernel per il caricamento di componenti esterni non liberi non inclusi nella distribuzione del kernel e rimuove i riferimenti all'uso di componenti non liberi dalla documentazione. <\/p>\n
Per ripulire il kernel da parti non libere, il progetto Linux-libre ha creato uno script shell universale, che contiene migliaia di modelli per identificare la presenza di inserimenti binari ed escludere i falsi positivi. Sono inoltre disponibili per il download patch pronte, create sulla base dell'uso dello script sopra menzionato. Il kernel Linux-libre \u00e8 raccomandato per l'uso in distribuzioni che rispettano i criteri del Fondo per la costruzione di distribuzioni GNU\/Linux completamente libere. Ad esempio, Linux-libre \u00e8 utilizzato in distribuzioni come Dragora Linux, Trisquel, Dyne:Bolic, gNewSense, Parabola, Musix e Kongoni. <\/p>\n
Nella versione Linux-libre 6.12-gnu \u00e8 stato aggiunto il codice per la rimozione dei blob nei driver per i SoC CPM\/QE QMC, i chip wireless Realtek 8852BE-VT, gli adattatori bluetooth Amlogic, i controller di rete amcc qt2025, i sensori aw96103\/aw96105 e i codec TI TLV320AIC31XX. \u00c8 stata effettuata un'ulteriore pulizia dei blob nei driver per i controller xHCI Renesas e Intel ISH (Integrated Sensor Hub) HID. \u00c8 stato aggiornato il codice per la rimozione dei blob nei driver e nei sottosistemi MHI PCI host, Adreno 620\/621, r8169, Qualcomm q6v5 remoteproc, rtw8852c, rtw8922a, e nei file dts per i chip ARM54 TI PRU e Qualcomm. \u00c8 stata interrotta la pulizia dei driver per le schede wireless ks7010 e il sottosistema audio Intel SkyLake, poich\u00e9 questi driver sono stati rimossi dal kernel. <\/p>\n
Viene segnalata separatamente l\u2019individuazione in alcuni testi sorgente di uno dei driver di codice oggetto eseguibile, generato a partire da testi non pubblicati e incorporato sotto forma di sequenza di numeri esadecimali. Il driver problematico non \u00e8 specificato, ma dai cambiamenti evidenziati sembra riguardare la presenza di microcodice del shader nel file gfx_v9_4_3_cleaner_shader.h, parte del driver AMDGPU. La prima di queste aggiunte \u00e8 stata identificata nel kernel 6.11 ed \u00e8 stata quindi proposta da uno degli sviluppatori per la rimozione, poich\u00e9 i testi sorgente non erano stati forniti (si \u00e8 verificata la situazione di fornitura sotto licenza GPL di un programma accessibile solo in forma binaria). Tuttavia, nel kernel 6.12 il codice binario indicato \u00e8 stato mantenuto e nello stesso driver \u00e8 stata aggiunta un'altra simile integrazione. <\/p>\n
Inoltre, nell\u2019annuncio di Linux-libre 6.12 vengono menzionati altri due eventi: <\/p>\n
\n
\u00c8 stata proposta una correzione da includere nel kernel che blocca i driver per i laptop Tuxedo dall'accesso ai sottosistemi del kernel disponibili solo per il codice sotto licenza GPLv2 (EXPORT_SYMBOL_GPL). La possibilit\u00e0 di bloccare l'accesso \u00e8 stata inizialmente introdotta per limitare il binding di driver proprietari con componenti del kernel Linux esportati solo per moduli sotto licenza GPLv2, ma viene aggirata con successo creando moduli intermedi che traducono l'accesso del driver proprietario alle API necessarie del kernel. Nel caso dei driver Tuxedo, la situazione \u00e8 opposta \u2014 nonostante i driver Tuxedo si sviluppino separatamente dal kernel, vengono forniti sotto licenza GPLv3, che da un lato non \u00e8 compatibile con GPLv2, ma dall'altro lato sostiene maggiori libert\u00e0, ad esempio protegge dalla tivoizzazione.\n
\u00c8 stato notato che l'azienda Tuxedo ha a lungo proposto di cambiare la licenza dei propri driver, ma ha continuato a fornire il codice sotto licenza GPLv3 e indicava nel codice del driver il macro ‘MODULE_LICENSE(«GPL»)’ invece di ‘MODULE_LICENSE(«GPL v3»)’ per accedere a tutte le sottosistemi del kernel. L'azienda Tuxedo ha accettato la critica e ha cambiato la licenza in GPLv2+ per alcuni dei propri driver. La modifica \u00e8 stata applicata ai driver gxtp7380, ite_8291, ite_8291_lb, ite_8297, ite_8297, stk8321, tuxedo_compatibility_check, tuxedo_nb02_nvidia_power_ctrl e tuxedo_tuxi. Pi\u00f9 di una dozzina di driver non sono ancora stati ri-licenziati, poich\u00e9 per cambiare la licenza \u00e8 necessario ottenere il consenso dagli sviluppatori terzi. <\/p>\n
L'utilizzo nel codice di ‘MODULE_LICENSE(«GPL»)’ invece di ‘MODULE_LICENSE(«GPL v3»)’ \u00e8 stato spiegato da un rappresentante di Tuxedo come una mancanza di chiara spiegazione nella documentazione del kernel, secondo cui il marcatore «GPL» non pu\u00f2 essere utilizzato per la licenza GPLv3. Ha anche affermato che l'azienda intende trasferire i propri driver nel kernel Linux principale e per questo sta lavorando alla loro completa riscrittura sotto la licenza GPLv2, rispettando i requisiti dei componenti del kernel. <\/p>\n
Gli sviluppatori del kernel discutono l'iniziativa di aggiungere il flag X86_BUG_OLD_MICROCODE, che segnala che il sistema sta utilizzando una versione non aggiornata del microcodice della CPU. Quando questo flag \u00e8 attivato, si suggerisce di considerare il sistema come avente potenziali vulnerabilit\u00e0 non corrette. I tentativi di equiparare lo stato del sistema con un microcodice non aggiornato alla situazione di reale presenza di vulnerabilit\u00e0 non corrette nel codice hanno portato a critiche da parte di uno dei manutentori del progetto Linux-libre.\n
Secondo il manutentore di Linux-libre, il kernel non dovrebbe compromettere il diritto degli utenti di non installare firmware e microcodice proprietari non verificati sui propri dispositivi. La questione delle vulnerabilit\u00e0 dovrebbe essere trattata in relazione a specifici aggiornamenti in determinate versioni dei firmware, piuttosto che etichettare vulnerabili tutti i sistemi sui quali non \u00e8 installato il microcodice pi\u00f9 recente, senza esaminare se in quel sistema emergano vulnerabilit\u00e0 e se il firmware aggiornato contenga correzioni per tali vulnerabilit\u00e0. <\/ul>\n