A Fundação Latino-Americana de Software Livre publicou uma versão totalmente livre do núcleo Linux 6.12 — Linux-libre 6.12-gnu, limpa de elementos de firmwares e drivers que contêm componentes ou trechos de código não livres, cuja área de aplicação está limitada pelo fabricante. Além disso, o Linux-libre desativa funções do núcleo para carregar componentes externos não livres que não estão incluídos na entrega do núcleo, e remove menções ao uso de componentes não livres da documentação.
Para limpar o núcleo de partes não livres, o projeto Linux-libre criou um script shell universal que contém milhares de modelos para identificar a presença de inserções binárias e excluir falsos positivos. Também estão disponíveis para download patches prontos, criados com base na utilização do script mencionado. O núcleo Linux-libre é recomendado para uso em distribuições que atendem aos critérios da Fundação de Software Livre para a construção de distribuições GNU/Linux totalmente livres. Por exemplo, o Linux-libre é utilizado em distribuições como Dragora Linux, Trisquel, Dyne:Bolic, gNewSense, Parabola, Musix e Kongoni.
Na versão Linux-libre 6.12-gnu, foi adicionado código para limpar blobs em drivers para SoC CPM/QE QMC, chips sem fio Realtek 8852BE-VT, adaptadores bluetooth Amlogic, adaptadores de rede amcc qt2025, sensores aw96103/aw96105 e codecs TI TLV320AIC31XX. Foi feita uma limpeza adicional de blobs em drivers para controladores xHCI Renesas e Intel ISH (Integrated Sensor Hub) HID. O código para remoção de blobs em drivers e subsistemas MHI PCI host, Adreno 620/621, r8169, Qualcomm q6v5 remoteproc, rtw8852c, rtw8922a, assim como em arquivos dts para chips ARM54 TI PRU e Qualcomm foi atualizado. A limpeza de drivers para placas sem fio ks7010 e subsistema de áudio Intel SkyLake foi interrompida, pois esses drivers foram removidos do núcleo.
Destaca-se ainda a identificação, nos códigos fonte, de um dos drivers de código objeto executável, gerado a partir de códigos fonte não publicados e embutido na forma de uma sequência de números hexadecimais. O driver problemático não é nomeado explicitamente, mas, com base nas mudanças, parece referir-se à presença de microcódigo de shader no arquivo gfx_v9_4_3_cleaner_shader.h, que faz parte do driver AMDGPU. A primeira inserção desse tipo foi identificada no núcleo 6.11 e depois sugerida por um dos desenvolvedores para remoção, pois os códigos fonte não foram fornecidos (ocorreu a situação de fornecimento sob licença GPL de um programa disponível apenas em formato binário). No entanto, no núcleo 6.12, o código binário mencionado foi mantido, e nesse mesmo driver foi adicionada mais uma inserção semelhante.
Além disso, o anúncio do Linux-libre 6.12 menciona mais dois eventos:
- Para inclusão no núcleo, foi proposta uma correção que bloqueia os drivers para notebooks Tuxedo de acessar subsistemas do núcleo disponíveis apenas para código sob licença GPLv2 (EXPORT_SYMBOL_GPL). A possibilidade de bloqueio foi inicialmente introduzida para restringir a vinculação de drivers proprietários com componentes do núcleo Linux, exportados apenas para módulos sob licença GPLv2, mas é contornada com sucesso através da criação de módulos intermediários que translatam o acesso do driver proprietário à API necessária do núcleo. No caso dos drivers Tuxedo, a situação é inversa — embora os drivers Tuxedo sejam desenvolvidos separadamente do núcleo, eles são fornecidos sob licença GPLv3, que, por um lado, não é compatível com GPLv2, mas, por outro lado, defende mais liberdades, como a proteção contra tivoização.
Nota-se que a empresa Tuxedo há muito propõe mudar a licença de seus drivers, mas continuou a fornecer o código sob licença GPLv3 e, ao mesmo tempo, indicava no código do driver a macro ‘MODULE_LICENSE(«GPL»)’ em vez de ‘MODULE_LICENSE(«GPL v3»)’ para obter acesso a todos os subsistemas do núcleo. A empresa Tuxedo concordou com a crítica e alterou a licença para GPLv2+ para parte de seus drivers. A alteração foi aplicada aos drivers gxtp7380, ite_8291, ite_8291_lb, ite_8297, ite_8297, stk8321, tuxedo_compatibility_check, tuxedo_nb02_nvidia_power_ctrl e tuxedo_tuxi. Mais de uma dezena de drivers ainda não foram relicenciados, pois para a mudança de licença deles é necessário obter a concordância de desenvolvedores terceiros.
O uso no código de ‘MODULE_LICENSE(«GPL»)’ em vez de ‘MODULE_LICENSE(«GPL v3»)’ foi explicado por um representante da Tuxedo pela ausência de uma explicação clara na documentação do núcleo, que o marcador «GPL» não pode ser usado para a licença GPLv3. Ele também mencionou que a empresa pretende submeter seus drivers ao núcleo principal do Linux e, para isso, está trabalhando em uma reescrita completa deles sob a licença GPLv2, levando em consideração os requisitos para componentes do núcleo.
- Os desenvolvedores do núcleo discutem a iniciativa de adicionar a flag X86_BUG_OLD_MICROCODE, que sinaliza que uma versão desatualizada do microcódigo da CPU está sendo usada no sistema. A configuração dessa flag sugere considerar o sistema como tendo vulnerabilidades potenciais não corrigidas. Tentativas de igualar o estado do sistema com microcódigo desatualizado à situação de várias vulnerabilidades reais não corrigidas no código geraram críticas de um dos mantenedores do projeto Linux-libre.
Na opinião do mantenedor do Linux-libre, o núcleo não deve restringir o direito dos usuários de não instalarem firmware e microcódigos proprietários não verificados em seus próprios dispositivos. A conversa sobre a existência de vulnerabilidades deve ser vinculada a correções específicas em versões determinadas de firmwares, e não rotular qualquer sistema que não tenha o microcódigo mais recente como vulnerável, sem considerar se vulnerabilidades se manifestam nesse sistema e se o firmware mais recente contém correções para essas vulnerabilidades.
Fonte: opennet.ru
