Firmware binário e sua liberdade

Binary firmware and your freedom

Autor original: Patrick Van Oosterwijck

Publicado originalmente no: distrowatch.com

Tradução: Roberto Bechtlufft

Introdução

No mundo da tecnologia, há uma batalha contínua entre as forças que promovem a liberdade e aquelas que tentam cerceá-la. A FSF tem sido uma guardiã vigilante da liberdade, e frequentemente traz à nossa atenção questões que, ignoradas, poderiam ameaçar nossa liberdade no uso da tecnologia. Graças aos seus esforços e à licença GPL, podemos nos beneficiar de software maravilhoso como o kernel do Linux, o GCC e muito mais. Estou convencido de que o cenário do código aberto não seria nem de longe tão belo como é hoje se não fosse pela GPL, que protege os direitos dos usuários de software livre.

E por que eu discordo da atitude da FSF com relação ao firmware binário? Acho que, na melhor das hipóteses, a postura da FSF é inocente. Na pior, é hipócrita. Seja qual for o caso, essa atitude acaba desviando a atenção do verdadeiro problema. Sim, eu sei que essas são acusações fortes. Devido ao meu envolvimento profissional com a indústria de eletrônicos, tenho uma perspectiva meio diferente, uma perspectiva que, digamos, se origina “do outro lado”: o dos fabricantes de hardware. Só para constar, eu não sou empregado e nem tenho relações comerciais com nenhuma das empresas que desenvolvem dispositivos incluídos na lista negra da FSF. Sou só um usuário de chips que precisam de firmware de um jeito ou de outro, então tenho uma ideia melhor de como essas coisas funcionam do que a maioria dos usuários.

O que é um firmware binário?

A maioria dos periféricos que podem ser conectados a um PC têm um “cérebro” próprio. Esse cérebro pode se apresentar na forma de um microcontrolador, de um microprocessador ou de um FPGA. Em todos esses casos, as peças básicas de hardware do periférico são programáveis, e o fabricante do periférico precisa implementar algoritmos que façam o periférico cumprir suas tarefas e se comunicar com o PC. Esses algoritmos podem ser implementados em código de software, como é o caso com os microcontroladores e microprocessadores, ou mesmo em código descrevendo conexões de hardware programáveis, como acontece com periféricos FPGA. Esse código é chamado de “firmware”.

Uma característica importante do firmware é que ele é totalmente executado no periférico. O microprocessador do PC não executa nenhuma das instruções do firmware. Na maioria dos casos, seria até mesmo impossível para o microprocessador do PC executar o código do firmware, já que os periféricos geralmente usam chips com arquiteturas e conjuntos de instruções mais simples, diferentes do conjunto de instruções do PC.

Quero deixar isso bem claro: a opinião que estou expressando neste artigo diz respeito apenas a firmware binário em execução no dispositivo periférico, e não a drivers binários carregados como módulos do kernel pelo kernel do Linux, e que são executados dentro do kernel. Os módulos binários do kernel trazem grandes problemas, que são completamente diferentes dos apresentados por firmware binário.

Nos últimos anos, uma parcela maior das arquiteturas de microprocessadores e microcontroladores usados em periféricos está ganhando suporte em compiladores de software livre, como o GCC e o SDCC, e a situação não para de melhorar. Mas do jeito que as coisas estão hoje, muitos desses chips só contam com suporte através de ferramentas de desenvolvimento proprietárias, muitas das quais não rodam no Linux. Mesmo que o sistema de compilação do kernel do Linux pudesse compilar firmware automaticamente a partir do código fonte durante o processo de compilação do kernel, obviamente isso não seria possível em todos os casos. Logo, o firmware para os diferentes periféricos é distribuído com o kernel do Linux como um conjunto de arquivos binários, e é chamado de “firmware binário”.

No meu entendimento, os fabricantes poderiam disponibilizar o código fonte do firmware de seus dispositivos, mesmo que o kernel tivesse que incluir o firmware em formato binário devido às limitações do compilador. Nesse caso, continuaria sendo complicado alterar o código, mas ao menos isso seria possível para quem tivesse a habilidade e as ferramentas necessárias. Não sei dizer com certeza, mas acho que a FSF não teria problema com o firmware se a situação fosse essa. Infelizmente, até onde eu sei, nós não vivemos em um mundo no qual esse tipo de coisa aconteça com muita frequência.

Se ter o código fonte disponível para todo o firmware binário fosse o centro da política da FSF, eu não discordaria deles de maneira alguma. O que pega para mim é o fato da FSF fazer uma lista negra de drivers específicos com base na forma como o firmware binário de cada um é distribuído, em vez de se concentrar no verdadeiro problema: a disponibilidade do código fonte do firmware. E ao mirar no problema errado, ela também está dando sua aprovação aos dispositivos que usam firmware igualmente fechado, ou até mais fechado, do que o dos dispositivos que estão na lista negra. Permitam-me explicar isso.

Como o chip do periférico obtém o firmware do qual precisa?

1. Uma possibilidade é o firmware ser programado diretamente no chip que precisa dele. Esse é o caso de várias soluções baseadas em microcontroladores e FPGAs/Flash. É comum a memória interna ser protegida de forma que torne praticamente impossível acessá-la ou alterá-la por meio de acesso externo. Em alguns casos, como em circuitos ASIC ou em peças remanufaturadas, chega a ser impossível dizer até qual é a arquitetura usada pelo chip; o firmware usado, então, nem se fala.

2. Outra possibilidade é o firmware ser programado em um chip de memória que é parte da placa do periférico, mas externo ao chip que vai usar o código. Alguns dispositivos baseados em microprocessadores, microcontroladores e FPGAs/SRAM usam essa opção. Geralmente é possível ler o código do chip de memória e, com as ferramentas de software certas para o chip e um programador para o chip de memória, você pode até carregar seu próprio código de firmware.

3. A terceira opção é o chip incluir um gerenciador de inicialização que peça ao PC que forneça o firmware do qual precisa para fazer seu trabalho. Se o PC estiver rodando Linux, o kernel recebe a solicitação e tenta localizar o firmware. Em seguida ele manda o firmware para o chip. Nesse momento, o chip começa a executar o firmware. Muitos fabricantes gostam desta opção, porque ela dá flexibilidade na atualização do firmware caso necessário – basta alterar um arquivo no PC, o que também economiza dinheiro, já que o periférico não precisa incluir um armazenamento não volátil.

E a sua liberdade?

Qual dos métodos de armazenamento de firmware binário descritos acima lhe parece mais livre? Lembre-se, nenhum deles se qualifica como software livre, já que não há código fonte disponível. Mas é claro que alguns são mais acessíveis.

Na opção 1, você não tem como acessar ou alterar o código. Na opção 2, com as ferramentas certas, você pode ler o código binário, e “desmontar” o código do firmware, ou então escrever um código todo novo e carregá-lo no dispositivo, se tiver uma ferramenta de programação. Na opção 3 você também pode fazer isso, mas nem precisa ter uma ferramenta que leia o código binário, porque o código está em um arquivo no seu computador. Como o kernel cuida do carregamento do firmware, a ferramenta de programação é dispensável. O código pode ser desmontado, ou então você pode criar um código do zero, e o firmware em execução no periférico pode ser alterado com a mera substituição do arquivo do firmware.

Parece-me óbvio que a opção 3 oferece mais liberdade, porque por ela é mais fácil ver o código e fazer alterações. Não é necessário nenhum hardware específico. Você só vai precisar de programas que montem e desmontem o código do dispositivo em questão para poder fazer as alterações que quiser. Pois essa é justamente a opção que a FSF desencoraja, taxando-a de incompatível com o software livre! Por quê? Por causa do método de distribuição. O firmware é distribuído com o kernel do Linux, e não na placa de circuito do dispositivo. Essa é a única diferença. Enquanto isso, a FSF nos encoraja a comprar outro hardware, que optou por uma forma menos acessível de distribuir seu firmware: trancado dentro do dispositivo. Firmware para o qual não há código fonte disponível, e sensivelmente mais difícil de ser acessado e alterado. Sim, esses dispositivos contam com a aprovação da FSF, mesmo que não haja código fonte disponível para seu firmware.

Eu acho que isso está totalmente errado. Como o código fonte do firmware não está disponível, todos esses dispositivos precisam ser tratados exatamente da mesma forma. Ou são todos bons, ou são todos ruins. A forma como o firmware é armazenado e distribuído é irrelevante. É claro que taxar todos os dispositivos que usam firmware binário como inaceitáveis não é uma opção, porque praticamente não teríamos hardware para rodar um sistema operacional totalmente livre. Em um nível ou outro, você sempre chega a um ponto onde as coisas ficam proprietárias e você perde o controle. No fim das contas, a computação é só a execução de algoritmos. Se isso é feito em termos de hardware ou software é apenas um detalhe de implementação. Que diferença faz se um periférico implementa seus algoritmos funcionais totalmente por meio do hardware, de forma inacessível, e o driver associado é declarado “livre”, enquanto outro periférico implementa exatamente o mesmo algoritmo parcialmente via software, e seu respectivo driver é declarado como “não livre” porque o periférico precisa receber um punhado de bits representando seu algoritmo primeiro?

Para qualquer desenvolvedor de software embarcado, a segunda opção é muito mais livre. Para todo o resto, que não conta com a habilidade para configurar as ferramentas necessárias, as duas opções dão no mesmo com respeito à liberdade. De um jeito ou de outro, as pessoas só têm acesso ao driver do lado do PC. Na verdade, o driver pode ser igual, e agir exatamente do mesmo jeito para ambos os dispositivos, exceto pela parte na qual um deles precisa enviar um arquivo para o periférico para poder começar a conversar com ele. Para o desenvolvedor do kernel, não há diferença em termos de liberdade. Dá no mesmo.

Avaliando o hardware de acordo com nossa liberdade

Sugiro o seguinte esquema de avaliação para determinar o grau de liberdade de um dispositivo, e o quanto um fabricante é simpático ao código aberto:

• O dispositivo de maior liberdade é o que usa uma arquitetura suportada por ferramentas abertas e que disponibilize o código fonte de seu firmware.

• Em segundo lugar está o dispositivo que disponibiliza o código fonte do firmware, mas que usa uma arquitetura que (ainda) não é suportada por ferramentas abertas.

• Em terceiro lugar, o dispositivo que tem o firmware integrado ou que usa um arquivo de firmware binário do kernel, e cujo fabricante permite que o firmware seja distribuído com o kernel do Linux. Esse é o caso tão propagandeado pela FSF, que promove a implementação integrada do firmware como “livre” e rotula a implementação carregada pelo kernel como “incompatível com o software livre”. Como eu já expliquei, na prática isso não faz diferença para nossa liberdade, sendo apenas um pequeno detalhe da implementação. Seja qual for o caso, nós não temos acesso ao código fonte. Seja qual for o caso, é muito fácil usar o dispositivo com nosso sistema operacional livre favorito (exceto, obviamente, se essa liberdade for negada de forma arbitrária não pelo fabricante do hardware, que merece elogios por permitir que o firmware seja distribuído livremente com o kernel, mas por uma distribuição Linux que diz estar “protegendo sua liberdade”).

• Em quarto lugar, temos o caso do firmware binário que precisa ser carregado pelo kernel, mas cujo fabricante não permite sua distribuição com o kernel. Isso é muito inconveniente, e o usuário tem que se virar para baixar o firmware e instalá-lo separadamente, ou até usar alguma ferramenta para extrair o firmware do driver do Windows. Nesse caso, o fabricante não merece os nossos elogios. Mas como culpá-lo? A FSF poria esses dispositivos em sua lista negra mesmo que o fabricante permitisse a distribuição do seu firmware com o kernel. Que diferença faz para eles?

• O pior caso é quando o firmware precisa ser carregado pelo kernel, mas ninguém conseguiu achar um jeito de obter o firmware. Se houver documentação pública sobre a arquitetura do dispositivo, é possível que alguém crie um firmware para dar suporte ao dispositivo. Se não houver documentação, alguém pode fazer engenharia reversa do firmware, mas isso é pouco provável. Dificilmente esse dispositivo poderá ser usado com um sistema operacional livre.

Conclusão

A liberdade, incluindo a liberdade do software, é importante. Mas o fato é que não existe liberdade total em nenhuma área da vida. Quando o assunto é computador, a não ser que você tenha software e hardware completamente abertos, incluindo o design dos chips que você usa, em um ponto ou outro você vai perder a sua liberdade. Vale a pena lutar o máximo possível por essa liberdade, mas criar regras arbitrárias para definir como algo não livre é distribuído não vai ajudar ninguém. Isso só nos afasta do verdadeiro problema. A realidade é que praticamente todos os dispositivos disponíveis hoje rodam internamente um firmware binário. É muita inocência fingir que não há problema se esse firmware estiver convenientemente armazenado longe da vista do seu PC, sem jamais tocar no seu disco rígido.

A postura atual da FSF é semelhante a de um exército que diz estar lutando contra um exército invasor, mas que só confronta os inimigos que estão com as armas na mão. Enquanto isso, vários outros soldados inimigos com as armas nas costas entram sem dificuldades. Quando questionados sobre o assunto, eles dizem que os que eles deixaram passar eram civis inofensivos, porque não estavam usando as armas. Enquanto isso, o verdadeiro problema é ignorado.

O resultado dessa regra sem sentido é que os usuários de dispositivos que exigem que o firmware seja carregado pelo kernel precisam passar pelo inconveniente de caçar esses arquivos, ou pior, são encorajados a comprar dispositivos com o mesmo firmware de código fechado trancado dentro deles. De um jeito ou de outro, o firmware de código fechado continua sendo executado no dispositivo do usuário. A única diferença é que o usuário que compra dispositivos cujo firmware é distribuído dentro do hardware é induzido a pensar que obteve algum tipo de liberdade. Com isso, saem por aí alardeando que estão usando um “sistema totalmente livre”, o que não é verdade.

Sugiro que, em vez de elaborar essas táticas fajutas e fingir que elas resolvem alguma coisa, haja um movimento para encorajar os fabricantes a abrir as especificações de seus chips e o código fonte do firmware, sem considerar se ele está dentro do dispositivo ou se é carregado pelo kernel. E vamos recomendar aos amigos os fabricantes que permitem que seu firmware binário seja convenientemente distribuído com o kernel do Linux, em vez puni-los colocando seus dispositivos numa lista negra. Esse pode ser o primeiro passo rumo a uma comunicação melhor com os fabricantes de hardware, o que por sua vez aumenta as chances de firmware realmente livre aparecer no futuro.

Créditos a Patrick Van Oosterwijck – distrowatch.com

Tradução por Roberto Bechtlufft <info at bechtranslations.com.br>