Compartilhar via

Diretrizes para Option ROM de Validação UEFI

  • Artigo

Versão 1.3

Este documento ajuda OEMs e ODMs a validar que o firmware verifica as assinaturas do Option ROM como parte da cadeia de confiança de Inicialização Segura.

Este guia pressupõe que você conhece os princípios UEFI, as noções básicas da Inicialização Segura (Capítulos 1, 2, 13, 20 e 27 da especificação UEFI) e o modelo de segurança PKI.

Introdução

Option ROMs (ou OpROMs) são componentes de firmware executados pelo sistema BIOS do computador durante a inicialização da plataforma. Eles geralmente são armazenados em um cartão plug-in, embora possam ser encontrados na placa base.

Os dispositivos que normalmente exigem Option ROMs são placas de vídeo, adaptadores de rede e drivers de armazenamento para módulos RAID. Esses Option ROMs também normalmente fornecem drivers de firmware para o computador.

Eles incluem uma variedade de tipos de drivers de firmware, inclusive Option ROMs herdados de PC-AT, Open Firmware e EFI. Os exemplos de drivers de firmware incluem BIOS de vídeo em placas de vídeo, drivers de inicialização PXE para adaptadores Ethernet e drivers de armazenamento em controladores RAID. Esses dispositivos normalmente têm Option ROMs que fornecem drivers de firmware.

A UEFI (Unified Extensible Firmware Interface) é compatível com Option ROMs no modo Herdado.

De acordo com a especificação UEFI mais recente (atualmente em 2.3.1 Errata C – seção 2.5.1.2), Option ROMs (herdados) do ISA não fazem parte da Especificação UEFI. Para fins dessa discussão, somente Option ROMs compatíveis com a UEFI baseada em PCI serão considerados.

Option ROMs podem ser usados quando não é possível inserir o firmware de um dispositivo no firmware do computador. Quando o Option ROM transporta o driver, o IHV pode utilizar esse driver e manter o driver e o dispositivo em um só lugar.

Este documento explica por que você precisa validar Option ROMs e mostra algumas técnicas de fazer isso.

Suporte ao BIOS UEFI e ao BIOS Herdado

Muitos fabricantes criam dispositivos que incluem Option ROMs e firmware para muitos tipos de computadores. As combinações comuns incluem:

  • Somente ROM Herdado
  • OpROM UEFI Nativo
  • ROM Herdado + UEFI EBC OpROM
  • ROM Herdado + UEFI x64 OpROM
  • ROM Herdado + UEFI x64 + UEFI IA32
  • ROM Herdado + UEFI x64 + UEFI IA32 + UEFI EBC OpROM

O BIOS UEFI pode carregar e executar drivers de firmware herdados quando um CSM (Módulo de Suporte de Compatibilidade) está habilitado. Observe que, quando a Inicialização Segura está habilitada, a execução do Módulo de Suporte de Compatibilidade e ROMs herdados é proibida porque os drivers de firmware herdados não são compatíveis com a autenticação. Se o formato do Option ROM na configuração do BIOS estiver definido como ROM herdada, ele sempre usará a ROM herdada no dispositivo.

Se o formato do Option ROM estiver definido como Compatível com a UEFI, ele usará a ROM EFI mais recente, se houver, e a ROM herdada, se não houver.

Os drivers UEFI são necessários para muitos dos novos recursos de segurança de nível de firmware, bem como para habilitar as sequências de inicialização UEFI. Por exemplo, não é possível instalar o Windows de um disco óptico anexado a um controlador de armazenamento não compatível com a UEFI, quando um sistema está inicializando no modo UEFI, quando a Inicialização Segura está habilitada.

1. UEFI e Option ROMs

diagram of uefi driver considerations

Figura 2: Consideração de Segurança do Driver UEFI, Fonte: UEFI 2.3.1 Errata C

O texto a seguir originou-se na UEFI 2.3.1 Errata C, mas desde então foi modificado com insights de parceiros:

Como o perfil de usuário UEFI detalha uma série de privilégios relacionados à segurança, é importante que o Gerenciador de Identidades do Usuário, os Provedores de Credenciais de Usuário e o ambiente no qual eles são executados sejam confiáveis.

Isso inclui:

  • Protegendo a área de armazenamento em que esses drivers são armazenados.
  • Protegendo os meios pelos quais esses drivers são selecionados.
  • Protegendo o ambiente de execução desses drivers contra drivers não verificados.
  • As estruturas de dados usadas por esses drivers não devem ser corrompidas por drivers não autorizados enquanto ainda estão sendo usados.

Componentes como o Gerenciador de Identidades do Usuário, os drivers de Credenciais de Usuário e os drivers de integração talvez estejam localizados em um local seguro, como a unidade flash protegida contra gravação, que é confiável para a política de plataforma.

Alguns outros drivers podem ser encontrados em locais de armazenamento desprotegidos, como Option ROMs ou uma partição de disco rígido, e podem ser facilmente substituídos. Esses drivers devem ser verificados.

Por exemplo, a política de plataforma padrão deve verificar com êxito os drivers listados nas opções de carga Driver#### ou então o usuário deve ser identificado antes de processar esses drivers. Caso contrário, a execução do driver deverá ser adiada. Se o perfil do usuário for alterado por meio de uma chamada subsequente para Identify () ou por meio da autenticação dinâmica, as opções Driver#### poderão não ser processadas novamente.

O banco de dados do perfil do usuário é fechado usando diferentes eventos de sinal UEFI com base na possibilidade de ele ser protegido.

Drivers UEFI e Option ROMs UEFI só serão executados para dispositivos no caminho de inicialização.

A especificação PCI permite várias imagens do Option ROM no mesmo dispositivo. Esses Option ROMs podem ser x86 Herdado e UEFI. O firmware UEFI define a política de plataforma para escolher o Option ROM. Isso pode fazer com que a ROM do adaptador opcional seja executada como seu próprio dispositivo de controle.

O firmware verifica as assinaturas durante as fases BDS e DXE. A sequência de eventos é a seguinte:

  1. Inicializar PCI e barramentos derivados
  2. Dispositivos PCI de Investigação para Option ROMs
  3. Os Option ROMs encontrados são mapeados na memória
  4. A fase DXE carrega todos os drivers UEFI em ROMs

Os Option ROMs UEFI podem estar em qualquer lugar na memória. O padrão é permitir que a ROM na placa gerencie o dispositivo. A UEFI permite que a plataforma controle a política sobre qual o Option ROM controla qual dispositivo usando EFI_PLATFORM_DRIVER_OVERRIDE. A UEFI é compatível com Option ROMs para registrar uma interface de configuração.

Em um computador com a Inicialização Segura habilitada, os drivers de Option ROM serão uma ameaça à segurança se não estiverem assinados ou não forem validados. A validação de assinatura para Option ROMs é um requisito de WHCK. Isso também se aplica durante a manutenção de Option ROMs para garantir que a atualização seja validada antes da instalação.

Nas Especificações e Políticas do Programa de Compatibilidade de Hardware do Windows versão 1809:

  1. Verificação de Integridade do Código de Firmware Assinado. O firmware que é instalado pelo OEM e é somente leitura ou protegido por um processo de atualização de firmware seguro, conforme definido acima, pode ser considerado protegido. Os sistemas devem verificar se todos os componentes de firmware, drivers UEFI e aplicativos UEFI desprotegidos são assinados usando o RSA-2048 mínimo com SHA-256 (MD5 e SHA-1 são proibidos) e verificar se os aplicativos e drivers UEFI que não são assinados de acordo com esses requisitos não serão executados (esta é a política padrão para algoritmos de assinatura aceitáveis). Se uma assinatura de imagens não for encontrada no banco de dados autorizado ou for encontrada no banco de dados proibido, a imagem não deverá ser iniciada e, em vez disso, as informações sobre ela serão colocadas na Tabela de Informações de Execução de Imagem.

2. Declaração do problema

Alguns builds do sistema BIOS compatível com a Inicialização Segura, inclusive o Tiano Core, não autenticaram por padrão os Option ROMs UEFI porque os Option ROMs UEFI assinados não estavam disponíveis durante o desenvolvimento da Inicialização Segura. Isso expõe uma superfície de ataque/vulnerabilidade na Inicialização Segura UEFI.

2.1. Vulnerabilidade

Essa vulnerabilidade ainda estava presente no EDK II e no UDK2010 desde agosto de 2013. Os administradores do código-fonte estão cientes do problema e um bug foi registrado. Qualquer firmware derivado do EDK II e do UDK2010 deve conferir como a verificação do Option ROM é gerenciada. O comportamento de verificação do Option ROM é controlado por um valor PcdOptionRomImageVerificationPolicy PCD no pacote EDK II SecurityPkg.

O código-fonte da vulnerabilidade TianoCore é o arquivo SecurityPkg\SecurityPkg.dec:

## Pcd for OptionRom.
  #  Image verification policy settings:
  #  ALWAYS_EXECUTE                         0x00000000
  #  NEVER_EXECUTE                          0x00000001
  #  ALLOW_EXECUTE_ON_SECURITY_VIOLATION    0x00000002
  #  DEFER_EXECUTE_ON_SECURITY_VIOLATION    0x00000003
  #  DENY_EXECUTE_ON_SECURITY_VIOLATION     0x00000004
  #  QUERY_USER_ON_SECURITY_VIOLATION       0x00000005
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00|UINT32|0x00000001

O valor padrão (0x00) é ALWAYS_EXECUTE, que não executa corretamente a verificação de drivers assinados em Option ROMs para periféricos de suplemento. Esse não é o valor ideal para sistemas que implementam a funcionalidade de Inicialização Segura UEFI.

Valor Recomendado (Melhor Segurança): DENY_EXECUTE_ON_SECURITY_VIOLATION (0x04)

Valor Recomendado (Melhor Flexibilidade): QUERY_USER_ON_SECURITY_VIOLATION (0x05)

No EDK II & UDK2010, a prática de codificação adequada usa um mecanismo de substituição para modificar os valores PCD do firmware da plataforma. Portanto, o valor de PcdOptionRomImageVerificationPolicy não deve ser alterado em SecurityPkg\SecurityPkg.dec. O valor de substituição deve ser definido no arquivo DSC da plataforma. Um exemplo é mostrado abaixo usando Nt32Pkg\Nt32Pkg.dsc:

[PcdsFixedAtBuild]
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04

A substituição PCD deve ser colocada na seção [PcdsFixedAtBuild] do arquivo DSC. O mecanismo exato para substituir parâmetros pode ser diferente dependendo das ferramentas do fornecedor do BIOS.

Observação

Esta vulnerabilidade pode existir em implementações anteriores do BIOS de Inicialização Segura UEFI de fornecedores de BIOS independentes. Entre em contato com o fornecedor de BIOS para determinar se sua versão pode ser afetada.

3. Quem é afetado?

Um computador UEFI que implementa a Inicialização Segura e tem um driver de Option ROM UEFI que não está assinado. Além disso, o firmware de compatibilidade para fazer com que as placas existentes funcionem pode ter uma vulnerabilidade de segurança que não verifica Option ROMs.

Notebooks, netbooks, ultrabooks e tablets: a maioria não é afetada. Normalmente, os Option ROMs estão presentes em barramentos de backplane, como PCI/e, ISA e seus derivados (ExpressCard, miniPCI, CardBus, PCCard, LPC, ThunderBolt etc). Se um notebook não tiver nenhum desses expostos, sua superfície de ataque será muito reduzida. Além disso, é provável que os drivers de UEFI para componentes de laptop integrados sejam integrados ao volume principal de firmware do BIOS, não localizados em um Option ROM separado. Portanto, a maioria dos notebooks não está em risco. Além disso, quando os Option ROMs Herdados estão desabilitados, parece que a UEFI só é compatível com Option ROMs baseados em PCI.

No entanto, se você tiver um desktop, uma placa-mãe ou um servidor que tenha um BIOS UEFI e implemente a Inicialização Segura, você poderá ser afetado. No controlador RAID dedicado de um servidor ou no controlador de armazenamento de suplementos para SATA, FC etc. as placas de rede Ethernet PCIe podem ter Option ROMs. Os controladores de suplemento compatíveis com uma ampla variedade de funcionalidades em servidores são comuns, portanto, isso se aplica especialmente ao espaço do servidor.

Isso pode afetar os computadores de 32 bits e 64 bits, classe 2 e classe 3.

Se uma plataforma de Inicialização Segura der suporte a Option ROMs em dispositivos não permanentemente anexados à plataforma e ela for compatível com a capacidade de autenticar esses Option ROMs, ela deverá dar suporte aos métodos de validação de Option ROMs descritos nos Protocolos de Rede – UDP e MTFTP e às variáveis de EFI autenticadas descritas na especificação UEFI 2.3.1 Errata C Seção 7.2.

4. Como testar isso?

Se você estiver desenvolvendo o firmware e ele for baseado no Tiano Core, verifique quanto à vulnerabilidade mencionada na seção 2.1. Se você estiver usando o firmware de outro IBV, verifique com eles. Ou você pode fazer o teste por conta própria, conforme mencionado abaixo.

Você precisará do seguinte:

  • Computador em teste com firmware UEFI
  • Dispositivo PCI com Option ROM no computador em teste (como uma placa de vídeo)
  • Verifique se a Inicialização Segura está habilitada

Etapas de teste:

  1. Insira uma placa PCI de suplemento UEFI com Option ROM no computador em teste.

    Se você estiver usando uma placa de vídeo PCI para teste, conecte um monitor externo.

  2. Habilite a Inicialização Segura com as configurações abaixo:

    • PK: o PK ou o PK de teste autoassinado
    • KEK: MS KEK, KEK de teste da Fabrikam assinado por PK ou outro KEK
    • BD: NULL. (Deve ser NULL.)
    • DBX: NULL.
    • SecureBoot: a variável UEFI deve ser definida como true

  3. Reinicialize o computador

  4. Espere o seguinte resultado:

    • Se o firmware UEFI for implementado corretamente, o driver de Option ROM UEFI não será carregado, pois a presença de um Option ROM fará com que o firmware verifique o "BD" de um certificado. Como o "BD" é NULL, o driver UEFI não será carregado. Por exemplo, se você estiver usando a placa de vídeo para testar, verá que nada aparecerá na tela.
    • Se o firmware não for implementado corretamente, o driver UEFI será carregado usando o Option ROM, pois o firmware não verifica se há assinaturas no "BD". Por exemplo, se você estiver usando a placa de vídeo para teste, verá que o monitor conectado à placa do Option ROM terá uma tela.

    ![note] Não importa se o driver de Option ROM UEFI está assinado ou não, o Option ROM não será carregado quando o DB for nulo e o SB estiver habilitado (PK e KEK estão registrados).

Consulte os scripts de exemplo disponíveis no WHCK para gerar o PK e o KEK. O apêndice B tem scripts de exemplo e mais detalhes.

Você também pode referenciar o Apêndice A para obter outra abordagem para executar o teste acima. Essa abordagem não requer a configuração do BD como Null, mas precisa de um driver de Option ROM UEFI não assinado do IHV.

5. Como corrigir isso

Se o teste acima falhar, trabalhe com o IBV para adquirir as versões necessárias e configurá-las para validar Option ROMs. Verifique se o firmware passou no teste. Para computadores enviados, você precisará fazer uma atualização de firmware segura. Consulte a publicação NIST 800-147 e/ou consulte Diretrizes de Criação e Gerenciamento de Chaves de Inicialização Segura do Windows 8.1.

Você pode testar o computador e utilizar o Windows HCK como uma ferramenta de teste (não uma ferramenta de certificação) para testar a atualização de firmware segura.

5.1. Como assinar o driver

Caso você descubra que pode ter drivers não assinados nos Option ROMs UEFI, leia abaixo sobre como corrigir isso.

Assine cada driver de Option ROM individualmente. Isso interromperá o formato do PCI Option ROM. Você só precisa assinar o driver UEFI antes de criar o Option ROM combinado.

Antes de inserir o driver UEFI no OpROM, assine a imagem UEFI e teste-a com a Inicialização Segura ATIVADA e DESATIVADA no UEFI Shell (carregue/descarregue o arquivo de driver). Em seguida, coloque o driver assinado no Option ROM combinado.

Você pode direcionar o IHV para o centro do Microsoft SysDev para obter os Option ROMs UEFI assinados por meio de um serviço disponível no centro do SysDev.

5.2. Validação da atualização

Execute o teste mencionado acima para verificar se a vulnerabilidade não existe. Use os testes de HCK para verificar se não há regressões funcionais.

6. Recursos

Apêndice A: abordagem alternativa para testar usando drivers de Option ROM não assinados

Essa abordagem depende de obter ferramentas do IHV para garantir que o driver de Option ROM UEFI esteja assinado.

Você precisará do seguinte:

  • Computador em teste com firmware UEFI
  • Dispositivo PCI com um driver de Option ROM não assinado anexado ao computador em teste (como uma placa de vídeo)
  • Verifique se a Inicialização Segura está habilitada
  • Opção de ferramentas do IHV para detectar assinatura no driver de Option ROM, se não for aparente que o driver de Option ROM está assinado ou não

Se o firmware for implementado corretamente e o Option ROM não estiver assinado, a placa não fará a verificação por firmware e não carregará o driver na placa. O computador deve relatar um código de erro, como EFI_IMAGE_EXECUTION_AUTH_SIG_FOUND. Caso esteja usando uma placa de vídeo, você poderá ver que o computador mostra apenas uma tela preta, pois o driver de Option ROM não foi carregado.

Se o firmware for implementado incorretamente, esse teste funcionará.

Apêndice B: scripts para habilitar a Inicialização Segura com o BD NULL

Você pode usar o conjunto atual de variáveis de Inicialização Segura (PK e KEK) ou gerar variáveis de teste.

Veja abaixo as etapas usadas para gerar o PK de teste, o KEK e a configuração do BD como NULL. Verifique se a Inicialização Segura não está habilitada. Caso contrário, essas etapas exigiriam arquivos de compartimento UEFI assinados.

Observação

Definimos a variável de Inicialização Segura – BD, KEK e PK na ordem inversa para que não seja necessário assinar os arquivos de compartimento UEFI.

Antes dessa etapa, o computador deve estar no modo de instalação.

  1. Criar certificados KEK e PK

    Esta etapa exige a ferramenta makecert.exe disponível no SDK do Windows.

    MakeCert.exe -cy authority -len 2048 -m 60 -a sha256  -pe -ss my -n "CN=DO NOT SHIP - Fabrikam Test KEK CA" Fabrikam_Test_KEK_CA.cer
MakeCert.exe -cy authority -len 2048 -m 60 -a sha256  -pe -ss my -n "CN=DO NOT SHIP - Fabrikam Test PK" TestPK.cer

  2. Script para gerar o PK de teste

    Um exemplo é fornecido abaixo.

    this scripts demonstrates how to format the Platform key
NOTE The PK is actually set in the Enable_OEM_SecureBoot.ps1 script
Import-Module secureboot
$d = (pwd).Path

###############################################################################
Complete the following parameters
###############################################################################

$certname = "TestPK"
TODO change this path to where you have the PK.cer file
This is where you plugin the certificate generated by the HSM
$certpath = $d + "\" + $certname + ".cer"

Each signature has an owner SignatureOwner, which is a GUID identifying the agent which inserted the signature in the database.
Agents might include the operating PC or an OEM-supplied driver or application.
Agents may examine this field to understand whether they should manage the signature or not.
TODO replace with OEM SignatureOwner GUID.
You can use tools like Guidgen.exe tool in SDK or a similar tool to generate a GUID
$sigowner = "55555555-5555-5555-5555-555555555555"

$var = "PK"
$efi_guid = "{8BE4DF61-93CA-11d2-AA0D-00E098032B8C}"
$append = $false

###############################################################################
Everything else is calculated
###############################################################################

Workaround relative path bug
TODO substitute OEM with your OEM name
$siglist =  $certname + "_SigList.bin"
$serialization = $certname + "_SigList_Serialization_for_" + $var + ".bin"
$signature = $serialization + ".p7"

$appendstring = "set_"
$attribute = "0x27"
$example = "Example_SetVariable_Data-" + $certname + "_" + $appendstring + $var + ".bin"

Format-SecureBootUEFI -Name $var -SignatureOwner $sigowner -ContentFilePath $siglist -FormatWithCert -Certificate $certpath -SignableFilePath $serialization -Time 2011-05-21T13:30:00Z  -AppendWrite:$append

OutputFilePath - Specifies the name of the file created that contains the contents of what is set.
If this parameter is specified, then the content are not actually set, just stored into this file.
Please note if -OutputFilePath is provided the PK is not set like in this case. The master script sets it at the end.

Time - you can change the time below as long as it isn't in the future. Nothing wrong with keeping it as is.

Set-SecureBootUEFI -Name $var -Time 2011-05-21T13:30:00Z -ContentFilePath $siglist  -OutputFilePath $example -AppendWrite:$append

  3. Gerar KEK de teste ou usar seu próprio OEM KEK

    Você pode aproveitar seu próprio OEM KEK ou scripts do WHCK para isso.

    Um exemplo é fornecido abaixo.

    script to add option OEM KEK
Import-Module secureboot
$d = (pwd).Path

###############################################################################
Complete the following parameters
###############################################################################

$certname = "Fabrikam_Test_KEK_CA"
TODO change this path to where you have the PK.cer file
This is where you plugin the certificate generated by the HSM
$certpath = $d + "\" + $certname + ".cer"

TODO change this path to where you have the OEM_KEK.cer file
Each signature has an owner SignatureOwner, which is a GUID identifying the agent which inserted the signature in the database.
Agents might include the operating system or an OEM-supplied driver or application.
Agents may examine this field to understand whether they should manage the signature or not.
TODO replace with OEM SignatureOwner GUID.
You can use tools like Guidgen.exe tool in SDK or a similar tool to generate a GUID

$sigowner = "00000000-0000-0000-0000-000000000000"

$var = "KEK"
$efi_guid = "{8BE4DF61-93CA-11d2-AA0D-00E098032B8C}"
$append = $false

###############################################################################
Everything else is calculated
###############################################################################

$siglist = $certname + "_SigList.bin"
$serialization = $certname + "_SigList_Serialization_for_" + $var + ".bin"
$signature = $serialization + ".p7"
if ($append -eq $false)
{
$appendstring = "set_"
$attribute = "0x27"
} else
{
$appendstring = "append_"
$attribute = "0x67"
}
$example = "Example_SetVariable_Data-" + $certname + "_" + $appendstring + $var + ".bin"

Format-SecureBootUEFI -Name $var -SignatureOwner $sigowner -ContentFilePath $siglist -FormatWithCert -CertificateFilePath $certpath -SignableFilePath $serialization -Time 2011-05-21T13:30:00Z -AppendWrite:$append

-Time You can change the time below as long as it isn't in the future. Nothing wrong with keeping it as is.

Set-SecureBootUEFI -Name $var -Time 2011-05-21T13:30:00Z -ContentFilePath $siglist -OutputFilePath $example -AppendWrite:$append

  4. Definir o BD como Null e definir KEK e PK

    A primeira coisa que esse script faz é definir o BD como Null.

    Observação

    Lembre-se de que, se a CA de KEK de teste da Fabrikam for a única autoridade de certificação de KEK presente (o que significa que não há autoridade de certificação KEK do Windows), o computador poderá inicializar no Windows RE.

    Antes da execução do script, execute "Set-ExecutionPolicy Bypass -Force"

    Import-Module secureboot
try
{
Write-Host "Deleting db..."
Set-SecureBootUEFI -Name db -Time "2011-06-06T13:30:00Z" -Content $null
}
catch
{
}
Write-Host "Setting Fabrikam KEK..."
Set-SecureBootUEFI -Time 2011-05-21T13:30:00Z  -ContentFilePath Fabrikam_Test_KEK_CA_SigList.bin  -Name KEK

Write-Host "Setting self-signed Test PK..."
Set-SecureBootUEFI -Time 2011-05-21T13:30:00Z -ContentFilePath TestPK_SigList.bin  -Name PK

Write-Host "`n... operation complete.  `nSetupMode should now be 0 and SecureBoot should also be 0. Reboot and verify that Windows is correctly authenticated, and that SecureBoot changes to 1."

  5. Conectar a placa de Option ROM e testar

    O teste deve ser aprovado ou reproado com base na exatidão do firmware. Por exemplo:

    Se o Option ROM no firmware for implementado corretamente e você estiver usando uma placa de vídeo para teste, não deverá haver uma tela no monitor anexado.

    No entanto, se você estiver usando o firmware incorreto, a placa de vídeo deverá ter uma saída na tela.

Diretrizes de Criação e Gerenciamento de Chaves de Inicialização Segura do Windows

Visão geral da inicialização segura

Validação da Funcionalidade da Plataforma de Atualização de Firmware UEFI do Windows