DevSecOps

25 jul, 2014

Linux-libre: kernel Linux totalmente livre

Publicidade

De acordo com Alexandre Oliva, um dos fundadores da Free Software Foundation (FSF) América Latina, o kernel Linux era originalmente livre, quando foi relicenciado em 1992, sob a segunda versão da GNU General Public License (GPL). No entanto, desde 1996, tem-se aceitado o que são conhecidos como blobs de firmware – bits binários de código proprietário, conhecidos por operar em drivers para wireless e outros periféricos. Como o código fonte para essas blobs não está disponível, Oliva e outros defensores do software livre argumentam que eles deixam de tornar o kernel livre. É por isso que Oliva iniciou o projeto GNU Linux-libre, para que os defensores do software livre pudessem se tornar cientes do problema e usar um kernel verdadeiramente livre em seus sistemas operacionais. Oliva tem sido um membro ativo do Projeto GNU desde 1991. Ele começou reportando bugs e, depois de alguns anos, passou a mantenedor do Autotools e do GNU Compiler Collection. Após o trabalho lhe render uma contratação da Red Hat em 2000, ele também se envolveu com o binutils, glibc e o GNU Project Debugger. Desde então tornou-se conhecido como um palestrante regular sobre projetos de software livre.

Blobs

“Os primeiros blobs no Linux”, explica ele, “foram pedaços de objeto de código muito pequenos, disfarçados no código fonte como arrays de caracteres e licenciados sob licenças de software livre muito permissivas”. No entanto, ele diz: “Uma vez que as portas estavam abertas, outros blobs com vários inconvenientes começaram a fluir para as fontes do Linux: alguns tinham licenças que eram claramente proprietárias, declarando explicitamente que foram gerados a partir do código fonte secreto, proibindo a engenharia reversa e impondo restrições incompatíveis com várias outras GPL. Outros têm licenças de software livre, e são compatíveis com a GPL, exceto pela a falta do código fonte, mas não são mais pequenos: alguns são sistemas operacionais que executam em periféricos, maiores do que as versões iniciais do próprio Linux”. Ao longo dos anos, algumas tentativas foram feitas para submeter patches para reduzir a dependência de blobs no firmware, mas “eles não eram apenas rejeitados, eram também desacreditados”. O máximo que o projeto do kernel Linux faria, seria mover os blobs para arquivos separados, o que os tornariam mais fáceis de encontrar, mas não faria nada para mudar o problema básico. A presença dos blobs passou despercebida até por volta de 2005, quando Ututo, a primeira distribuição Linux totalmente livre, notou a existência deles e começou a retirá-los de seus próprios releases. Logo depois, o gNewSense, outra distribuição gratuita, lançou sua primeira versão, que incluía ferramentas para ajudar a localizar blobs no código fonte, e Oliva então iniciou o Linux-libre. Então, por que esse problema básico não foi abordado? “O projeto Linux não compartilha os valores do software livre”, afirma Oliva sem rodeios. “Os principais decisores lá não concordam que os usuários mereçam liberdade em todo o software que utilizam ou qualquer software que tire a liberdade é um problema, uma ferramenta criada para subjugar que pode e será abusada para estender o poder”. Ele observa, também, que muitas distribuições populares “enganam os usuários fazendo-os acreditar que são livres e que têm liberdade”, quando, na verdade, não são. Oliva não revela, mas, sem dúvida, a prática comum de se incluir software proprietário como o Acrobat Flash Player para a conveniência do usuário abre uma precedência para as distribuições não se preocuparem com blobs de firmware. Afinal, insistir em um kernel completamente livre ainda pode causar problemas de compatibilidade de hardware até hoje.

Criação e uso de um kernel livre

Atualmente, o Linux-libre ou seus scripts são usados ​​por todas as distribuições que a Free Software Foundationlista como completamente livres. Voluntários também usam kernels do projeto para ajudar a criar kernels livres para o Debian, Ubuntu e Fedora, que “oferece aos usuários a opção de recuperar a liberdade sem abandonar suas distribuições favoritas”. A maior parte do trabalho básico de criação de um kernel Linux-libre é feita por Oliva, embora a criação de binários para distribuições específicas seja muitas vezes feita por outros membros do projeto também. O trabalho de Oliva é atualizar os “scripts de deblobbing”, e então executá-los no código fonte do kernel Linux: a atualização é feita uma vez a cada grande ciclo de lançamento: “Pego uma nova versão, publicada por Linus Torvalds, executo o script de deblobbing da versão anterior sobre ele e ajusto o script até que seja executado sem erros. Então, executo o script de deblobbing no modo “busca de inconsistências”, de modo que ele retorna todos os novos blobs ou requisições de blobs que não são cobertos, e ajusta os padrões de modo a não retornar uma flag de falsos positivos, e de forma a fazer o deblob de novos padrões corretamente, repetindo este passo até que toda a árvore seja considerada como blobfree. Finalmente, comparo as alterações introduzidas pelo deblobbing com as da versão anterior, e faço quaisquer ajustes para a manipulação de arquivos que estavam sob – ou sobre – o deblobbed. Uma vez que este trabalho preliminar seja concluído, é feita a limpeza de um arquivo tar ou árvore de código fonte baseada no mesmo release, o que requer apenas a execução de scripts apropriados. Atualizar scripts de deblobbing geralmente leva um dia inteiro de trabalho, ao passo que o deblobbing de uma árvore fonte leva apenas alguns minutos – muitas vezes menos tempo do que arquivá-la em um arquivo tar. O arquivo tar de um kernel deblobbed é compilado exatamente da mesma forma que qualquer outro kernel. Se os usuários percebem alguma coisa diferente dependerá da distribuição e do hardware. Em uma distribuição que esconde mensagens de boot, os usuários não notam nada, a menos que leiam os logs de inicialização. Em uma distribuição que mostra mensagens de boot, eles podem notar uma mensagem que o firmware livre está faltando para um dispositivo periférico. Esta mensagem, no entanto, não significa necessariamente que o dispositivo não é suportado – pode ser apenas que o driver livre seja carregado mais tarde no processo de boot. Alternativamente, “os poucos drivers Linux que ainda possuem blobs disfarçados de código fonte silenciosamente irão abster-se de fazer o upload dos blobs para o periférico”. Além disso, diz Oliva, “uma série de dispositivos funcionarão mesmo na ausência de uma atualização de firmware, mas outros serão processados de maneira não-funcional pela ausência de firmware”. Esses casos podem ser irritantes, mas ele argumenta que esta situação não pode ser uma coisa totalmente ruim, lembrando que “se o dispositivo não funciona, ele provavelmente não vai controlar ou espionar o usuário”.

A razão disso tudo

O processo básico tem funcionado bem durante vários anos. Ao mesmo tempo, Oliva menciona vários problemas ou possíveis melhorias. Por exemplo, Oliva sugere que o bloqueio do carregamento de blobs não é uma característica de kernels Linux-libre tanto como “um erro que é muito difícil de corrigir”. Ele sugere que isso interfere na capacidade do usuário de decidir se deve ou não carregar o firmware. Além disso, quando um blob se torna um driver livre – como aconteceu com o driver ath6k htc para placas wireless Atheros – os usuários tiveram que esperar por um kernel livre revisado antes que pudessem usar o driver livre recém-lançado. Ele está atualmente considerando uma revisão dos scripts de deblobbing que permita aos usuários fazer suas próprias escolhas sobre carregar blobs de firmware. Oliva também gostaria de criar um repositório Git com uma história completa em que cada commit corresponde a um commit no kernel Linux em si. Com este arranjo, “usuários git que utilizam o repositório git livre poderiam colaborar com aqueles cujas árvores são montadas pelo blob, realizando merges e patches de uma forma que não requeiram que qualquer uma das partes tome os históricos de revisão inteiros”. No entanto, ele acrescenta que, “ainda não está claro qual infraestrutura precisa ser adicionada ao Git, se houver, para tornar possível esse tipo de interoperação”. Mesmo sem essas melhorias, no entanto, Oliva continua convencido da importância do trabalho do Linux-libre. “Tenho muitas vezes ouvido argumentos de que há uma necessidade de comprometer a liberdade, por vezes, para ganhar massa crítica e mudar o jogo”. Mas, diz Oliva, “se a incompatibilidade entre partes específicas do hardware e a liberdade de um usuário é escondida do usuário, se distribuições populares levam os usuários a acreditarem que repositórios que escondem o blob contêm apenas software livre, e se desenvolvedores experientes se referem a todo o sistema pelo nome de um kernel, onde os blobs não são sequer considerados um problema, que esperança há de que os usuários possam aprender sobre o problema e tomar uma posição de liberdade?” Oliva pontuou, mas pelo menos com as incursões que o Linux-libre fez nos poucos anos de sua existência, há uma possibilidade de que os usuários – ou, pelo menos, os desenvolvedores das distribuições – possam educar-se sobre os problemas e fazer escolhas com base em informações mais precisas.

***

Publicado originalmente em: http://www.linuxmag.com.br/lm/article_online/linux_libre