Você sabe o que é BIOS?

Nos últimos anos temos acompanhado o grande crescimento da comunidade responsável pelo desenvolvimento de softwares/firmwares para a área de embarcados em todo o mundo, e no Brasil isso não é diferente. Grande parte disso se dá devido à possibilidade de rodar o S.O. Linux em plataformas minimalistas, facilitando assim o desenvolvimento de projetos sem a necessidade de adquirir softwares proprietários para cada equipamento vendido.

Porém, existe um tipo de software embarcado que foi de extrema importância durante a evolução da computação, e ainda é nos dias de hoje, que não tem recebido a atenção do público brasileiro. Esse embarcado é o BIOS!

A Origem do BIOS

O BIOS, sigla para “Basic Input and Output System”, é uma porção de firmware responsável pela inicialização básica da placa mãe de um determinado equipamento nas plataformas x86, ARM (alguns) e PowerPC, permitindo, assim, que a plataforma seja entregue ao software subsequente, seja ele um S.O. ou um bootloader, de uma forma padronizada. Dessa forma as complexidades específicas de uma dada plataforma são encapsuladas, facilitando o desenvolvimento e execução de drivers a nível de S.O.

Esse tipo de firmware, o BIOS, foi primeiramente desenvolvido pela IBM na década de 70, e não sofreu muitas alterações em sua arquitetura por várias décadas.

Embarcados Experience 2024: Evento Presencial

Participe do Embarcados Experience 2024 em São Paulo. Conhecimento técnico, palestras, workshops e oportunidade de networking com profissionais experientes.

Inscreva-se agora

BIOS Legacy

Certamente a maioria, se não todos, já entraram nas telas de setup do BIOS de algum equipamento. Essas telas têm por finalidade a configuração de alguns controladores existentes na plataforma, como USB, ATA, SCSI, a configuração de algumas opções de segurança, a configuração do dispositivo a ser inicializado primeiro, entre outras opções. Mas vale lembrar que o BIOS não é só isso. Vamos fazer um pequeno overview do que o BIOS deve fazer a partir do momento em que um dado equipamento é ligado (a sequência dessas tarefas depende de cada plataforma, portanto, vamos nos ater ao conteúdo e não à sequência):

1 – Limpar cache;
2 – Detectar memória RAM;
3 – Inicializar Stack;
4 – Configurar handlers SMM;
5 – Configurar registradores MSR;
6 – Configurar registradores MTRR;
7 – Inicializar Chipset (certamente uma das tarefas mais complicadas);
8 – Inicialização e Enumeração do barramento PCIe;
9 – Inicialização e Enumeração do barramento USB;
10 – Inicializar controladoras de HD (caso exista alguma configuração de RAID, essa tarefa fica ainda mais complicada);
11 – Montar a parte dinâmica do firmware (acpi);
12 – Inicializar frame buffer (vbios);
13 – Detectar firmwares externos e executá-los (Option ROM);
14 – Verificações de segurança em baixo nível (senha do BIOS, tamper, …);
15 – Detectar dispositivos a serem inicializados (boot device selection);
16 – Mover o processador para modo protegido (na arquitetura Intel os processadores sempre são iniciados em modo real quando ligados);
17 – Preencher tabelas e820 (mapeamento de memória que é passado para o S.O.);
18 – Atualização de microcode (correção de erros do processador);
19 – Criação de handlers para as interrupções (por exemplo, a Int 15/AX=E820h, que retorna o mapeamento de memória);
20 – Preencher SMBIOS.

As etapas apresentadas são o mínimo necessário para que um bootloader ou S.O. tenha um local estável para se apoiar e executar seu trabalho. Como visto, não são poucas as tarefas.

Vale lembrar que, normalmente, tudo isso deve ser feito em linguagem Assembly, visto que não existe Stack até que uma parte desse código seja executado, e visto que otimizações executadas por compiladores são um perigo nesse nível.

Outro agravante é que tudo isso precisa ser feito em 1 MB de código, que é o máximo endereçável pela arquiteta x86 quando o processador está em modo real 16 bits (existente para fins de compatibilidade), sendo este modo o modo padrão no qual o processador é iniciado ao ser energizado.

BIOS UEFI

Como visto anteriormente, as BIOS legacy possuíam algumas limitações que de certa forma estavam atrapalhando a evolução das plataformas, considerando o ambiente pré-OS. Para tentar resolver, ou ao menos diminuir essas limitações, foi criada a especificação EFI (Extensible Firmware Interface), que posteriormente passou a ser adotada por várias outras empresas e se tornou a especificação UEFI (Unified Extensible Firmware Interface).

O que aconteceu após a criação dessa especificação, encabeçada por grandes empresas como Intel, Apple, entre outras, foi a padronização das etapas de inicialização de um dado BIOS, bem como as interfaces as quais o mesmo deveria criar para poder ser consumido por aplicações e drivers para ambiente pré-OS. A essas interfaces foi dado o nome de UEFI Protocols (que não devem ser confundidos com protocolos de comunicação).

Outra especificação criada durante esse período foi a PI (Platform Initialization), que juntamente com a UEFI Spec, coloca ordem no grande caos existente na inicialização de plataformas “high end”. Vamos nos ater à UEFI Spec, por enquanto nesse entendimento inicial desse novo mundo que acontece antes do SO/Bootloader.

Simplificando. A especificação PI define como o boot deve ser feito e a especificação UEFI define as interfaces que um BIOS deve exportar para o ambiente pré-OS.

Detalhes sobre cada etapa são explicados na especificação UEFI, que pode ser encontrada no site do órgão responsável por essas especificações, aqui.

Como visto, a adoção da especificação UEFI causou grandes mudanças no BIOS, porém, abriu um novo mercado que é bastante explorado no exterior, principalmente nos Estados Unidos, Europa (mais precisamente Alemanha, França e Inglaterra) e Ásia.

Agora que sabemos os dois tipos de BIOS existentes atualmente, Legacy e UEFI, podemos verificar o avanço da tecnologia no tempo.

O que pode ser feito com tudo isso?

Exemplos de trabalhos que podem ser feitos com aplicações pré-OS:

• Ferramentas de configuração de controladoras especificas (ex.: RAID);
• Verificações de Rede antes do SO subir;
• Execução de tarefas paralelas ao SO (SMM handlers).

Somente esses 3 itens já permitem a criação de inúmeros projetos, e em alguns casos, ideias inovadoras.

Outro ponto importante no ambiente pré-OS é que não existe diferenciação entre “User Mode” e “Kernel Mode”. Portanto, aplicações UEFI têm controle total do hardware, sem ter que disputar recursos com outros pedaços de software, com um overhead muito menor.

Levando em consideração um axioma da área de segurança:

“Whoever touches the hardware first wins.” [2]

Outra área que pode ser abordada com o desenvolvimento para ambiente pré-OS é o desenvolvimento de rootKits, seja para o bem ou para o mal, bem como outros pontos referentes à segurança, como drives encriptados.

Conclusão

A área de aplicações pré-OS é um mundo bastante complexo e que necessita de profissionais altamente capacitados. É uma ótima oportunidade para universidades e empresas, pois permite a evolução da tecnologia nacional, bem como criação de novas empresas com foco específico nessa área.

Uma boa leitura para o entendimento de que grande parte dos dispositivos existentes precisam de algum tipo de firmware, e em vários deles firmwares compatíveis com a especificação UEFI podem ser encontrados, é o artigo “Neither seen not heard” escrito por Vincent Zimmer, um dos maiores nomes nessa área no mundo e uma pessoa formidável, tanto por sua simplicidade quanto por seu conhecimento.

Vale lembrar que firmwares UEFI podem ser encontrados tanto em plataformas Intel quanto em plataformas ARM fabricadas após o ano de 2006.

Referências

[1] PI Boot Flow
[2] UEFI Windows
[3] Neither seen not heard