04 - Configuração de Módulos (-etc-modprobe.d-)

O subsistema de módulos do Linux é governado arquiteturalmente pelo mapeamento estático de dependências (modules.dep). Contudo, a necessidade de impor políticas administrativas dinâmicas — como forçar parâmetros de hardware, bloquear drivers instáveis ou alterar a sequência de inicialização não coberta por dependências simbólicas — exige uma camada de configuração no espaço do usuário (user-space). Essa camada reside no diretório /etc/modprobe.d/.

Historicamente, o Linux utilizava um arquivo monolítico (/etc/modprobe.conf). Com a adoção da suíte kmod, a arquitetura migrou para um modelo de diretório (drop-in directory), onde arquivos individuais com a extensão .conf são lidos e processados em ordem lexicográfica. Isso permite que gerenciadores de pacotes injetem políticas de módulos sem o risco de corromper configurações feitas pelo administrador.

Quando o utilitário modprobe é invocado (seja manualmente pelo usuário ou automaticamente pelo udev durante a detecção de hardware), ele compila as regras contidas em /etc/modprobe.d/*.conf em memória e altera seu comportamento padrão de inserção de código no Ring 0.

1. Diretiva options: Injeção Estática de Parâmetros

A maioria dos device drivers expõe variáveis internas que podem ser ajustadas no momento da inicialização (visíveis via modinfo <modulo>). A diretiva options permite definir permanentemente esses parâmetros, instruindo o modprobe a anexá-los à chamada de sistema init_module().

Sintaxe: options <nome_do_modulo> <parametro_1>=<valor> <parametro_2>=<valor>

Exemplo:

Plaintext

options iwlwifi 11n_disable=1 power_save=0

Neste cenário, ao carregar o driver da placa de rede Intel (iwlwifi), o modprobe passa os parâmetros para desabilitar o protocolo 802.11n e o modo de economia de energia.

Hierarquia de Sobrescrita: É crucial notar que parâmetros definidos em /etc/modprobe.d/ possuem precedência sobre os padrões compilados no driver, mas são sobrepostos por parâmetros passados diretamente na linha de comando do kernel (via GRUB) no formato <modulo>.<parametro>=<valor>.

2. Diretiva blacklist: Oclusão Baseada em Alias

A diretiva blacklist é frequentemente mal compreendida. Seu propósito primário é impedir que o daemon de gerenciamento de dispositivos (udev) carregue automaticamente um módulo baseado na identificação de barramento (PCI/USB ID).

Sintaxe: blacklist <nome_do_modulo>

Mecanismo de Ação:

Quando o hardware é descoberto, o kernel emite um uevent. O udev intercepta este evento e executa algo como modprobe pci:v000010DEd00001C2D.... O modprobe verifica seus índices (modules.alias.bin) e descobre que o módulo correspondente é o nouveau (driver genérico NVIDIA). Se houver uma diretiva blacklist nouveau, o modprobe aborta silenciosamente a operação.

Limitação Crítica: O blacklist não proíbe o carregamento explícito do módulo, nem impede que ele seja carregado como dependência de outro módulo. Se o administrador executar modprobe nouveau, ou se um módulo "B" depender explicitamente de nouveau, o módulo será carregado em memória ignorando o blacklist.

3. Diretivas install e remove: Interceptação Absoluta (Hooks)

Para cenários onde o controle absoluto sobre o ciclo de vida do módulo é necessário, o modprobe fornece a diretiva install (e sua contraparte remove). Quando essas diretivas são declaradas, o modprobe descarta seu comportamento padrão (ler o arquivo .ko e injetar na memória) e, em vez disso, executa um comando arbitrário via /bin/sh -c.

Sintaxe: install <nome_do_modulo> <comando_shell>

Caso de Uso A: Bloqueio Forte (Hard Blacklist)

Como o blacklist tradicional pode ser contornado, a diretiva install é usada para criar uma barreira intransponível (frequentemente exigida por políticas de hardening de segurança, como o CIS Benchmarks, para desabilitar sistemas de arquivos obsoletos).

Plaintext

install cramfs /bin/false

Ao tentar carregar o módulo cramfs, o sistema simplesmente executa /bin/false, que retorna um código de saída de erro (1). O módulo nunca é lido pelo kernel, mesmo se for dependência de outro.

Caso de Uso B: Encadeamento Customizado

Plaintext

install snd-pcm /sbin/modprobe --ignore-install snd-pcm && /sbin/modprobe snd-pcm-oss

Neste cenário exótico, a tentativa de carregar snd-pcm é interceptada. O shell executa o carregamento real do snd-pcm usando a flag crítica --ignore-install (para evitar um loop infinito de recursão sintática) e, logo em seguida, engatilha o carregamento de um módulo complementar de compatibilidade.

4. Diretiva alias: Abstração de Nomenclatura

A diretiva alias permite que um nome arbitrário ou um identificador de protocolo seja mapeado para um binário de módulo real. Isso permite que aplicações de espaço de usuário solicitem serviços ao kernel genéricos, sem precisar conhecer a arquitetura do driver subjacente.

Sintaxe: alias <nome_fantasia> <nome_do_modulo_real>

Exemplo:

Plaintext

alias net-pf-10 ipv6

Quando uma aplicação tenta abrir um socket AF_INET6 (família de protocolos de rede 10), o kernel solicita o módulo net-pf-10. O modprobe intercepta o pedido e o redireciona para o binário real do módulo ipv6.ko.

5. Diretiva softdep: Orquestração Semântica de Carga

Enquanto o modules.dep gerencia dependências duras (hard dependencies — dependências por símbolos C exportados), a diretiva softdep define dependências comportamentais (soft dependencies). Ela força a ordem de inicialização entre módulos que não compartilham chamadas de função diretas, mas que precisam estar presentes em conjunto para o funcionamento de um subsistema lógico.

Sintaxe: softdep <modulo_alvo> pre: <modulos_antes> post: <modulos_depois>

Exemplo:

Plaintext

softdep vfio-pci pre: vfio_virqfd

Ao inicializar o driver de passthrough de PCI (vfio-pci), o modprobe garantirá que a estrutura de interrupções virtualizadas (vfio_virqfd) seja carregada primeiro, garantindo a integridade do barramento lógico, mesmo que o código compilado do vfio-pci não dependa diretamente de símbolos do vfio_virqfd.

6. A Armadilha do Initramfs (Visibilidade de Configuração)

Um erro operacional clássico em engenharia de sistemas Linux ocorre quando políticas definidas em /etc/modprobe.d/ parecem ser ignoradas pelo kernel durante a fase de inicialização (por exemplo, um driver de vídeo "blacklisted" que continua alterando a resolução do console durante o boot).

A Mecânica do Problema: Arquivos vitais para montar a partição raiz (como drivers AHCI/SATA, NVMe, Ext4 ou módulos de criptografia DRM) são carregados pelo kernel antes do sistema de arquivos físico raiz (/) estar disponível. Para fazer isso, o kernel utiliza um sistema de arquivos temporário injetado na RAM pelo bootloader: o initramfs.

A Solução: Se uma regra em /etc/modprobe.d/ envolver um driver de carregamento prematuro, a regra deve ser fisicamente copiada para dentro da imagem do initramfs. Toda vez que uma configuração crítica for alterada no disco (como isolar um módulo problemático de controladora RAID), o administrador é obrigado a regenerar a imagem do boot executando ferramentas como dracut -f (sistemas RHEL/Fedora), update-initramfs -u (sistemas Debian/Ubuntu) ou mkinitcpio -P (sistemas Arch), embutindo o diretório .conf dentro do ambiente temporário para que seja visível nos primeiros milissegundos de execução do kernel.