05 - CMOS e NVRAM (Configurações Armazenadas)

1. A Necessidade Arquitetural da Persistência de Estado

Embora o código binário do firmware (BIOS ou UEFI) seja gravado em um chip de memória de leitura (Flash ROM), ele não é um sistema rígido e imutável. Para que uma placa-mãe possa operar de forma flexível em diferentes cenários, o firmware exige a capacidade de armazenar e recuperar o estado da configuração entre os ciclos de energia mecânica (estado ACPI G3).

Essa persistência de dados é o que permite ao hardware lembrar a sequência exata de discos para o boot, os parâmetros de tensão e latência aplicados à memória RAM (perfis XMP/EXPO), as chaves criptográficas de segurança e a data e hora do relógio do sistema. A evolução desta camada de armazenamento reflete diretamente a transição das limitações do BIOS legado para a complexidade orientada a objetos da UEFI.

2. A Era Legada: CMOS e SRAM Suportada por Bateria

Em sistemas baseados em BIOS tradicional, o armazenamento de configurações era indissociável do componente de Relógio de Tempo Real (RTC - Real Time Clock). Historicamente derivado do chip Motorola MC146818 no IBM PC original, este circuito possuía um minúsculo banco de memória estática (SRAM) integrado, variando de meros 64 bytes a 256 bytes físicos.

Esta arquitetura introduziu o termo CMOS (Complementary Metal-Oxide-Semiconductor), que tecnicamente descreve o processo de fabricação dos transistores do chip, mas tornou-se o jargão do mercado para se referir ao armazenamento de configurações do BIOS em si.

A SRAM tem uma característica elétrica fundamental: ela é volátil e exige tensão elétrica contínua para manter o estado binário de suas portas lógicas. Para garantir que as configurações do BIOS sobrevivessem ao desligamento da fonte de alimentação principal, a placa-mãe dependia inteiramente de uma bateria de célula tipo moeda (quase invariavelmente uma bateria de Lítio de 3 Volts, modelo CR2032).

• Limitações: O tamanho restrito obrigava o BIOS a armazenar configurações como bitfields ou variáveis indexadas de 1 byte. Não havia espaço para strings de texto ou caminhos de arquivos.

• Vulnerabilidade Física: Se a bateria CR2032 descarregasse ou fosse fisicamente removida, o banco de capacitores do circuito RTC esvaziava-se. A SRAM perdia imediatamente sua carga elétrica e, consequentemente, todos os dados de configuração armazenados. Ao reiniciar, o BIOS detectava o checksum de memória inválido e entrava no modo Failsafe/Default, forçando o usuário a reconfigurar relógio e ordem de boot.

• O Jumper "Clear CMOS": Fabricantes incluíam um jumper físico (uma ponte de curto-circuito) na placa-mãe. Ao conectar os pinos, o circuito aterrava a linha de energia da SRAM, destruindo intencionalmente os dados instantaneamente para recuperar placas-mãe travadas por overclock mal-sucedido.

3. A Modernização: NVRAM e Memória Flash SPI

Com a ascensão da UEFI, o espaço ínfimo de 256 bytes do CMOS legado tornou-se matematicamente incapaz de abrigar a estrutura complexa de dados exigida. A indústria abandonou o uso de memória SRAM dependente de bateria para salvar configurações de firmware.

Em placas-mãe modernas, as configurações são armazenadas na NVRAM (Non-Volatile Random-Access Memory). Fisicamente, a NVRAM não é um chip separado, mas sim uma partição dedicada dentro do mesmo chip de memória SPI Flash ROM de alta densidade (16MB a 64MB) que hospeda o código binário principal da UEFI.

• Persistência Genuína: Como é baseada em tecnologia de portões flutuantes (EEPROM/Flash), a NVRAM retém os dados indefinidamente, mesmo na ausência absoluta de energia elétrica.

• A Falácia da Bateria Moderna: É um erro conceitual comum acreditar que remover a bateria CR2032 de uma placa-mãe UEFI moderna apagará as configurações de boot. A bateria atual serve exclusivamente para alimentar o oscilador de cristal do Relógio de Tempo Real (RTC). Variáveis UEFI, ordem de boot e chaves Secure Boot permanecem intactas na NVRAM Flash, independentemente do status da bateria. Para limpar a NVRAM quando o sistema não dá boot (o equivalente moderno ao Clear CMOS), o jumper da placa-mãe agora aciona um pino de hardware do chipset (PCH) que instrui o firmware a reescrever o bloco Flash com os padrões de fábrica no próximo POST.

4. O Paradigma Orientado a Objetos: Variáveis UEFI

A UEFI organiza a NVRAM utilizando um sistema de arquivos chave-valor estruturado. Diferente dos bytes crus do CMOS, os dados na NVRAM são chamados de Variáveis UEFI e possuem um cabeçalho descritivo complexo composto por três elementos cruciais:

1. Vendor GUID (Globally Unique Identifier): Um identificador de 128 bits que categoriza a quem pertence a variável (ex: Variáveis Globais de Boot, Variáveis exclusivas da Microsoft, Variáveis proprietárias da Dell/Lenovo).

2. Variable Name (Nome da Variável): Uma string legível, como Boot0000, BootOrder, SecureBoot ou Setup.

3. Data (Carga Útil): O valor armazenado (pode ser uma matriz de caminhos de dispositivos EFI, chaves criptográficas em formato X.509 ou booleanos simples).

Além disso, cada variável é salva com uma máscara de bits de atributos (Attributes), que determina o seu escopo de acesso:

• NV (Non-Volatile): A variável deve ser gravada na Flash física e sobreviver ao reboot.

• BS (BootServiceAccess): A variável está visível apenas durante o POST e a execução do bootloader.

• RT (RuntimeAccess): A variável continua visível e acessível para leitura/escrita mesmo após o kernel Linux assumir o controle total do hardware.

5. A Interface com o Kernel Linux: O Subsistema efivarfs

Uma das capacidades mais formidáveis da arquitetura Linux em ecossistemas UEFI é sua comunicação direta com a NVRAM física sem a necessidade de reiniciar o sistema ou entrar em telas gráficas de setup.

Quando o kernel Linux inicializa via EFI, ele lê a tabela de serviços de runtime fornecida pelo firmware. Utilizando esses serviços, o kernel monta um sistema de arquivos virtual (VFS) no espaço do usuário, tradicionalmente localizado em /sys/firmware/efi/efivars.

Neste diretório, cada arquivo que você visualiza é uma representação em tempo real de uma variável hospedada nos transistores físicos da placa-mãe.

• Leitura e Manipulação: Ferramentas utilitárias clássicas, como o efibootmgr, não modificam partições de disco. Elas interagem diretamente com o /sys/firmware/efi/efivars para criar, deletar ou reordenar as variáveis de boot (ex: alterando a variável BootOrder).

• Proteção contra Bricking (Imutabilidade): Histórica e tristemente, se uma aplicação de usuário gravasse lixo na NVRAM ou a enchesse até o limite físico de capacidade (alguns chips suportam apenas 64KB de espaço reservado para variáveis), o firmware não conseguiria alocar espaço para o próximo POST, travando a placa-mãe de forma irreparável em nível elétrico (um cenário catastrófico conhecido como brick). Para mitigar isso, os mantenedores do kernel Linux modificaram o módulo efivarfs para aplicar atributos de imutabilidade estrita do VFS (o equivalente a rodar chattr +i). O Linux recusa-se sumariamente a apagar a maior parte do conteúdo da NVRAM via comandos tradicionais (como rm -rf /), protegendo a sanidade do hardware.

6. O Pstore (Persistent Storage) e o Registro Post-Mortem

O Linux aproveita o fato de a NVRAM ser uma memória persistente à prova de desligamentos para implementar um de seus recursos de diagnóstico mais agressivos: o pstore (Persistent Storage).

Quando o subsistema do kernel sofre um colapso catastrófico incontornável — o temido Kernel Panic ou Oops —, os buffers de log em memória RAM (que continham as mensagens de erro críticas do dmesg) estão fadados a desaparecer no milissegundo em que a máquina reiniciar.

Se a máquina for uma servidora remota sem console visual (KVM) anexado, a causa do travamento seria um mistério total. Através do pstore (normalmente montado em /sys/fs/pstore), o kernel intercepta a exceção final de morte no processador. Antes de enviar o sinal de reinicialização de hardware elétrica, o kernel compacta rapidamente os últimos bytes cruciais do buffer de log de erros e utiliza os serviços de runtime da UEFI para forçar uma gravação síncrona desses bytes em uma área predefinida da NVRAM da placa-mãe.

Ao realizar o próximo ciclo de boot com sucesso, o novo kernel detecta que existe um log residual gravado na placa-mãe, extrai os dados para o espaço do usuário, registra o motivo exato da falha do boot anterior nos logs do systemd-journald e apaga a variável da NVRAM para liberar o espaço, demonstrando a perfeita simbiose entre as decisões de hardware e o rastreamento de software de baixo nível.