BIOS vs. UEFI
O firmware é o primeiro código a rodar em qualquer máquina x86, e sua escolha de interface, BIOS legada ou UEFI moderna, molda quase tudo sobre como um kernel é carregado antes de poder começar a gerenciar a própria máquina. As duas diferem em esquema de particionamento, em qual estado deixam a CPU, e em quanto do processo de carregamento realizam em nome de um kernel.
Um sistema baseado em BIOS localiza um dispositivo de boot lendo seu primeiro setor de 512 bytes, o Master Boot Record, verificando a assinatura de boot 0x55, 0xAA em seu final, e se presente, carregando o setor inteiro para o endereço físico 0x7C00 e saltando para ele, ainda em real mode de 16 bits, com acesso a disco disponível apenas através de serviços de interrupção da BIOS (int 0x13), não qualquer driver que o próprio código de boot forneça. Particionamento sob esse esquema usa a tabela de partição MBR, embutida no mesmo setor de 512 bytes que o código de boot, limitando um disco a quatro partições primárias (partições estendidas contornam isso na prática) e, mais consequentemente para discos muito grandes, uma contagem de setores de 32 bits que limita um disco endereçável por MBR a 2 TB. A própria BIOS nunca foi formalmente especificada por um único órgão de padrões da forma que a UEFI é; é melhor entendida como uma convenção de longa vida, informalmente padronizada, que cada fabricante de firmware implementou de forma compatível com o comportamento original do IBM PC.
A UEFI (Unified Extensible Firmware Interface) substitui isso por um modelo consideravelmente mais estruturado. Em vez de um boot sector bruto de 512 bytes, um sistema UEFI localiza e executa diretamente um executável no formato PE .efi (convencionalmente \EFI\BOOT\BOOTX64.EFI como padrão de fallback), a partir de uma EFI System Partition formatada em FAT32 em um disco particionado com GPT, que usa endereçamento de setor de 64 bits e remove as limitações de quatro partições e 2 TB do MBR. De forma crítica, o firmware UEFI roda código de tempo de boot em um modo de endereçamento plano e não segmentado, já próximo do que um kernel de 32 ou 64 bits espera, em vez de real mode de 16 bits: código de aplicação UEFI é código de máquina comum chamável de C desde o início, não assembly de real mode, e a UEFI adicionalmente expõe um conjunto definido de boot services (alocação de memória, o mapa de memória, I/O de arquivo e disco) como funções chamáveis, em vez da interface mais ad hoc de interrupção de software que a BIOS fornece.
Diferenças práticas para um kernel
Seção intitulada “Diferenças práticas para um kernel”Os dois caminhos levam a condições iniciais significativamente diferentes para um kernel ou bootloader. Código de boot BIOS herda real mode e precisa realizar as transições de protected/long mode por conta própria, ou depender de um bootloader que o faça; código de boot UEFI começa já além dessa fronteira, em um ambiente plano de 32 ou 64 bits, embora ainda precise chamar explicitamente ExitBootServices antes que o gerenciamento de memória e os serviços do próprio firmware possam ser considerados totalmente cedidos ao SO. A descoberta de memória difere correspondentemente: código da era BIOS recupera um mapa de memória via int 0x15, EAX=0xE820, enquanto código UEFI chama GetMemoryMap, mecanismos diferentes que servem ao mesmo propósito descrito em Memória Física. Um bootloader compatível com Multiboot, como o GRUB, pode ter como alvo qualquer um dos dois tipos de firmware e normaliza a maior parte dessa diferença para o kernel, ao custo de depender daquele bootloader em vez de controlar diretamente a interação com o firmware.
Secure Boot
Seção intitulada “Secure Boot”A UEFI define adicionalmente o Secure Boot, um mecanismo opcional que verifica a assinatura criptográfica de um executável de boot contra um conjunto de chaves em que o firmware confia antes de executá-lo, destinado a prevenir que código de boot não assinado ou adulterado rode. O próprio bootloader ou executável .efi de um kernel hobby não é, por definição, assinado por chave alguma em que o firmware já confie, o que geralmente significa desabilitar o Secure Boot nas configurações de firmware para desenvolvimento, ou providenciar separadamente para assinar o executável de boot e registrar uma chave correspondente, um passo sem equivalente algum sob BIOS legada, que não tem conceito comparável de verificação.
Notas de implementação
Seção intitulada “Notas de implementação”Fabricantes de firmware cada vez mais descontinuam por completo o suporte a BIOS legada em favor de um “CSM” (Compatibility Support Module), um recurso UEFI que emula boot no estilo BIOS para sistemas operacionais mais antigos, ou abandonam totalmente o boot em modo BIOS, o que torna a UEFI o alvo mais à prova de futuro para novo desenvolvimento de kernel, mesmo que o caminho BIOS/MBR permaneça extremamente bem documentado e, na maioria dos emuladores, marginalmente mais simples de fazer funcionar um primeiro boot. Testar contra os dois caminhos cedo, em vez de se comprometer exclusivamente com um, evita uma reescrita depois, caso o suporte de firmware para o caminho escolhido se torne indisponível no hardware real contra o qual o kernel é eventualmente testado.
Referências
Seção intitulada “Referências”- ^ Especificação UEFI: a especificação formal que governa boot services UEFI, GPT, e Secure Boot.
Ver também
Seção intitulada “Ver também”- The Boot Process: a sequência mais ampla do firmware à entrada do kernel da qual este artigo faz parte.
- Bootloaders: a camada que comumente normaliza a diferença descrita acima, escondendo-a do kernel.
- Tabelas de Partição, MBR e GPT: os dois esquemas de particionamento nomeados acima, cobertos por completo.
- Escrevendo um Bootloader UEFI: o formato de aplicação PE32+ e a API de Boot Services que a seção UEFI deste artigo só resume.