andrelop’s blog

Módulos de kernel binários : a saga continua

Estava lendo a retrospectiva de 2006 do lwn.net (desculpe, conteúdo somente para assinantes, mas em uma semana o conteúdo será liberado para todos) e algo que me chamou a atenção foi novamente a citação do caso dos módulos de kernel somente binários (módulos para os quais não existem código-fonte liberado). Não vou entrar em detalhes sobre o que foi dito na retrospectiva aqui porque seria injusto de minha parte reproduzir conteúdo de acesso restrito.

O que me levou a escrever este post foi o fato de, recentemente, os próprios desenvolvedores do kernel terem considerado a idéia de banir completamente o carregamento de módulos somente binários do kernel. Sim, isso mesmo, banir completamente. E a idéia teve gente importante e influente que a apoiasse (como Andrew Morton e Greg Kroah-Hartman), inclusive com patches para colocá-lo em prática postados na lista de discussão dos desenvolvedores do kernel.

No final, porém, depois de muita discussão, a idéia foi abandonada, infelizmente. Um dos pontos principais que levou a idéia a não ser levada adiante e ser concretizada foi o fato de que, na verdade, a licença usada pelo kernel Linux (a GPL) não impede explicitamente que você USE (maiúsculas usadas intencionalmente aqui) código GPL com qualquer outro código, seja ele livre ou um monte de lixo binário sem fonte algum disponível.

Veja bem, existem restrições em relação a mesclar código licenciado sob GPL com código coberto por outras licenças (mas não vou entrar em detalhes até porque não sou especialista na àrea jurídica e não quero correr o risco de falar bobeira), mas não em relação a USAR software licenciado sob GPL com softwares somente binários não cobertos pela GPL.

O que é interessante de se notar é que, caso fossem implementadas maneiras de impedir o carregamento de módulos somente binários, na prática estariam implementando um artifício técnico para impedir algo que no fundo ninguém gosta (seria ótimo ter drivers livres e especificações liberadas para todo tipo de hardware), mas que é explicitamente permitido pela licença sob a qual o kernel é lançado. Ou seja, estariam restringindo um direito que a própria licença garante aos usuários de software cobertos pela mesma.

Ok, não é lá muito inteligente retirar intencionalmente uma liberdade explicitamente garantida pela própria licença do software que você desenvolve, mas, convenhamos : que muita gente ficaria feliz caso isso acontecesse, ah, isso ficaria sim. Pena que tenhamos que ser boas almas e não forçar a barra para acabar com um problema maior.

Um dos problemas de módulos binários (além do problema óbvio de não serem livres) é que, como não existe código fonte disponível, não há como os desenvolvedores do kernel suportá-los. Na verdade, qualquer pessoa que relata um problema com os mesmos para a lista dos desenvolvedores do kernel é informada que, infelizmente, vai ter que entrar em contato com o fornecedor do módulo binário, geralmente o mesmo fornecedor do hardware que teria que funcionar com o módulo binário em questão mas que, por algum motivo, não o está.

Basicamente, o usuário fica escravo do fornecedor do módulo binário e cria-se aí uma relação de dependência, mesmo o usuário muitas vezes tendo migrado para softwares livres exatamente para fugir dessa armadilha de dependência de um único fornecedor. Quer um exemplo fácil do dia-a-dia ? Quantos são impedidos de atualizarem seus kernels antes que a nVidia lance versões novas de seus drivers fechados compatíveis com a nova versão do kernel ?

Ou, pior ainda, quantos nem sabem que esse problema existe e atualizam para uma versão mais nova do kernel (com as ferramentas de atualização de software modernas das distribuições atuais isso é moleza, feito com um ou dois cliques) e descobrem que perderam seu ambiente gráfico completamente ? E quantos desses usuários põem a culpa no “Linux” por isso ? E quantos desses usuários realmente sabem que não há nada que os desenvolvedores do kernel possam fazer em relação a isso, mesmo se quisessem ?

Percebeu o problema ? Eu ainda não li (e creio que, se lesse, provavelmente não entenderia a maior parte), mas gostaria que a GPLv3 ajudasse de alguma forma nesse sentido, criando algum tipo de mecanismo legal que, de alguma forma inteligente, obrigasse a liberação dos códigos-fonte dos módulos binários ou pelo menos tornasse o uso dos mesmos com um software GPL (o kernel, por exemplo) algo ilegal.

Esse seria meu presente de Natal preferido. Infelizmente, parece que, ao menos por um bom tempo, isso não vai acontecer. Eu adoraria estar errado e presenciar uma liberaçao em massa de fontes por parte dos desenvolvedores de módulos binários, já que, de outra forma, o hardware que os mesmos desenvolvem não funcionariam em Linux. Atualmente, Linux já é algo que atingiu massa crítica grande o bastante para forçar movimentos nessa direção. Só não acontece porque não é algo que seja estritamente necessário, legalmente falando.

Seria ótimo também, na minha próxima compra, poder comprar hardware sem medo de que o mesmo não funcione por eu estar utilizando uma distribuição “não recomendada para uso empresarial” (já me falaram isso, Å›erio) e, portanto, ignorada pelos desenvolvedores de módulos binários, que muitas vezes só lançam versões binárias de seus módulos para distribuições específicas e não de uma forma genérica que possa ser utilizada por todas as distribuições.

Lógico, é impraticável manter versões para cada distribuição, mas liberar o código faria com que o mesmo fosse melhorado pelos desenvolvedores da comunidade, possivelmente incorporado a árvore oficial e mantido atualizado constantemente, como é feito com todos os outros drivers que já foram liberados e já estão incorporados na árvore oficial do kernel. Não existiria a necessidade de manter versões para cada distribuição, visto que o código seria genérico o bastante para funcionar em todas elas.

Todos sairiam ganhando : o usuário, que poderia optar por utilizar a distribuição que mais lhe agradasse, e a empresa fabricante do hardware, que não teria o trabalho de manter seu código atualizado e alinhado com todas as constantes modificações que ocorrem no código do kernel e demandam trabalho constante dos mantenedores de código que roda em nível de kernel.

Módulos de kernel binários e liberdade

Eu sei que não deveria estar escrevendo sobre isso sob pena de gerar infindáveis discussões e sei que o post que eu vou citar pode ser incluso como parte da guerra entre a Red Hat e a Novell que se iniciou após o acordo entre Novell e Microsoft vir a público, mas, deixando o fato de que ambas Red Hat e Novell estão cada uma tentando defender o seu peixe, é interessante citar o último post de Dave Jones, kernel hacker da Red Hat que mantém o kernel da distribuição Fedora.

Ele toca em um assunto importante, que é a liberdade, e critica o Ubuntu por aparentemente ter decidido incluir módulos binários por padrão no kernel da próxima versão do Ubuntu. Tente deixar de lado o fato que existe sim uma briga por trás dos bastidores e que, como funcionário da Red Hat, é improvável que ele defenderia as ações de um concorrente, mas tenha em mente que, antes de ser um funcionário da Red Hat, ele tem razão em relação a questão da liberdade.

Apesar de já ser algo bastante antigo, Dave foi astuto em notar um documento já antigo escrito por Arjan van de Ven há algum tempo atrás sobre módulos binários sendo incluídos no kernel Linux e os resultados futuros que isso poderia gerar.

Eu já havia lido esse documento na época que Arjan o tornou público, mas devido ao asunto parecer ter voltado à tona novamente e a pessoas já terem me perguntando várias vezes sobre drivers (módulos de kernel, na verdade) binários para Linux e porque os mesmos não são incluídos no kernel de uma vez para “facilitar” a vida dos usuários, resolvi traduzí-lo aqui.

É importante deixar claro que é uma tradução não oficial e feita de forma rápida e, como tal, pode conter erros. Conto com a ajuda de quem encontrá-los pra relatá-los e permitir que eu os corrija para tornar esse post o mais correto possível. Segue abaixo a tradução do documento do Arjan, antigo mais ainda bastante atual :

Linux em um mundo binário
=========================

O que aconteceria se … o que aconteceria se os desenvolvedores do kernel
Linux amanhã aceitassem que módulos de kernel binários estivessem OK e que os mesmos fossem essenciais para o progresso do Linux.

Um cenário hipotético do final dos tempos por Arjan van de Ven

A hipótese primária nesse cenário obviamente não vai acontecer, mas todas as hipóteses que a seguem são coisas que possuem uma base e que são verdadeiras em uma forma ou outra, mas é claro que nomes de “inocentes” foram omitidos.

Em 6 de Dezembro de 2005 os desenvolvedores do kernel decidem em massa que módulos binários são legalmente aceitos e também essenciais para o progresso do Linux e, dessa forma, são algo desejável. Em um primeiro momento, o processo de desenvolvimento do kernel Linux não muda muito além do fato de que alguns símbolos a mais são exportados, e o símbolo EXPORT_SYMBOL_GPL é removido.

Dentro de 3 semanas, distribuições como o Red Hat Linux Enterprise e o SuSE SLES começam a incluir uma ampla variedade de módulos binários em seus CDs de instalação. O Debian renuncia a isso e continua puro a sua causa, como o fazem outras distribuições abertas como o Fedora Core e o
openSuSE.

As distribuições corporativas (enterprise) só não incluem os módulos da nVidia e da ATI, mas incluem todos os módulos de distribuidores OEM de “fakeraid” (RAID falso, ou pseudo-RAID) e diversos módulos wireless, winmodem, winDSL e TCP-offloading. Porém, ao contrário da nVidia e da ATI, a maioria dos distribuidores de módulos binários não fornecem seus drivers em um formato de “camada de cola” (glue layer) : eles fornecem somente os binários finais.

Diversos distribuidores de hardware que foram amigáveis ao movimento de código aberto até então vêem seus competidores fornecer somente drivers binários e internamente começam a sofrer pressão para também manter sua propriedade intelectual (IP) privada e eles sabem que não usaram alguns recursos de seu hardware porque seus departamentos legais não queriam sua propriedade intelectual se tornando pública.

Como resultado eles acham que os drivers binários de seus competidores estão em vantagem teórica, ou que pelo menos seus próprios drivers poderiam estar em vantagem caso eles também fossem fechados, porque nesse caso eles poderiam utilizat aqueles outros recursos extras para
se manter a frente de seus competidores.

Em Fevereiro de 2006, por volta da metade dos distribuidores de hardware refocaram seus esforços internos para drivers Linux para criar valor agregado em drivers binários que lançarão além dos drivers abertos que já existem. Alguns distribuidores até mesmo pararam de suportar seus drivers abertos porque não possuem recursos suficientes para fazê-lo.

1 de Março. Todas as ntícias dos maiores distribuidores de hardware saem com a próxima geração de hardware de armazenamento e rede. Esse hardware é distribuído com drivers binários para as últimas 2 versões das distribuições RHEL e SLES e esses drivers já estão integrados nas atualizações de Fevereiro dessas distribuições

Um desses distribuidores de hardware lançam seu driver em um formato .o mais um formato de camada de cola, os outros não se importam e lançam somente versões binárias para essas duas distribuições. Dois dos fabricantes de placas de rede lançam uma atualização para seus drivers de código aberto para suportar minimamente as novas placas, os outros nem isso o fazem. Hardware destinado ao público em geral não é amplamente afetado : a maioria dos chipsets destinados ao público em geral padronizaram em AHCI para armazenamento SATA e mantiveram o conjunto de recursos existente em chipsets de rede.

1 de Abril. 2 dos fabricantes de chipsets destinado ao consumo geral atualizam seus chipsets para que os mesmos incluam novos e excitantes recursos de áudio que oferecem reprodução de DVD melhorada, mas infelizmente isso os levou a desviar da interface de hardware de áudio i810 ‘padrão’. Um deles lança um driver binário para algumas distribuições e o outro não considerou o Linux relevante para o desktop e ainda não se preocupou em desenvolver um driver para Linux.

1 de Maio. Todo hardware para servidores que você pode comprar requer pelo menos um, mas normalmente 2 ou 3 módulos binários para funcionar. Apesar de alguns desses módulos estarem disponíveis no formato BLOB+cola, diversos estão somente disponíveis para RHEL3, RHEL4 e SLES9 e em alguns casos o recém-lançado SLES10.

Usuários Linux terão a sua escolha 4 kernels para esses servidores ao mesmo tempo, mas nenhuma esperança de poder usar um kernel oficial do kernel.org nesses servidores. O pessoal do Ubuntu está bem desapontado e trabalhando duro, com sucesso variado, conseguir disponibilizar drivers para sua
distribuição. Devido ao sucesso desse lobby, por volta de 50% desses servidores tambpem podem ser usados com o kernel do Ubuntu.

1 de Junho. Uma grande discussão (flamewar), a quarta sobre esse assunto desde Janeiro, acontece na lista de discussão linux-kernel. Usuários e alguns desenvolvedores estão querendo que o kernel do site kernel.org adote a ABI de módulos do RHEL ou do SLES. Investigações mostram que isso não é possível, e a discussão se torna uma discussão sobre o design de uma nova ABI versus congelar a ABI existente.

Muitos desenvolvdores do kernel acham que que a ABI ad-hoc existente não é adequada para congelamente e que uma nova ABI e uma nova API, criada para que possam ser tornadas estáveis de forma mais fácil é o caminho certo a ser seguido, enquanto outros dizem que isso iria requerer muito tempo e que isso não ajudaria pelos próximos 2 anos até que o RHEL e o SLES tenham adotado essa ABI, e pelo menos demandaria um congelamento imediato da ABI do kernel do site kernel.org de forma que o futuro RHEL5 talvez a utilizasse, o que levaria a drivers serem desenvolvidos para a mesma. Usuários normalmente usam o RHEL ou o SLES para servidores de produção e clones como o CentOS, que lançaram kernels compatíveis binariamente.

1 de Julho. É crescemente difícil rodar Linux sem módulos binários na maioria do novos PCs destinados ao público em geral. Enquanto que um ano atrás as pessoas teriam que abdicar da aceleração 3D para isso rotineiramente, agora até mesmo suporte a 2D não funciona sem drivers
binários, nem rede (ambos rede cabeada e wireless) ou som. Para metade das máquinas não existe suporte a Linux disponível de forma geral, enquanto 20% utilizam camadas de tradução como o ndiswrapper para rodar os drivers de som e rede do Windows.

O Debian, incapaz de rodar na maioria das máquinas atuais, está perdendo quantidades massivas de usuários para o Ubuntu e os híbridos Ubuntu-Debian. A lista de discussão debian-legal e outras listas do projeto Debian são impossíveis de serem lidas por pessoas não interessadas nesse tópico
inflamatório em particular. A maioria dos distribuidores que mantinham seus drivers de código aberto ao menos parcialmente atualizados pararam de fazê-lo.

14 de Julho. Linus declara a ABI do kernel estável mas também inicia a série 2.7 do kernel e declara que o kernel 2.8 terá uma ABI diferente. Na prática, somente pessoas que mantiveram suas máquinas antigas podem ajudar o desenvolvimento da série 2.7, uma vez que nenhum dos distribuidores
de drivers, nem mesmo aqueles que ainda possuem uma construção BLOB+cola, se importa com a árvore de desenvolvimento que se move de ‘muito rápida’.

21 de Agosto. Uma série falha de segurança é encontrada na série 2.6, que finalmente se dscobre ser uma falha de design em uma API sysfs chave. Corrigir essa falha iria requerer que a ABI de módulos e que praticamente todos os módulos fossem quebrados, e não corrigir essa falha deixaria uma falha que poderia ser explorada com privilégios de root aberta.

Uma correção rápida é disponibilizada sob a forma de uma opção CONFIG_ no kernel, mas usuários que precisam de drivers binários não tem outra escolha a não ser deixar seus sistemas vulneráveis. Diversas discussões na lista linux-kernel aparecem novamente, dizendo que Linus cometeu um
erro em congelar a ABI ao invés de criar uma nova desenhada para ser congelada. O desenvolvimento da série 2.7 estagnou quase que totalmente e um patch para que a série 2.7 utilize a ABI da série 2.6 novamente é proposto, revertendo diversas melhorias em subistemas chave de memória
virtual e os patches de tempo-real do Ingo.

26 de Agosto. Um exploit pré-deenvolvido para a falha de segurança aparece na lista de discussão bugtraq e o mesmo passa a atuar sendo usado por diversos rootkits. Um exploit PHP utiliza-o para se tornar root a partir do usuário httpd. Usuários estão colocando pressão nos distribuidores de
módulos para que os mesmos lancem módulos para a nova ABI e diversos deles na verdade fazem isso nas três semanas que se seguem. Outros, a maioria no mercado do público em geral, dizem que o hardware em questão não é mais vendido e que eles não vão mais gastar tempo algum em esforços para escrever drivers para o mesmo.

Esse cenário pode parecer irreal para você. E, felizmente, é improvável que a hipótese principal (o evento de 6 de Dezembro) aconteça.

Porém, e isso infelizmente, diversos outros “saltos” não são assim tão improváveis. De fato, alguns dos resultados provavelmente acontecerão independente do evento inicial : observe as discussões acaloradas na lista de discussão linux-kernel sobre quebrar a API/ABI de módulos.

Observe o efeito do ndiswrapper em distribuidores que agora dizem “nós suportamos o Linux porque o ndiswrapper pode usar nosso driver Windows.” Eu espero que nada disso aconteça. Algumas dessas esperanças serão esperanças perdidas, mas eu acredito que as vantagens da liberdade no final são fortes o bastante para suplantar as forças opostas.

Ok, acho que minha posição sobre o assunto é bem clara a esse ponto