Requisitos de UEFI para edições do Windows em plataformas SoC

Este artigo descreve os requisitos de UEFI que se aplicam ao Windows 10 para edições da área de trabalho (Home, Pro, Enterprise e Education) e Windows 10 Mobile. Para obter requisitos adicionais que se aplicam apenas a Windows 10 Mobile, consulte Requisitos de UEFI para Windows 10 Mobile.

Resumo dos requisitos

A tabela a seguir lista todos os requisitos atuais de conformidade com UEFI, conforme definido na especificação UEFI (Seção 2.6 da especificação UEFI 2.3.1). Nesta tabela, o termo Requisito Explícito do Windows identifica qualquer protocolo ou serviço que seja chamado diretamente por um componente do Windows. Embora apenas esses serviços sejam usados explicitamente pelo Windows, outros serviços e protocolos listados podem ser implicitamente ou explicitamente exigidos por uma implementação de firmware principal, drivers de dispositivo EFI ou por cadeias de ferramentas de desenvolvimento e implantação.

A Microsoft recebe comentários e comentários dos implementadores sobre esse conjunto de requisitos. Para quaisquer requisitos de conformidade da UEFI que sejam determinados como não exigidos pelo sistema operacional ou pelo firmware, é nossa intenção trabalhar com UEFI.org para que esses requisitos de conformidade sejam relaxados para essa classe de dispositivo.

Para obter mais informações sobre requisitos específicos, consulte as seções após a tabela.

Requisito	Seção de especificação uefi	Observações
Tabela do sistema EFI	4.3	Requisito explícito do Windows
Serviços de inicialização de EFI	6,0
Serviços de evento, temporizador e tarefa	6.1
Serviços de memória	6.2	Requisito explícito do Windows'
Serviços de manipulador de protocolo	6.3	Requisito explícito do Windows
Serviços de imagem	6.4	Requisito explícito do Windows
Serviços diversos	6.5	Requisito explícito do Windows
Serviços de runtime de EFI	7.0
Serviços de tempo	7.3	Requisito explícito do Windows
Serviços variáveis	7.2	Requisito explícito do Windows
Serviços diversos	7.5	Requisito explícito do Windows
Protocolos UEFI necessários
Protocolo de imagem carregada por EFI	8.1
Protocolo de caminho do dispositivo de imagem carregada por EFI	8.2
Protocolo de caminho do dispositivo EFI	9.2	Requisito explícito do Windows
Protocolo de utilitários de caminho de dispositivo EFI	9,5
Protocolo de descompactação EFI	18.5
Protocolo interpretador EBC	20.11
Protocolos UEFI exigidos condicionalmente
Protocolo de entrada de texto simples EFI	11.3	Requisito explícito do Windows
Protocolo EX de entrada de texto simples EFI	11.2
Protocolo de saída de texto simples EFI	11,4
Protocolo de saída de elementos gráficos EFI	11.9	Requisito explícito do Windows
Protocolo EFI EDID descoberto	11.9.1
Protocolo ativo EFI EDID	11.9.1
Protocolo de EFI block EO	12.8	Requisito explícito do Windows
Protocolo de EFI disk EO	12.7
Protocolo de sistema de arquivos simples EFI	12,4
Protocolo de ordenação Unicode EFI	12.10
Protocolo de rede simples EFI	21.1
Protocolo de código base EFI PXE	21.3
Protocolo de serviços de integridade de inicialização EFI	21,5
Protocolo de EFI serial de EO	11,8
Associação de braço UEFI	2.3.5	Requisito explícito do Windows
Requisitos de segurança
Inicialização Segura	27.0	Requisito explícito do Windows
Requisitos do gerenciador de inicialização	3.1, 3.3	Requisito explícito do Windows

Requisitos de tabela do sistema EFI

A Tabela do Sistema EFI deve estar em conformidade com a definição padrão no nível de revisão implementado. A Tabela de Configuração apontada pela Tabela do Sistema EFI deve incluir os dois GUIDs e seus ponteiros associados descritos na tabela a seguir.

GUID	Descrição
EFI_ACPI_Table GUID	Esse GUID deve apontar para o RSDP (Ponteiro de Descrição do Sistema Raiz) do ACPI para a plataforma.
SMBIOS_Table GUID	Esse GUID deve apontar para a estrutura do ponto de entrada SMBIOS. O Windows requer a Especificação SMBIOS, no nível de revisão 2.4 ou superior. As seções 3.2, "Estruturas e dados necessários" e 4, "Diretrizes de conformidade", são necessárias. Um teste de compatibilidade do SMBIOS do Windows está disponível.

Requisitos de serviços de inicialização de EFI

A tabela a seguir lista os requisitos de serviços de inicialização EFI para Windows.

Serviço de inicialização EFI	Requisito
Serviços de memória	O Windows requer todos os serviços de memória.
Serviços de manipulador de protocolo	O Windows requer os seguintes serviços de manipulador de protocolo: OpenProtocol() CloseProtocol() LocateDevicePath() LocateHandle()
Serviços de imagem	O Windows requer os seguintes serviços de imagem: ExitBootServices()
Serviços de inicialização diversos	O Windows requer os seguintes serviços de inicialização diversos: Stall() Nota: A implementação stall() é necessária para ter um erro determinístico (repetível) de modo que a correção ou cancelamento de erro possa ser feito de forma confiável.

Requisitos de serviços de runtime de EFI

A tabela a seguir lista os requisitos de serviços de runtime do EFI para Windows.

Serviço de runtime de EFI	Requisito
Serviços de tempo	O Windows requer os seguintes serviços de hora: GetTime() SetTime() Nota: Os serviços de tempo só serão chamados durante a inicialização (antes de ExitBootServices()) para acessar o hardware de hora do dia da plataforma.
Serviços variáveis	Todos os Serviços de Variáveis uefi são necessários para gerenciar vários dispositivos de inicialização e variáveis de segurança na classe de destino de sistemas.
Serviços de runtime diversos	O Windows requer os seguintes serviços de runtime diversos: ResetSystem() Nota: A implementação ResetSystem() deve dar suporte às opções de redefinição e desligamento.

Requisitos de protocolo

A tabela a seguir descreve os protocolos UEFI exigidos pelo Windows para realizar funções específicas durante a inicialização.

Protocolo	Requisito
Protocolo de saída de gráficos	O Windows requer o GOP (Graphics Output Protocol). Os requisitos específicos do buffer de quadro são: Para exibições integradas, HorizontalResolution e VerticalResoluton devem ser a resolução nativa do painel. Para exibições externas, HorizontalResolution e VerticalResoluton devem ser a resolução nativa da exibição ou, se não houver suporte, os valores mais altos compatíveis com o adaptador de vídeo e a exibição conectada. PixelsPerScanLine deve ser igual a HorizontalResolution. PixelFormat deve ser PixelBlueGreenRedReserved8BitPerColor. Um buffer de quadro físico é necessário; Não há suporte para PixelBltOnly . Quando a execução é entregue a um aplicativo de inicialização UEFI, o gerenciador de inicialização de firmware e o firmware não devem usar o buffer de quadros para nenhuma finalidade. O buffer de quadro deve continuar a ser verificado após a saída dos serviços de inicialização.
Saída de exibição alternativa	O firmware UEFI deve dar suporte à inicialização usando qualquer conector de exibição compatível com o hardware. Se um painel interno estiver conectado e visível, o painel interno deverá ser usado. Todas as saídas que têm exibições fisicamente conectadas devem mostrar a tela de inicialização. Para exibições conectadas, o firmware UEFI deve: Inicialize a saída com o modo nativo da exibição, se a resolução nativa puder ser determinada. Se um modo nativo não for possível, ele deverá inicializar para o modo mais alto compatível. Se os recursos de exibição não puderem ser determinados, a exibição conectada deverá ser inicializada em um modo conhecido por ser compatível com o maior número possível de monitores (normalmente 640x480 ou 1024x768, a 60 Hz).
Entrada na hora da inicialização	O Protocolo de Entrada de Texto Simples EFI é necessário para fazer opções de inicialização ou outras seleções de menu em sistemas que têm teclados internos ou teclados anexados. Para sistemas sem teclado, três botões são recomendados no ambiente de inicialização: botão Iniciar Botão Aumentar Volume Botão Diminuir Volume As teclas de botão devem ser relatadas por meio do Protocolo de Entrada de Texto Simples EFI mapeando-as para as seguintes teclas de teclado, respectivamente: Tecla do Windows Tecla de seta para cima Tecla de seta para baixo
Inicialização de armazenamento local	O Windows requer suporte ao Protocolo de E/S de Bloco e ao Protocolo de Caminho do Dispositivo para a solução de armazenamento que contém a partição do sistema EFI e a partição do sistema operacional Windows. Para inicializar do armazenamento flash que requer nivelamento de desgaste ou outro gerenciamento flash, isso deve ser implementado no firmware (não em um aplicativo UEFI).

Requisitos de segurança

O Windows tem requisitos de segurança nas áreas de Inicialização Segura, Inicialização Medida, Criptografia e Proteção de Dados. Esses requisitos são detalhados na tabela a seguir. Além disso, para as áreas em que o hardware soc impede a conformidade com o padrão existente (TPM, RTC etc.), requisitos adicionais estão sendo desenvolvidos. Eles são descritos no final da tabela.

Área	Requisito
Geral	Requisito 1: OBRIGATÓRIO. A plataforma deve estar em conformidade com todos os requisitos especificados nesta seção. Requisito 2: OBRIGATÓRIO. As plataformas devem ser uefi classe três sem nenhum módulo de suporte de compatibilidade instalado ou instalável. A emulação do BIOS e a inicialização herdada do COMPUTADOR/AT devem ser desabilitadas.
Inicialização segura UEFI	Requisito 3: OBRIGATÓRIO. A Inicialização Segura, conforme definido na seção 27 da UEFI v2.3.1, deve ser enviada habilitada e com um banco de dados de assinatura (EFI_IMAGE_SECURITY_DATABASE) necessário para inicializar o computador com segurança pré-provisionado. O conteúdo inicial do banco de dados de assinatura é determinado pelo OEM, com base nos drivers UEFI de terceiros necessários, nas necessidades de recuperação e no carregador de inicialização do sistema operacional instalado no computador, mas uma assinatura de EFI_CERT_X509 fornecida pela Microsoft deve ser incluída. Nenhuma assinatura adicional deve estar presente. Requisito 4: OBRIGATÓRIO. A presença do banco de dados de assinatura "proibido" da UEFI (EFI_IMAGE_SECURITY_DATABASE1) é necessária. Requisito 5: OBRIGATÓRIO. Uma KEK UEFI fornecida pela Microsoft será incluída no banco de dados KEK da UEFI. Nenhuma KEK adicional estará presente. A Microsoft fornece a KEK na forma de uma assinatura de EFI_CERT_X509. Requisito 6: OBRIGATÓRIO. Uma chave PKpub deve estar presente e armazenada no flash de firmware. Observação: como o PKpriv (o equivalente de chave privada para pkpub) controla a política de Inicialização Segura em todos os dispositivos provisionados com pkpub, sua proteção e uso devem ser bem protegidos. Requisito 7: OBRIGATÓRIO. Os bancos de dados de assinatura iniciais devem ser armazenados no flash de firmware e podem ser atualizados apenas com uma atualização de firmware assinada por OEM ou por meio de gravação de variável autenticada por UEFI. Requisito 8: OBRIGATÓRIO. As imagens no caminho de inicialização que falham na verificação de assinatura não devem ser executadas e o motivo da falha deve ser adicionado ao EFI_IMAGE_EXECUTION_TABLE. Além disso, a abordagem recomendada nessas situações é que o gerenciador de inicialização uefi inicia a recuperação de acordo com uma estratégia específica do OEM. Requisito 9: OBRIGATÓRIO. A substituição de usuário fisicamente presente não deve ser permitida para imagens UEFI que falham na verificação de assinatura. Requisito 10: OPCIONAL. Um OEM pode implementar a capacidade de um usuário fisicamente presente desativar a Inicialização Segura com acesso ao PKpriv ou com Presença Física por meio da configuração do firmware. O acesso à configuração do firmware pode ser protegido por meios específicos da plataforma (senha de administrador, cartão inteligente, configuração estática etc.) Requisito 11: OBRIGATÓRIO se o requisito 10 for implementado. Se a Inicialização Segura estiver desativada, todas as variáveis UEFI existentes não estarão acessíveis. Requisito 12: OPCIONAL. Um OEM pode implementar a capacidade de um usuário fisicamente presente selecionar entre dois modos de Inicialização Segura na configuração do firmware: "Personalizado" e "Standard". O Modo Personalizado permite mais flexibilidade, conforme especificado no seguinte. Requisito 13: OBRIGATÓRIO se o requisito 12 for implementado. Será possível reabilitar uma Inicialização Segura desabilitada no Modo Personalizado definindo um PK específico do proprietário. A administração deve continuar conforme definido na seção 27.5 da especificação uefi v2.3.1: Firmware/SO Key Exchange. No Modo Personalizado, o proprietário do dispositivo pode definir sua escolha de assinaturas nos bancos de dados de assinatura. Requisito 14: OBRIGATÓRIO se o requisito 12 for implementado. A configuração do firmware indicará se a Inicialização Segura está ativada e se ela é operada no Modo Standard ou Personalizado. A configuração do firmware deve fornecer uma opção para retornar do Modo Personalizado para Standard. Requisito 15: OBRIGATÓRIO. Se as configurações de firmware forem redefinidas para padrões de fábrica, todas as variáveis protegidas de conjunto personalizado serão apagadas e o PKpub original deverá ser restabelecida junto com os bancos de dados de assinatura originais provisionados pelo fabricante. Requisito 16: OBRIGATÓRIO. A assinatura do driver deve usar a opção Authenticode (WIN_CERT_TYPE_PKCS_SIGNED_DATA). Requisito 17: OBRIGATÓRIO. Suporte para o EFI_IMAGE_EXECUTION_INFO_TABLE (ou seja, criação e armazenamento de informações sobre imagens iniciadas ou não iniciadas durante a inicialização). Requisito 18: OBRIGATÓRIO. Suporte a GetVariable() para o EFI_IMAGE_SECURITY_DATABASE (banco de dados de assinatura autorizado e proibido). Requisito 19: OBRIGATÓRIO. Suporte a SetVariable() para o EFI_IMAGE_SECURITY_DATABASE (banco de dados de assinatura autorizado e proibido), usando o Microsoft KEK para autenticação. Requisito 20: OBRIGATÓRIO. EFI_HASH_SERVICE_BINDING_PROTOCOL: Suporte ao serviço: CreateChild(), DestroyChild(). Requisito 21: OBRIGATÓRIO. EFI_HASH_PROTOCOL. Suporte de serviço: Hash(). Suporte para os algoritmos de hash SHA_1 e SHA-256. Deve dar suporte à passagem de uma mensagem com pelo menos 10 Mbytes de comprimento.
Inicialização medida por UEFI	Os requisitos a seguir não implicam a necessidade de uma implementação de TPM TCG; eles, no entanto, implicam uma necessidade de funcionalidade equivalente para as áreas afetadas. O suporte à plataforma pode ser fornecido por uma implementação de firmware de um TPM em execução no ambiente de execução segura, camadas sobre o mecanismo de aceleração criptográfica e aproveitando o armazenamento isolado. A Microsoft pode ser capaz de fornecer software de referência para essa implementação de TPM para uso pelo fornecedor. Isso está sujeito a discussões adicionais. Requisito 22: OBRIGATÓRIO. A plataforma deve estar em conformidade com o protocolo EFI especificado no Protocolo EFI de Ambiente de Execução Confiável da UEFI. Requisito 23: OBRIGATÓRIO. A plataforma deve seguir a Especificação da Plataforma TCG EFI com as seguintes adições: Em plataformas que dão suporte à interface definida no TrEE EFI Protocol, o resumo do PKpub deve ser estendido para o TPM PCR[03] como um evento de EV_EFI_VARIABLE_CONFIG. O resumo do conteúdo do banco de dados de assinatura autorizado (consulte a seção 27.8 da lista de especificações da UEFI v2.3.1) deve ser estendido na inicialização medida como um evento de EV_EFI_VARIABLE_CONFIG. A operação de extensão deve ser para TPM PCR[03]. É possível que um cliente UEFI leia e analise a lista de certificados usando a variável EFI_IMAGE_SECURITY_DATABASE e valide o resumo em relação ao valor estendido. TCG_PCR_EVENT valores de resumo devem ser SHA-256, não SHA-1. Requisito 24: OBRIGATÓRIO. A plataforma deve implementar o MemoryOverwriteRequestControl definido na Especificação de Mitigação de Ataque de Redefinição de Plataforma TCG.
Criptografia	Requisito 25: OBRIGATÓRIO. A plataforma fornecerá o EFI_HASH_PROTOCOL (UEFI v2.3.1 Seção 27.4) para descarregamento de operações de hash criptográficas. SHA-256 deve ter suporte. Requisito 26: OBRIGATÓRIO. A plataforma deve dar suporte à EFI_RNG_PROTOCOL definida pela Microsoft para leitura pré-so da entropia.
Proteção de dados	Requisito 27: OBRIGATÓRIO. A plataforma deve dar suporte a variáveis EFI com qualquer combinação dos seguintes atributos de variável UEFI definidos: EFI_VARIABLE_BOOTSERVICE_ACCESS EFI_VARIABLE_NON_VOLATILE EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS
Outros requisitos de segurança	Os requisitos adicionais a seguir são exigidos pelo Windows em plataformas SoC. A Microsoft definiu o protocolo para coletar entropia de uma plataforma UEFI. Embora não seja um requisito uefi, esse protocolo é exigido pelo Windows em plataformas SoC. Para obter mais informações sobre esse protocolo, consulte Protocolo de coleta de entropia UEFI. Atualizações de banco de dados de assinatura UEFI. Um novo mecanismo para atualizar variáveis autenticadas foi adotado na seção 27 da UEFI 2.3.1. Esse mecanismo é exigido pelo Windows. Ambiente de execução confiável. A Microsoft desenvolveu um protocolo EFI para interagir com um TrEE (Ambiente de Execução Confiável), semelhante na funcionalidade a um subconjunto de um TPM (Trusted Computing Group) Trusted Platform Module (TCG). O protocolo EFI aproveita em grande parte o "Protocolo TCG EFI", Versão 1.2 Revisão 1.00, 9 de junho de 2006, pelo Grupo de Computação Confiável. Para obter detalhes, consulte Protocolo EFI do Ambiente de Execução Confiável da UEFI.

Requisitos do gerenciador de inicialização de firmware

O gerenciador de inicialização de firmware deve dar suporte ao comportamento de inicialização padrão definido na seção 3.3 da especificação. Além disso, para dar suporte a variáveis de várias inicializações, definidas globalmente e aos requisitos do Gerenciador de Inicialização da seção 3.1 da especificação, são necessários.

Requisitos de associação do Braço da UEFI

A Associação de Braço uefi inclui requisitos específicos para a plataforma Arm necessária para ser compatível com especificações UEFI. O Windows requer tudo na associação arm aplicável ao ARMv7. Como o Windows não dá suporte a nada anterior ao ARMv7, os requisitos na associação que são específicos do ARMv6k e abaixo são opcionais.

A associação especifica, por exemplo, como a MMU deve ser configurada e como a memória física deve ser mapeada. A associação também especifica que as chamadas feitas a protocolos e serviços UEFI devem ser feitas apenas no ARM ISA, o que significa que o software em execução no Thumb2 ou thumb precisaria voltar para o modo Arm antes de chamar funções UEFI.

Requisitos de inicialização de multiprocessador do Arm da UEFI

A Microsoft desenvolveu um protocolo para iniciar vários núcleos do Arm em uma plataforma UEFI de vários processadores. Esse protocolo é exigido pelas plataformas Windows no Arm que não dão suporte à PSCI (Interface de Coordenação de Estado do Power). As plataformas que dão suporte a PSCI não devem usar esse protocolo. Para obter mais informações sobre esse protocolo, consulte o documento Inicialização de vários processadores em plataformas baseadas em ARM UEFI no site ACPICA (Arquitetura de Componentes acPI).

Requisitos de configuração da plataforma

O firmware é responsável por colocar o hardware do sistema em um estado bem definido antes de ser entregue ao carregador do sistema operacional. A tabela a seguir define os requisitos de configuração da plataforma relacionada.

Requisito	Descrição
Caminho de inicialização	O firmware deve inicializar a plataforma para o ponto em que o Windows é capaz de acessar o dispositivo de inicialização via UEFI e carregar o kernel. Qualquer dispositivo envolvido na hierarquia para ler do dispositivo de inicialização deve ser cronometrado e alimentado a uma taxa razoável, considerando considerações de desempenho e energia. O núcleo do processador base em si também deve ser cronometrado e alimentado a uma taxa razoável, para que o sistema possa ser inicializado em tempo hábil sem drenar a bateria.
Principais recursos do sistema	Os Principais Recursos do Sistema expostos ao sistema operacional por meio de tabelas ACPI devem ser ativados e ativados. Os principais recursos do sistema incluem controladores de interrupção, temporizadores e controladores de DMA que devem ser gerenciados pelo sistema operacional. Além disso, as interrupções devem ser mascaradas pela chamada para ExitBootServices() até que o driver de dispositivo associado no sistema operacional desmascare e habilite novamente as interrupções no dispositivo. Se as interrupções estiverem habilitadas durante os serviços de inicialização, supõe-se que o firmware as gerencie.
Depuração	O Windows dá suporte à depuração por meio do Host USB 3 (XHCI), do Host USB 2 (EHCI)1, do IEEE 1394, das interfaces de função serial e USB (bem como adaptadores de ethernet PCI). Pelo menos um deles deve ser alimentado, cronometrado e inicializado pelo firmware antes da entrega do sistema operacional. Seja qual for a opção fornecida, ela deve ter uma porta exposta para fins de depuração e o controlador deve ser mapeado para memória ou ser conectado por meio de um barramento periférico dedicado (não compartilhado).
Outros requisitos de configuração da plataforma	Qualquer configuração de pin-multiplexing e pad deve ser concluída no firmware antes de entregar o controle ao carregador do sistema operacional.

Requisitos de instalação

O Windows exige que a partição do sistema operacional resida em uma solução de armazenamento particionada por GPT. O armazenamento particionado MBR pode ser usado como armazenamento de dados. Conforme definido na especificação uefi, uma plataforma UEFI requer uma partição de sistema dedicada. O Windows requer essa partição de sistema dedicada, conhecida como ESP (partição do sistema EFI).

Requisito de HSTI (Interface de Teste de Segurança de Hardware)

A plataforma deve implementar a Interface de Teste de Segurança de Hardware e a plataforma é necessária para compartilhar documentação e ferramentas, conforme especificado na Especificação de Testabilidade de Segurança de Hardware.

Artigos relacionados

Requisitos mínimos de UEFI para Windows em plataformas SoC

Requisitos de UEFI para Windows 10 Mobile

Requisitos de UEFI para suporte a flash usb