07 - Seleção do Dispositivo de Boot (Boot Order)

1. O Fim da Enumeração e o Início da Seleção Lógica

Após a conclusão da varredura de hardware e da inicialização das controladoras (Fase DXE em ambientes UEFI), o firmware possui um mapa topológico completo de todos os dispositivos elétricos conectados à máquina. O processador, a memória e os barramentos estão estabilizados. Contudo, o sistema ainda carece de um propósito lógico; ele precisa transferir o controle absoluto da CPU para um software mais complexo: o sistema operacional.

A ponte entre o hardware inicializado e o sistema operacional é gerenciada pela lógica de Seleção do Dispositivo de Boot (Boot Order ou Boot Sequence). A forma como essa seleção ocorre define uma das divisões arquiteturais mais profundas e críticas na história da computação, separando a abordagem empírica do BIOS legado da abordagem determinística da UEFI.

2. A Abordagem Legada: BBS (BIOS Boot Specification)

No ecossistema do BIOS tradicional, o firmware não possui a capacidade de compreender sistemas de arquivos. Portanto, a seleção de boot é um processo de tentativa e erro baseado em leitura crua de blocos lógicos. A padronização desse comportamento foi estabelecida pela especificação BBS (BIOS Boot Specification).

IPL (Initial Program Load) e BCV (Boot Connection Vector)

O BIOS categoriza os dispositivos elegíveis para boot em duas matrizes principais:

• Dispositivos IPL: São periféricos de armazenamento em bloco padrão, como discos rígidos IDE/SATA, unidades de disquete e CD-ROMs.

• Dispositivos BCV: São dispositivos complexos que injetaram Option ROMs na memória do sistema durante o POST, como placas de rede (para boot PXE) ou controladoras RAID de hardware. O BCV é um ponteiro que direciona a execução de volta para a ROM da controladora para que ela gerencie seu próprio subsistema de discos antes do boot final.

O Algoritmo de Tentativa e Erro (INT 19h)

O administrador define a ordem (ex: 1º CD-ROM, 2º USB, 3º HDD) no setup do CMOS. O algoritmo executado pelo BIOS via interrupção INT 19h opera estritamente da seguinte forma:

1. Emite um comando de leitura do LBA 0 (primeiro setor) para o primeiro dispositivo da fila.

2. Carrega os 512 bytes na memória RAM no endereço físico 0x7C00.

3. Inspeciona o final do bloco. Se a assinatura mágica de Boot Record (0x55AA) não estiver presente, o disco é considerado não inicializável.

4. O BIOS descarta o buffer, incrementa o índice para o próximo dispositivo da fila e repete o processo. Se todos falharem, o infame erro "Operating System not found" é exibido.

Este método obriga o BIOS a inicializar o primeiro código que encontre, resultando em extrema fragilidade, onde um disco secundário ou um pendrive formatado incorretamente poderia sequestrar a sequência de inicialização.

3. A Arquitetura UEFI e a Fase BDS (Boot Device Selection)

A UEFI trata a seleção de boot não como uma leitura cega de discos, mas como uma execução de aplicativos de forma semelhante a um sistema operacional. Na arquitetura UEFI, esta etapa é isolada em uma fase de execução específica chamada BDS (Boot Device Selection).

O BDS é um aplicativo UEFI nativo. Ele lê as variáveis globais estruturadas armazenadas na NVRAM para construir uma fila de execução determinística. Sob a UEFI, o sistema não inicializa discos, ele inicializa arquivos.

O Triunvirato das Variáveis de Boot

A lógica de decisão do BDS é controlada rigorosamente por um conjunto de variáveis indexadas na NVRAM:

1. BootOrder: Uma matriz de inteiros hexadecimais de 16 bits. Esta variável dita a ordem exata na qual o gerenciador de boot deve avaliar as entradas. Exemplo de valor em memória: 0002 0000 0001.

2. BootNext: Uma variável de uso único e mais alta prioridade. Se o Linux ou o administrador gravar um valor nesta variável (ex: 0005), no próximo reboot o firmware ignorará a BootOrder, tentará inicializar a entrada Boot0005 e, em seguida, apagará automaticamente a variável BootNext. É o mecanismo usado para forçar reinicializações para utilitários de firmware (como fwupd).

3. BootXXXX (Entradas de Carregamento): Variáveis individuais (como Boot0000, Boot0001, Boot0002) onde a carga útil de informação reside. Elas contêm a receita exata para encontrar e executar o bootloader.

4. Estrutura Anatômica de uma Entrada BootXXXX

Uma entrada de boot na NVRAM UEFI é uma estrutura de dados binária formalizada pela especificação EFI, chamada de EFI Load Option. Ela é muito mais complexa do que um simples apontamento de disco, contendo os seguintes campos:

• Attributes (Atributos): Uma máscara de bits (ex: LOAD_OPTION_ACTIVE). Se o bit ativo for zero, o firmware pulará a entrada sem deletá-la, útil para desativar temporariamente um sistema operacional.

• Description (Descrição): Uma string de texto legível por humanos (UTF-16) que o firmware exibe no menu visual da placa-mãe (ex: "Ubuntu", "Arch Linux", "GRUB").

• Device Path (Caminho do Dispositivo): Um array binário que traça a rota completa do barramento desde a CPU, passando pela controladora PCIe, porta SATA/NVMe, até a identificação algorítmica da Tabela GPT, a Partição de Sistema EFI (ESP) específica pelo seu UUID, e o caminho hierárquico de pastas até o arquivo executável (ex: \EFI\debian\grubx64.efi).

• Optional Data (Parâmetros de Linha de Comando): Qualquer espaço não utilizado no final da estrutura é considerado argumento de texto a ser passado diretamente para o binário .efi no momento da execução. O EFISTUB do Linux utiliza pesadamente este campo para receber parâmetros do kernel (como root=/dev/nvme0n1p2 quiet) diretamente do firmware, eliminando a necessidade de um bootloader intermediário.

5. O Mecanismo de Fallback Padrão (O Caminho Hardcoded)

Uma vulnerabilidade arquitetural do design orientado a variáveis na NVRAM é que, se a memória CMOS/Flash da placa-mãe for limpa (reset de fábrica) ou se o disco for movido fisicamente para outra máquina, as variáveis BootXXXX desaparecem. Sem um apontamento na NVRAM, o BDS ficaria paralisado, mesmo com um sistema operacional perfeitamente instalado no SSD.

Para resolver este problema e permitir o boot por mídias removíveis (como pendrives de instalação do Linux), a especificação UEFI dita um mecanismo de Fallback Padrão.

Se a BootOrder for exaurida sem sucesso, o BDS da UEFI irá iterar sobre todas as partições formatadas em FAT32 conectadas ao sistema. Em cada uma delas, ele procurará passivamente por um arquivo em um diretório e nome de arquivo rigidamente codificados na especificação (Default Removable Media Boot Path):

• Em sistemas de 64 bits (x86_64): \EFI\BOOT\BOOTX64.EFI

• Em sistemas ARM de 64 bits: \EFI\BOOT\BOOTAA64.EFI

• Em sistemas de 32 bits (legados): \EFI\BOOT\BOOTIA32.EFI

Instaladores do Linux e distribuições projetadas para máxima compatibilidade instalam uma cópia do GRUB ou do systemd-boot simultaneamente em /EFI/sua_distro/grubx64.efi (onde criam a variável na NVRAM) e também o clonam silenciosamente em /EFI/BOOT/BOOTX64.EFI. Isso garante que a máquina consiga recuperar o acesso ao disco de boot de forma transparente caso a NVRAM sofra corrupção.

6. Seleção de Boot por Rede (PXE - Preboot eXecution Environment)

A seleção de boot não se limita a discos locais. Em infraestruturas corporativas e datacenters de alta densidade operando Linux, a prioridade máxima na BootOrder costuma ser atribuída à Interface de Rede (NIC).

O firmware invoca o ambiente PXE utilizando um driver nativo UEFI UNDI (Universal Network Device Interface). A sequência de carregamento em rede diverge radicalmente do disco físico:

1. O firmware envia sinais de broadcast DHCP (Dynamic Host Configuration Protocol) na rede local (Porta UDP 68).

2. O servidor DHCP corporativo responde alocando um endereço IP para a máquina, além de injetar configurações adicionais cruciais: a Option 66 (Endereço IP do servidor TFTP local) e a Option 67 (O nome do arquivo a ser baixado, frequentemente chamado de NBP - Network Boot Program).

3. O firmware UEFI inicializa um cliente TFTP primitivo em RAM, conecta-se ao servidor especificado pela Option 66, faz o download do binário definido na Option 67 para o espaço de endereçamento principal e o executa.

7. Handover: A Chamada LoadImage e StartImage

Quando o algoritmo BDS finalmente localiza um binário de boot funcional (seja na ESP mapeada pela NVRAM, no caminho de Fallback, ou via download PXE), a seleção de dispositivo é formalmente encerrada.

A transferência de controle do firmware para o software obedece à API da UEFI. O firmware invoca dois serviços de inicialização sequenciais:

1. LoadImage(): A UEFI lê o arquivo do disco FAT32 e o carrega para um endereço seguro na memória RAM. O carregador analisa os cabeçalhos PE32+ para garantir que o binário foi compilado para a arquitetura correta e, em sistemas com o Secure Boot ativado, verifica a integridade da assinatura criptográfica X.509 antes de autorizar a permanência na RAM.

2. StartImage(): A UEFI constrói uma Tabela de Sistema (System Table) contendo os ponteiros para todos os serviços de Boot, serviços de Runtime e o mapa de memória física. Ela passa o endereço dessa tabela como argumento no registrador da CPU e executa um salto para o ponto de entrada do aplicativo carregado.

Nesse instante, o gerenciador de boot (como o GRUB2 ou o systemd-boot) assume o topo da hierarquia de execução. O Boot Order cumpriu seu papel e o computador deixa a fase de firmware para adentrar o domínio do ecossistema Linux.