Engenharia de BIOS e Firmware

O hardware arranca, mas o produto não

A engenharia de firmware começa depois de a placa conseguir ligar-se

Uma placa-mãe pode concluir o POST e, mesmo assim, não ser adequada para o produto instalado. Pode parar no dispositivo de arranque errado, permanecer desligada após o restabelecimento da alimentação, exibir opções de configuração que os operadores no terreno nunca devem alterar, indicar uma identificação incorreta do produto ou não conseguir recuperar-se quando o software de aplicação deixa de responder.

A engenharia de firmware converte esses requisitos do produto num comportamento controlado da plataforma. O ponto de partida é uma revisão específica da placa-mãe, a versão atual do firmware, a imagem do sistema operativo, os dispositivos ligados, os requisitos relativos ao estado de alimentação, a política de segurança e o método de atualização.

Conceção de placas Mini-ITX personalizadas → Especificações da plataforma →

Âmbito do firmware ao nível do produto

O que podemos definir no BIOS e no firmware UEFI

Definições predefinidas de configuração

Prioridade de arranque, dispositivos ativados, virtualização, modo de armazenamento, configurações de porta série, opções de segurança e predefinições de produção.

Acesso à configuração

Ocultar os menus selecionados, restringir as alterações, definir o acesso de administrador, e remover as opções de assistência no terreno que devem permanecer sob controlo da fábrica.

Política de arranque

NVMe, SATA, USB, PXE ou prioridade de arranque HTTP suportada, ordem de recurso, atraso de arranque e condições de entrada de recuperação.

Política Energética

Recuperação após falha de corrente alternada, ativação do RTC, comportamento de desligamento suave, estados de suspensão suportados, e fontes de ativação específicas da placa.

Identidade da plataforma

Fabricante, nome do produto, informações de série, identificação da placa, campos SMBIOS, dados do ativo e alterações aprovadas no logótipo de arranque.

Segurança e atualizações

Propriedade da chave de arranque seguro, exposição do TPM, proteção da configuração, política de atualizações assinadas, caminho de recuperação e aprovisionamento de produção.

Requisitos relativos ao estado de alimentação

Definir exatamente o que acontece no arranque, no encerramento e quando se volta a ligar à corrente alternada

O equipamento não supervisionado não pode depender de um técnico premir uma tecla após uma falha de alimentação. O comportamento de arranque e de alimentação deve ser definido em função da implementação real da UEFI, da lógica de alimentação da placa-mãe, do armazenamento ligado, do caminho de rede e da imagem do SO.

Plataformas de alimentação →

Controlo ao nível do Conselho de Administração

O firmware só pode controlar o que a placa disponibiliza

Os projetos Mini-ITX incorporados incluem frequentemente controlos que não aparecem na BIOS de um computador de secretária. O seu comportamento depende do Super I/O instalado, do controlador incorporado, do expansor GPIO, do transceptor, do watchdog, do controlador de ventoinha ou do chipset.

Múltiplas portas de série → Plataforma GPIO e CAN →

Dados do firmware para o sistema operativo

O ACPI e o SMBIOS devem descrever o hardware fornecido

O firmware apresenta informações padronizadas que o sistema operativo e o software de gestão utilizam para a configuração, a gestão de energia e o inventário de hardware. Não basta que a estrutura esteja correta; os dados têm de corresponder exatamente à placa de produção e à identidade do produto.

Confiança pré-arranque

O Secure Boot requer a definição de um proprietário da chave e de um caminho de atualização

O Secure Boot em produção não é apenas uma configuração de ativação/desativação. O projeto deve definir quem controla a Chave da Plataforma, quais chaves de troca de chaves são consideradas fiáveis, o que é incluído na base de dados de assinaturas permitidas, como as imagens revogadas são introduzidas no dbx, e como as atualizações de campo autorizadas permanecem recuperáveis.

Os requisitos atuais da UEFI estabelecem que o formato da Chave da Plataforma de Arranque Seguro (Secure Boot Platform Key) deve ser, no mínimo, RSA-2048 e exigem que os hash das imagens UEFI armazenados em dbx utilizem, no mínimo, SHA-256. Trata-se de requisitos criptográficos mínimos, não de uma política completa de segurança do produto.

Propriedade da PK

Decida se é o fabricante de equipamento original (OEM), o cliente ou outro proprietário autorizado que controla a chave da plataforma utilizada para estabelecer a titularidade do Arranque Seguro.

KEK, db e dbx

Defina as autoridades de atualização de confiança, as imagens permitidas, as assinaturas revogadas e o método de aprovisionamento utilizado em produção.

TPM 2.0

Disponibilizar e configurar a plataforma TPM, sempre que tal seja suportado, com a titularidade e a política de implementação definidas pelo sistema final.

Recuperação

Manter uma via de recuperação autorizada para atualizações falhadas ou alterações de chaves, sem contornar a política de confiança prevista.

Sistemas de segurança de rede →

Controlo do firmware de produção

Lançar o binário com a sua placa, as definições predefinidas e o registo de alterações

Um ficheiro de firmware só se torna um artefacto de produção quando a sua identidade e compatibilidade são controladas. O ficheiro binário lançado deve permanecer associado à revisão da placa-mãe, à configuração predefinida, ao provisionamento de segurança, ao método de atualização e ao motivo da alteração.

1. Identidade binária Registe a versão do firmware, a revisão exata da placa, o tamanho do ficheiro, o resumo SHA-256 e a data de lançamento.
2. Definições predefinidas de produção Bloqueie os valores de configuração enviados separadamente das definições de depuração de engenharia e das alterações efetuadas pelo técnico local.
3. Registo de alterações Identificar as funções alteradas, o hardware afetado ou as versões do sistema operativo, as restrições conhecidas e os testes de regressão necessários.
4. Atualização e recuperação Defina o método de atualização aprovado, a política de versões, as precauções em caso de falha de energia, as regras de reversão e o percurso de recuperação.

Especificações de referência

Interfaces de firmware e especificações de referência

UEFI 2.11

Especificação UEFI atual relativa ao ambiente padronizado de firmware pré-SO, serviços de arranque, serviços em tempo de execução, variáveis e protocolos.

ACPI 6.6

Especificação ACPI atual para a configuração de dispositivos orientada pelo sistema operativo, descrição da plataforma, gestão de energia e eventos do sistema.

SMBIOS 3.9.0

Especificação da DMTF relativa a informações de gestão normalizadas fornecidas pelo firmware do sistema sobre a plataforma e o hardware instalado.

TCG TPM 2.0 v185

Março de 2026: Especificação da biblioteca TPM 2.0 que define a arquitetura, as estruturas e os comandos utilizados pelas implementações do TPM 2.0.

Certificações e normas de qualidade →

Lançamento do firmware

Verifique a versão exata do firmware que pretende distribuir

A engenharia de firmware culmina com um ficheiro binário definido e uma configuração de produção. A validação de engenharia executa, em seguida, essa versão exata na placa de destino com a imagem do sistema operativo pretendida, os periféricos, os estados de alimentação, as configurações de segurança, o método de atualização e o percurso de recuperação.

Validação de Engenharia → Todos os serviços de engenharia →

FAQ

Questões sobre engenharia de BIOS e firmware