Existem Blobs Binários no Kernel Linux usado pelo Ubuntu?

Recentemente, em um dos grupos de Telegram que participo foi colocado em questão: O Kernel Linux contém ou não os polêmicos Blobs binários?

O Juca afirmou que sim, baseado num processo lógico indutivo, outro participante afirmou que não baseado em... Bem, ele apenas afirmou que não. Então decidi buscar algo que ajudasse a descobrir a verdade...

Para começar, o Ubuntu segue o mesmo procedimento do Debian para publicar seus pacotes. Todo pacote .deb é fruto de um pacote original vindo do upstream (projeto de origem, como Inkscape, GNOME, Linux,...) e modificações da distro, que você encontra em packages.debian.org ou packages.ubuntu.com em um "*.debian.tar.xz" ou "*.diff.gz"

Hoje, 19/nov/2017, encontrei os pacotes linux-image-4.9 no Debian stable e o linux-image-4.13 no Ubuntu xenial. O pacote "orig.tar.xz" do Debian já veio sem o diretório "firmware", que ainda existe no pacote "orig.tar.gz" do Ubuntu. Neste diretório estão todos ou boa parte dos Blobs. Entretanto apenas essa informação não confirma que os pacotes binários do Ubuntu contenham os Blobs. Para compilar o Linux com os firmwares é preciso passar a configuração "CONFIG_FIRMWARE_IN_KERNEL=y" para o builder. Os fontes do kernel não trazem essa configuração por padrão (massa) e, como é de se esperar, o Debian não adiciona essa diretriz em seus diffs, entretanto o diff do Ubuntu sim, adiciona os firmwares para todas as arquiteturas.

$ egrep -r '^\+{3} |CONFIG_FIRMWARE_IN_KERNEL *= *[yY]' . | grep -B1 CONFIG_FIRMWARE_IN_KERNEL
...diff:+++ linux-hwe-edge-4.13.0/debian.hwe-edge/config/amd64/config.common.amd64
...diff:+CONFIG_FIRMWARE_IN_KERNEL=y
--
...diff:+++ linux-hwe-edge-4.13.0/debian.hwe-edge/config/arm64/config.common.arm64
...diff:+CONFIG_FIRMWARE_IN_KERNEL=y
--
...diff:+++ linux-hwe-edge-4.13.0/debian.hwe-edge/config/armhf/config.common.armhf
...diff:+CONFIG_FIRMWARE_IN_KERNEL=y
--
...diff:+++ linux-hwe-edge-4.13.0/debian.hwe-edge/config/i386/config.common.i386
...diff:+CONFIG_FIRMWARE_IN_KERNEL=y
--
...diff:+++ linux-hwe-edge-4.13.0/debian.hwe-edge/config/ppc64el/config.common.ppc64el
...diff:+CONFIG_FIRMWARE_IN_KERNEL=y
--
...diff:+++ linux-hwe-edge-4.13.0/debian.master/config/amd64/config.common.amd64
...diff:+CONFIG_FIRMWARE_IN_KERNEL=y
--
...diff:+++ linux-hwe-edge-4.13.0/debian.master/config/arm64/config.common.arm64
...diff:+CONFIG_FIRMWARE_IN_KERNEL=y
--
...diff:+++ linux-hwe-edge-4.13.0/debian.master/config/armhf/config.common.armhf
...diff:+CONFIG_FIRMWARE_IN_KERNEL=y
--
...diff:+++ linux-hwe-edge-4.13.0/debian.master/config/i386/config.common.i386
...diff:+CONFIG_FIRMWARE_IN_KERNEL=y
--
...diff:+++ linux-hwe-edge-4.13.0/debian.master/config/ppc64el/config.common.ppc64el
...diff:+CONFIG_FIRMWARE_IN_KERNEL=y
--
...diff:+++ linux-hwe-edge-4.13.0/zfs/zfs_config.h.in
.../Makefile:# 1. Building kernel with CONFIG_FIRMWARE_IN_KERNEL=y -- $(fw-shipped-y) should

Talvez essa informação não seja suficiente para você. Justo... Então um amigo com uma máquina Ubuntu me fez o favor de executar "dpkg -L linux-image-*" e no resultado estavam dezenas de firmwares diretamente relacionados aos arquivos de blobs que localizei no tar.gz dos fontes. Faça você mesmo esse teste. É o mais simples e direto.

Então fica claro que o Ubuntu adiciona sim blobs ao pacote compilado entregue aos seus usuários.

Não podemos afirmar, apenas com essa analise, que o Debian não adiciona blobs, mas temos a declaração do projeto (validada pela FSF) de que todos os blobs foram removidos do kernel distribuído pelo Debian em 2011 e, caso seja necessário, os firmwares baseados em blobs binários estão no repositório "non-free" da distribuição.

Sim, tem Blobs, e o que isso significa?

Para começar Blobs binários nunca deveriam ter entrado no repositório do projeto Linux simplesmente porque estes são incompatíveis com a definição de Software Livre e de Código Aberto. Especificamente na liberdade 1 "A liberdade de estudar como o programa funciona, e adaptá-lo às suas necessidades" e no critério 2 "Source Code (...) Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed."

Blobs, como qualquer software fechado, representa um limite praticamente intransponível a auditabilidade (a não ser que vc tenha MUITO tempo e dinheiro). Significa que nem você e nem o seu amigo super-mega-hacker podem afirmar que sabem exatamente o que um Blob faz, simplesmente porque você não sabe o que longas cadeias binárias como "1000 9000 0204 007C 1217 0000 0204 0080 2217 00F6" significam. E, seja lá o que for, ele faz com permissões de superusuário (isso se ele estiver limitado a userland) ou com poder total em um processador dedicado (que é o caso dos firmwares).

Blobs são uma forma de restringir a principal ação do ecossistema FOSS. Blobs impedem a validação, a colaboração e a evolução. Sabe a sua impressora que imprime melhor no Windows? Se o driver dela fosse livre poderíamos melhorar. Sabe a sua placa de vídeo que por um motivo desconhecido tem um FPS menor no Linux, ou superaquece, ou não responde adequadamente certas chamadas do OpenGL? Se o driver dela fosse livre poderíamos melhorar.

E quantos blobs temos hoje? No diretório firmware você encontra arquivos .HEX, .H16 e .ihex. Eu acabei de contar 141 deles aqui.

Poderíamos levantar algumas teorias da conspiração sobre por que a industria de hardware força a dependência dos blobs. A desculpa padrão (rápida, fácil e superficial) diz que é uma forma de garantir seu diferencial. Não... Vou me conter. A verdade é que mesmo achando essa desculpa inocente, nem eu nem ninguém, fora dos boards dessa indústria, sabe o real porquê. Independente que qual seja a verdade, ignorar, ou pior, negar o fato dos Blobs estarem presentes nas máquinas da maioria dos usuários de Linux não é só inocente ou contraprodutivo. É agir como fantoche do interesse alheio. É dificultar o processo de remoção do stack privativo/fechado que reduz a nossa autonomia, favorece oligopólios e ~~ajuda o controle estatal~~.