04 - UEFI (Unified Extensible Firmware Interface)

1. A Ruptura de Paradigma: De Firmware Estático a Mini-Sistema Operacional

A UEFI (Unified Extensible Firmware Interface) não é uma simples evolução iterativa do BIOS legado; trata-se de uma reengenharia completa da fronteira entre o hardware e o sistema operacional. Concebida originalmente pela Intel como Intel Boot Initiative (e mais tarde EFI), a arquitetura UEFI foi projetada para eliminar de forma absoluta as restrições arcaicas do Modo Real de 16 bits, o limite de endereçamento de 1 Megabyte e a dependência de vetores de interrupção em código de máquina cego.

Em sua essência, a UEFI opera como um micro-sistema operacional. Ela é escrita predominantemente em linguagem C de alto nível, ao invés de código Assembly monolítico, o que lhe confere um design extensível e modular. Diferente do BIOS, que passava o controle para o bootloader ainda em 16 bits, o firmware UEFI inicializa a CPU rapidamente para o Modo Protegido (32 bits) ou Modo Longo (64 bits), possuindo acesso irrestrito a toda a memória RAM instalada no sistema logo nos primeiros estágios do boot.

Outra diferença arquitetural crítica é o formato dos binários suportados. A UEFI não executa mais blocos de código de 512 bytes no formato raw inseridos no primeiro setor do disco. Em vez disso, o firmware possui um carregador nativo capaz de compreender e executar binários padronizados no formato PE32+ (Portable Executable, o mesmo formato base dos executáveis do Windows, adaptado para a plataforma EFI). Qualquer bootloader de Linux em um sistema moderno é, tecnicamente, um aplicativo EFI (com a extensão .efi).

2. O Ciclo de Vida de Execução (Fases PI - Platform Initialization)

A inicialização do sistema sob o protocolo UEFI é rigorosamente dividida em fases discretas e lógicas, documentadas pela especificação PI (Platform Initialization). Cada fase tem um nível de privilégio e responsabilidades específicas:

• SEC (Security Phase): É a fase de nível mais baixo. Ela recebe o controle direto do vetor de reset do hardware. Sua missão é estabelecer as raízes de confiança (Root of Trust) básicas, inicializar temporariamente o microcódigo do processador e configurar a técnica de Cache-as-RAM (CAR) para permitir a execução de código em C antes que a memória RAM principal esteja disponível.

• PEI (Pre-EFI Initialization Phase): Focada na inicialização do silício principal. Ocorre aqui o treinamento da memória DRAM (via Memory Reference Code - MRC), o mapeamento inicial do chipset e a transição do ambiente temporário em Cache para a RAM física verdadeira.

• DXE (Driver Execution Environment): A fase mais densa e crítica. O ambiente UEFI está totalmente operacional. O despachante do DXE carrega centenas de drivers modulares em memória. O firmware descobre os barramentos PCIe, placas de vídeo (via driver GOP), controladoras de disco (SATA/NVMe) e interfaces de rede. É nesta fase que a UEFI obtém a capacidade de montar sistemas de arquivos.

• BDS (Boot Device Selection): Com o hardware mapeado, o firmware lê as variáveis armazenadas na NVRAM para determinar a política de boot. Ele localiza os dispositivos de armazenamento válidos e monta a Partição de Sistema EFI para procurar o binário do gerenciador de boot do sistema operacional.

• TSL (Transient System Load): O firmware entrega o controle para o aplicativo EFI selecionado (por exemplo, o GRUB2 ou o próprio Kernel Linux via EFISTUB). Durante esta fase, o bootloader ainda pode usar os serviços da UEFI para ler arquivos e imprimir dados na tela, mas ele está se preparando para assumir o controle total.

• RT (Run Time): O sistema operacional está rodando. Os serviços de boot foram permanentemente encerrados, mas um subconjunto de serviços da UEFI permanece residente em memória para comunicação de baixo nível com o hardware.

3. O Gerenciador de Boot Integrado e as Variáveis NVRAM

O BIOS tradicional delegava inteiramente a inteligência de seleção de boot para o disco (lendo o primeiro setor que encontrasse e transferindo a execução). A UEFI, por outro lado, possui seu próprio Boot Manager embutido nativamente no firmware.

O firmware mantém um banco de dados de variáveis persistentes dentro da memória não volátil (NVRAM) da placa-mãe. Essas variáveis ditam com exatidão matemática o comportamento da inicialização. No Linux, a interação ocorre através de utilitários como o efibootmgr.

As variáveis principais de controle de boot seguem uma nomenclatura estrita:

• BootOrder: Uma matriz que define a sequência de tentativa de boot (ex: 0001, 0000, 0002).

• Boot0000, Boot0001, etc.: Variáveis indexadas que contêm caminhos absolutos para executáveis .efi dentro de discos específicos. Ao invés de apontar cegamente para um disco físico, uma entrada UEFI aponta para a exata assinatura UUID de uma partição e o caminho exato do arquivo (ex: \EFI\debian\grubx64.efi).

Essa capacidade elimina a "guerra de bootloaders" no MBR, permitindo que múltiplos sistemas operacionais coexistam de forma civilizada na mesma máquina, cada um com sua própria entrada estruturada na NVRAM.

4. A Ponte Logica: A Partição de Sistema EFI (ESP)

Para que o firmware UEFI consiga executar arquivos sem depender de hacks de setores brutos, ele precisa obrigatoriamente de um meio de armazenamento formatado em um sistema de arquivos que ele compreenda nativamente. A especificação obriga que todo firmware UEFI suporte, no mínimo, o sistema de arquivos FAT12, FAT16 e FAT32.

Cria-se então a ESP (EFI System Partition). Trata-se de uma pequena partição primária no disco (geralmente formatada em FAT32 e com tamanho entre 100MB e 500MB), identificada por um GUID específico (em tabelas GPT) ou por um ID hexadecimal (em tabelas MBR legadas, embora raro em UEFI puro).

A ESP atua como o ponto de encontro diplomático entre o firmware e o sistema operacional. Quando instalamos o Linux (como Ubuntu, Arch ou Red Hat), o instalador copia o binário do gerenciador de boot (como grubx64.efi ou systemd-bootx64.efi) para dentro do diretório /EFI/ desta partição em formato FAT32. Quando o sistema liga e chega na fase BDS, a UEFI monta a ESP nativamente, navega até a pasta e executa o binário contido nela. Sem a ESP, a UEFI é cega para os sistemas de arquivos complexos (ext4, xfs) onde reside o resto do kernel Linux.

5. Serviços de Boot (BS) vs Serviços de Runtime (RS)

A interface que a UEFI oferece aos aplicativos carregados divide-se estritamente em duas categorias operacionais:

1. Boot Services (Serviços de Inicialização): Compreendem alocação de memória complexa, primitivas de desenho em tela (GOP), leitura de eventos do teclado e acesso a arquivos na ESP. Esses serviços existem exclusivamente enquanto o bootloader está trabalhando. Quando o kernel Linux está pronto para assumir o controle definitivo do hardware, ele invoca uma função obrigatória chamada ExitBootServices(). Ao executar essa chamada, o kernel "expulsa" o ambiente DXE/BDS da memória. O firmware destrói os ponteiros dos Boot Services e repassa a tabela de mapas físicos de memória para o Linux. A partir deste momento, não há retorno ao firmware sem um reset elétrico da máquina.

2. Runtime Services (Serviços de Execução): Um conjunto muito menor e restrito de rotinas de firmware que sobrevivem à chamada ExitBootServices() e permanecem ativas, mapeadas em áreas de memória protegidas, em paralelo com o sistema operacional. O Linux os acessa para tarefas de hardware profundo e invariável, como ler o Relógio de Tempo Real (RTC), realizar atualizações de cápsulas de firmware (Capsule Updates via fwupd) e, mais criticamente, para manipular as variáveis EFI na NVRAM através da montagem virtual /sys/firmware/efi/efivars.

6. O Fim do Legado: Classes UEFI e CSM

Para permitir uma transição suave da indústria, as primeiras especificações UEFI introduziram o CSM (Compatibility Support Module). O CSM era um emulador de hardware embutido na UEFI que recriava perfeitamente a Tabela de Vetores de Interrupção (IVT) do Modo Real de 16 bits do BIOS, permitindo a instalação de sistemas operacionais arcaicos que desconheciam o formato EFI.

No entanto, a arquitetura de firmware é classificada por níveis evolutivos:

• Classe 0: BIOS legado puro (obsoleto).

• Classe 1: UEFI operando unicamente em modo de compatibilidade CSM (ausência de boot nativo EFI).

• Classe 2: UEFI com suporte dual (Boot Nativo EFI + CSM Ativável). Foi o padrão de mercado de 2010 até meados de 2020.

• Classe 3: UEFI puro. O módulo CSM foi extirpado do código do firmware. Executa exclusivamente binários PE32+.

• Classe 3+: UEFI puro com exigência compulsória de Secure Boot ativado (sem opção de desabilitação pelo usuário convencional, restrito a OEMs restritivos).

A indústria de hardware atual adota a Classe 3, impossibilitando de maneira definitiva a inicialização de sistemas operacionais via MBR/Boot Sector clássico. O kernel Linux moderno e bootloaders como o GRUB2 estão nativamente desenhados para ambientes Classe 3, aproveitando a segurança criptográfica, o endereçamento linear e a inicialização paralelizada inerentes à plataforma UEFI.