O padrão UEFI-BIOS

Em meados dos anos 1990, a Intel trabalhava junto com a HP no desenvolvimento da plataforma de servidores Itanium. Neste momento, as limitações do padrão IBM BIOS/MBR ficaram evidentes e uma nova tecnologia para BIOS/MBR tornou-se necessária.

A proposta da Intel foi publicada no ano de 2000 com a especificação "BIOS-EFI 1.2".

O BIOS-EFI funciona como uma API (Application Programming Interface), atuando entre o sistema operacional e o firmware da placa principal (Motherboard), como demonstra a figura 4.

Esta estrutura torna o O.S. Loader uma aplicação no topo da camada EFI. Por ser um ambiente completo, EFI inclui seu próprio ambiente em shell, os aplicativos executados no ambiente EFI são considerados aplicações pré-O.S.

O EFI permite, entre outras coisas, reduzir o tempo de carregamento dos sistemas operacionais, que estão cada vez maiores e mais pesados. O boot pré-O.S. permite incluir configurações de hardware, com o carregamento de drivers genéricos, antes do O.S. ser carregado, facilitando o plug-and-play. Em 2005, o desenvolvimento desta tecnologia migrou da Intel para o consórcio formado por 140 companhias da indústria de computadores: AMD, AMI, Apple, Dell, HP, IBM, Insyde, Intel, Lenovo, Microsoft, entre outras. A iniciativa é denominada de UEFI (Unified Extensible Firmware Interface), e encontra-se na versão 2.3.1 (Abril/2011).

A principal diferença entre o IBM-BIOS e o UEFI-BIOS, é que a nova tecnologia não tem qualquer relação com a arquitetura de 16 bits da IBM-BIOS, que obriga o processador ser inicializado em "modo real x86" endereçando apenas 1 MiB de RAM no momento do boot, fazendo o processador se comportar como o PC-XT (8088) de 1983.

Na especificação UEFI não há qualquer legado, apesar de haver compatibilidade retroativa em pontos muito específicos. A especificação UEFI-BIOS permite implementações de softwares em 32 ou 64 bits. Os binários UEFI (byte code) têm acesso a toda memória RAM, já no momento do boot.

Isso permite, por exemplo, criar um ambiente completo com ferramentas de reparo, ou diagnóstico, baseadas em software UEFI, que são independentes do carregamento do O.S., veja a figura figura 5.

Aplicativos UEFI também poderão se apresentar na forma de serviços que são executados como daemons tradicionais. Aplicativos UEFI são escritos na linguagem de programação C, portanto, são portáveis, diferente das BIOS que são escritas prioritariamente em linguagem de montagem Assembly e são vinculadas à arquitetura do hardware. Observe que UEFI não pretende substituir o software contido no firmware, mas funciona como uma extensão desse. Alguma aplicação é necessária para fazer a função de POST (Power-On Self Test) e a função do SETUP também continuará necessária.

UEFI pode ser implementado como uma camada no topo da BIOS legada (eliminando as instruções INT de 16 bits), ou assumir totalmente essa função em sistemas classe 3, que são BIOS-less.

As principais vantagens do UEFI, são:

• Capacidade para inicializar sistemas operacionais em discos rígidos maiores que 2 TiB, utilizando o particionamento GPT.
• Inclusão de capacidades nativas, como gerenciamento do hardware, suporte à rede, banco de dados e utilitários em ambiente pré-O.S.
• - Modularidade e expansão do modelo em várias direções e níveis.
• UEFI block I/O protocol, substitui as interrupções de BIOS, permitindo, por exemplo, o tráfego de 1 MiB de dados em tempo de boot, contra 64 KiB do método INT 13. Isto resulta em um processo de hibernação e uma retomada no boot muito mais rápidos.
• Uma interface EBC (EFI Byte Code) permite escrever drivers genéricos independentes da arquitetura do O.S. e da CPU.
• Um módulo CSM (Compatibility Support Module), permitindo a emulação de um sistema BIOS-MBR, garantindo que sistemas operacionais legados possam ser executados em hardware UEFI da classe 3, que são UEFI nativos.

Serviços UEFI

A especificação UEFI define dois tipos de serviços:

• Serviços em tempo de boot;
• Serviços em tempo de execução.

Grosso modo, podemos dizer que serviços em tempo de boot são executados na fase firmware do processo de boot. Os serviços em tempo de execução, auxiliam as operações do sistema operacional prestando serviços para o O.S., por exemplo, fornecendo data e hora atualizados por NTP. O ambiente UEFI tem potencial para assumir várias funções do O.S.

O ambiente UEFI pode funcionar também como um repositório de dados não voláteis para configurar o sistema operacional. Uma espécie de registro com chaves aos pares, do tipo nome=valor.

Um ambiente EBC (EFI Byte Code) pode prover drivers genéricos para configuração do hardware em tempo pré-O.S., isso facilitaria o reconhecimento do hardware pelo plug-and-play.

A possibilidade de ter suporte a vídeo, no padrão GOP (Graphics Output Protocol) eliminando a dependência atual do padrão VGA para dar partida em computadores.

O processo de boot UEFI puro, não possui um setor de inicialização nos moldes de MBR, nem um código de arranque (stage 1), como no modelo BIOS-MBR.

No padrão UEFI, os aplicativos de arranque são armazenados em uma partição FAT32, FAT16 ou até FAT12. Isso funciona de modo similar à fase 2 do stage do GRUB.

Durante o boot, o GRUB é capaz de ler diretamente o sistema de arquivos em /boot, procurando pelos arquivos "vmlinuz" e "initrd", pois GRUB "conhece" alguns dos principais filesystems do GNU/Linux.

O serviço mais polêmico fornecido por UEFI, tem sido o Boot Seguro. Vejamos como ele funciona.