Compartir a través de


Requisitos de UEFI para las ediciones de Windows en plataformas SoC

En este artículo se describen los requisitos de UEFI que se aplican a Windows 10 para las ediciones de escritorio (Home, Pro, Enterprise y Education) y Windows 10 Mobile. Para conocer los requisitos adicionales que solo se aplican a Windows 10 Mobile, consulte Requisitos de UEFI para Windows 10 Mobile.

Resumen de los requisitos

En la tabla siguiente se enumeran todos los requisitos actuales para el cumplimiento de UEFI tal y como se define en la especificación UEFI (sección 2.6 de la especificación UEFI 2.3.1). En esta tabla, el término Requisito explícito de Windows identifica cualquier protocolo o servicio al que llama directamente un componente de Windows. Aunque Windows usa explícitamente estos servicios, otros servicios y protocolos enumerados pueden ser implícita o explícitamente requeridos por una implementación de firmware principal, controladores de dispositivos EFI o por cadenas de herramientas de desarrollo e implementación.

Microsoft acoge con satisfacción los comentarios y comentarios de los implementadores en este conjunto de requisitos. Para cualquier requisito de cumplimiento de UEFI que se determine que no sea necesario para el sistema operativo o el firmware, es nuestra intención trabajar a través de UEFI.org para que estos requisitos de cumplimiento estén relajados para esta clase de dispositivo.

Para obtener más información sobre los requisitos específicos, consulte las secciones posteriores a la tabla.

Requisito Sección de especificación de UEFI Notas
Tabla del sistema EFI 4.3 Requisito explícito de Windows
Servicios de arranque de EFI 6.0
Servicios de eventos, temporizadores y tareas 6.1
Servicios de memoria 6.2 Requisito explícito de Windows
Servicios de controlador de protocolos 6.3 Requisito explícito de Windows
Servicios de imagen 6.4 Requisito explícito de Windows
Servicios varios 6.5 Requisito explícito de Windows
Servicios en tiempo de ejecución de EFI 7.0
Servicios de hora 7.3 Requisito explícito de Windows
Servicios de variables 7.2 Requisito explícito de Windows
Servicios varios 7.5 Requisito explícito de Windows
Protocolos UEFI necesarios
Protocolo de imagen cargada por EFI 8.1
Protocolo de ruta de acceso del dispositivo de imagen cargada por EFI 8,2
Protocolo de ruta de acceso del dispositivo EFI 9.2 Requisito explícito de Windows
Protocolo de utilidades de ruta de acceso de dispositivo EFI 9.5
Protocolo de descompresión de EFI 18.5
Protocolo de intérprete EBC 20.11
Protocolos UEFI requeridos condicionalmente
Protocolo de entrada de texto simple EFI 11.3 Requisito explícito de Windows
Protocolo EX de entrada de texto simple EFI 11.2
Protocolo de salida de texto simple EFI 11.4
Protocolo de salida de gráficos EFI 11.9 Requisito explícito de Windows
Protocolo detectado de EDID de EFI 11.9.1
Protocolo activo EFI EDID 11.9.1
Protocolo de EFI de EFI de E/S 12.8 Requisito explícito de Windows
Protocolo de EFI para E/S de disco 12.7
Protocolo de sistema de archivos simple EFI 12,4
Protocolo de intercalación Unicode de EFI 12.10
Protocolo de red simple EFI 21,1
Protocolo de código base EFI PXE 21,3
Protocolo de servicios de integridad de arranque EFI 21,5
Protocolo de EFI de EFI de E/S serie 11,8
Enlace de arm UEFI 2.3.5 Requisito explícito de Windows
Requisitos de seguridad
Arranque seguro 27.0 Requisito explícito de Windows
Requisitos del administrador de arranque 3.1, 3.3 Requisito explícito de Windows

Requisitos de la tabla del sistema EFI

La tabla del sistema EFI debe cumplir la definición estándar en el nivel de revisión implementado. La tabla de configuración a la que apunta la tabla del sistema EFI debe incluir los dos GUID y sus punteros asociados descritos en la tabla siguiente.

GUID Descripción
EFI_ACPI_Table GUID Este GUID debe apuntar al puntero de descripción del sistema raíz ACPI (RSDP) para la plataforma.
SMBIOS_Table GUID Este GUID debe apuntar a la estructura de punto de entrada SMBIOS.

Windows requiere la especificación SMBIOS, en el nivel de revisión 2.4 o superior. Las secciones 3.2, "Estructuras y datos necesarios" y 4, "Directrices de conformidad", son necesarias. Hay disponible una prueba de compatibilidad de Windows SMBIOS.

Requisitos de servicios de arranque de EFI

En la tabla siguiente se enumeran los requisitos de los servicios de arranque EFI para Windows.

Servicio de arranque EFI Requisito
Servicios de memoria Windows requiere todos los servicios de memoria.
Servicios de controlador de protocolos Windows requiere los siguientes servicios de controlador de protocolo:

OpenProtocol()
CloseProtocol()
LocateDevicePath()
LocateHandle()
Servicios de imagen Windows requiere los siguientes servicios de imagen:

ExitBootServices()
Varios servicios de arranque Windows requiere los siguientes servicios de arranque varios:

Stall()

Nota: La implementación de Stall() es necesaria para tener un error determinista (repetible) de modo que la corrección de errores o la cancelación se puedan realizar de forma confiable.

Requisitos de servicios en tiempo de ejecución de EFI

En la tabla siguiente se enumeran los requisitos de servicios en tiempo de ejecución de EFI para Windows.

Servicio en tiempo de ejecución de EFI Requisito
Servicios de hora Windows requiere los siguientes servicios de hora:

GetTime()
SetTime()

Nota: Solo se llamará a los servicios de hora durante el arranque (antes de ExitBootServices()) para acceder al hardware de hora del día de la plataforma.
Servicios de variables Todos los servicios de variables de UEFI son necesarios para administrar varios dispositivos de arranque y variables de seguridad en la clase de destino de los sistemas.
Varios servicios en tiempo de ejecución Windows requiere los siguientes servicios en tiempo de ejecución varios:

ResetSystem()

Nota: La implementación resetSystem() debe admitir las opciones de restablecimiento y apagado.

Requisitos de protocolo

En la tabla siguiente se describen los protocolos UEFI que Windows necesita para realizar funciones específicas durante el arranque.

Protocolo Requisito
Protocolo de salida de gráficos Windows requiere el Protocolo de salida de gráficos (GOP). Los requisitos específicos del búfer de fotogramas son:

Para las pantallas integradas, HorizontalResolution y VerticalResoluton deben ser la resolución nativa del panel.

Para las pantallas externas, HorizontalResolution y VerticalResoluton deben ser la resolución nativa de la pantalla, o bien, si no se admite, los valores más altos admitidos por el adaptador de vídeo y la pantalla conectada.

PixelsPerScanLine debe ser igual a HorizontalResolution.

PixelFormat debe ser PixelBlueGreenRedReserved8BitPerColor. Se requiere un búfer de marco físico; PixelBltOnly no se admite.

Cuando la ejecución se entrega a una aplicación de arranque UEFI, el administrador de arranque de firmware y el firmware no deben usar el búfer de fotogramas para ningún propósito. El búfer de fotogramas debe seguir examinandose después de que se hayan cerrado los servicios de arranque.
Salida de visualización alternativa El firmware UEFI debe admitir el arranque mediante cualquier conector de pantalla compatible con el hardware. Si un panel interno está conectado y visible, se debe usar el panel interno. Todas las salidas que tienen pantallas conectadas físicamente deben mostrar la pantalla de arranque. Para las pantallas conectadas, el firmware de UEFI debe:

Inicialice la salida con el modo nativo de la pantalla, si se puede determinar la resolución nativa.

Si no es posible un modo nativo, debe inicializarse en el modo compatible más alto.

Si no se pueden determinar las capacidades de visualización, la pantalla conectada debe inicializarse en un modo que se sabe que es compatible con tantos monitores como sea posible (normalmente 640 x 480 o 1024x768, a 60 Hz).
Entrada en tiempo de arranque El protocolo de entrada de texto simple EFI es necesario para tomar opciones de arranque u otras selecciones de menú en sistemas que tienen teclados integrados o teclados conectados. En el caso de los sistemas sin teclado, se recomiendan tres botones en el entorno de arranque:

Botón Iniciar
Botón Subir volumen
Botón Bajar volumen

Las pulsaciones de botón se deben notificar a través del protocolo de entrada de texto simple EFI mediante su asignación a las teclas de teclado siguientes, respectivamente:

Tecla Windows
Tecla flecha arriba
Tecla de flecha abajo
Arranque de almacenamiento local Windows requiere la compatibilidad de Bloquear protocolo de E/S y Protocolo de ruta de acceso del dispositivo para la solución de almacenamiento que contiene la partición del sistema EFI y la partición del sistema operativo Windows. Para arrancar desde el almacenamiento flash que requiere el nivel de desgaste u otra administración flash, debe implementarse en el firmware (no en una aplicación UEFI).

Requisitos de seguridad

Windows tiene requisitos de seguridad en las áreas de Arranque seguro, Arranque medido, Criptografía y Protección de datos. Estos requisitos se detallan en la tabla siguiente. Además, para aquellas áreas en las que el hardware soC impide el cumplimiento del estándar existente (TPM, RTC, etc.), se están desarrollando requisitos adicionales. Se describen al final de la tabla.

Área Requisito
General
  • Requisito 1: OBLIGATORIO. La plataforma cumplirá todos los requisitos especificados en esta sección.

  • Requisito 2: OBLIGATORIO. Las plataformas deben ser de la clase UEFI Tres sin módulo de compatibilidad compatible instalado o instalable. La emulación del BIOS y el arranque heredado de PC/AT deben estar deshabilitados.

Arranque seguro UEFI
  • Requisito 3: OBLIGATORIO. El arranque seguro tal y como se define en la sección 27 de UEFI v2.3.1 debe estar habilitado y con una base de datos de firma (EFI_IMAGE_SECURITY_DATABASE) necesaria para arrancar la máquina de forma segura previamente aprovisionada. El contenido inicial de la base de datos de firma viene determinado por el OEM, en función de los controladores UEFI de terceros necesarios, las necesidades de recuperación y el cargador de arranque del sistema operativo instalados en la máquina, pero se incluirá una firma de EFI_CERT_X509 proporcionada por Microsoft. No habrá firmas adicionales.

  • Requisito 4: OBLIGATORIO. Se requiere presencia de la base de datos de firma "prohibido" de UEFI (EFI_IMAGE_SECURITY_DATABASE1).

  • Requisito 5: OBLIGATORIO. Una KEK UEFI proporcionada por Microsoft se incluirá en la base de datos de LA UEFI KEK. No habrá keK adicionales. Microsoft proporciona la KEK en forma de firma EFI_CERT_X509.

  • Requisito 6: OBLIGATORIO. Una clavede publicación PK estará presente y almacenada en el flash de firmware. Nota: Dado que PKpriv (el homólogo de clave privada de PKpub) controla la directiva de arranque seguro en todos los dispositivos aprovisionados con PKpub, su protección y uso deben protegerse estrechamente.

  • Requisito 7: OBLIGATORIO. Las bases de datos de firma iniciales se almacenarán en flash de firmware y solo se pueden actualizar con una actualización de firmware firmada por OEM o a través de escritura de variable autenticada de UEFI.

  • Requisito 8: OBLIGATORIO. Las imágenes de la ruta de acceso de arranque que produce un error en la comprobación de la firma no se deben ejecutar y el motivo del error se agregará al EFI_IMAGE_EXECUTION_TABLE. Además, el enfoque recomendado en estas situaciones es que el administrador de arranque UEFI inicia la recuperación según una estrategia específica del OEM.

  • Requisito 9: OBLIGATORIO. La invalidación de usuario presente físicamente no debe permitirse para imágenes UEFI que produzcan un error en la comprobación de la firma.

  • Requisito 10: OPCIONAL. Un OEM puede implementar la posibilidad de que un usuario presente físicamente desactive el arranque seguro con acceso a PKpriv o con presencia física a través de la configuración del firmware. El acceso a la configuración del firmware puede estar protegido por medios específicos de la plataforma (contraseña de administrador, tarjeta inteligente, configuración estática, etc.)

  • Requisito 11: OBLIGATORIO si se implementa el requisito 10. Si el arranque seguro está desactivado, no se podrá acceder a todas las variables UEFI existentes.

  • Requisito 12: OPCIONAL. Un OEM puede implementar la capacidad de un usuario presente físicamente para seleccionar entre dos modos de arranque seguro en la configuración del firmware: "Personalizado" y "Estándar". El modo personalizado permite una mayor flexibilidad, tal como se especifica en lo siguiente.

  • Requisito 13: OBLIGATORIO si se implementa el requisito 12. Será posible volver a habilitar un arranque seguro deshabilitado en modo personalizado estableciendo un PK específico del propietario. La administración continuará tal y como se define en la sección 27.5 de la especificación UEFI v2.3.1: Intercambio de claves firmware/sistema operativo. En modo personalizado, el propietario del dispositivo puede establecer su elección de firmas en las bases de datos de firma.

  • Requisito 14: OBLIGATORIO si se implementa el requisito 12. La configuración del firmware indicará si el arranque seguro está activado y si está funcionado en modo estándar o personalizado. La configuración del firmware proporcionará una opción para volver del modo personalizado al estándar.

  • Requisito 15: OBLIGATORIO. Si la configuración de firmware se restablece a los valores predeterminados de fábrica, se borrarán todas las variables protegidas de conjunto personalizado y se restablecerá elpub PK original junto con las bases de datos de firma originales aprovisionadas por el fabricante.

  • Requisito 16: OBLIGATORIO. La firma de controladores usará la opción Authenticode (WIN_CERT_TYPE_PKCS_SIGNED_DATA).

  • Requisito 17: OBLIGATORIO. Compatibilidad con el EFI_IMAGE_EXECUTION_INFO_TABLE (es decir, creación y almacenamiento de información sobre imágenes iniciadas o no iniciadas durante el arranque).

  • Requisito 18: OBLIGATORIO. Compatibilidad con GetVariable() para el EFI_IMAGE_SECURITY_DATABASE (tanto la base de datos de firmas autorizadas como prohibidas).

  • Requisito 19: OBLIGATORIO. Compatibilidad con SetVariable() para la EFI_IMAGE_SECURITY_DATABASE (tanto la base de datos de firmas autorizadas como prohibidas), mediante la KEK de Microsoft para la autenticación.

  • Requisito 20: OBLIGATORIO. EFI_HASH_SERVICE_BINDING_PROTOCOL: Soporte técnico del servicio: CreateChild(), DestroyChild().

  • Requisito 21: OBLIGATORIO. EFI_HASH_PROTOCOL. Compatibilidad con el servicio: Hash(). Compatibilidad con los algoritmos hash SHA_1 y SHA-256. Debe admitir el paso de un mensaje de al menos 10 Mbytes de longitud.

Arranque medido de UEFI

Los siguientes requisitos no implican una necesidad de una implementación de TCG TPM; sin embargo, implican una necesidad de funcionalidad equivalente para las áreas afectadas.

La compatibilidad con la plataforma puede proporcionarse mediante una implementación de firmware de un TPM que se ejecuta en el entorno de ejecución seguro, superpuesta al motor de aceleración criptográfica y aprovechando el almacenamiento aislado. Microsoft puede proporcionar software de referencia para esta implementación de TPM para su uso por parte del proveedor. Esto está sujeto a debates adicionales.

  • Requisito 22: OBLIGATORIO. La plataforma se ajustará al protocolo EFI especificado en el protocolo EFI del entorno de ejecución de confianza de UEFI.

  • Requisito 23: OBLIGATORIO. La plataforma cumplirá la especificación de la plataforma TCG EFI con las siguientes adiciones:

    • En las plataformas que admiten la interfaz definida en el Protocolo EFI trEE, el resumen de PKpub se extenderá a TPM PCR[03] como evento de EV_EFI_VARIABLE_CONFIG.

    • El resumen del contenido de la base de datos de firmas autorizada (consulte la sección 27.8 de la lista de especificación UEFI v2.3.1) debe extenderse en el arranque medido como un evento de EV_EFI_VARIABLE_CONFIG. La operación de ampliación será para TPM PCR[03].

    • Será posible que un cliente UEFI lea y analice la lista de certificados mediante la variable EFI_IMAGE_SECURITY_DATABASE y valide el resumen con el valor extendido.

    • TCG_PCR_EVENT valores de resumen deben ser SHA-256, no SHA-1.

  • Requisito 24: OBLIGATORIO. La plataforma debe implementar memoryOverwriteRequestControl definida en la especificación de mitigación de ataques de restablecimiento de plataforma TCG.

Criptografía
  • Requisito 25: OBLIGATORIO. La plataforma proporcionará el EFI_HASH_PROTOCOL (UEFI v2.3.1 sección 27.4) para la descarga de operaciones hash criptográficas. Se debe admitir SHA-256.

  • Requisito 26: OBLIGATORIO. La plataforma admitirá el EFI_RNG_PROTOCOL definido por Microsoft para la lectura previa del sistema operativo de entropía.

Protección de los datos
  • Requisito 27: OBLIGATORIO. La plataforma debe admitir variables EFI con cualquier combinación de los siguientes atributos de variable UEFI establecidos:

    • EFI_VARIABLE_BOOTSERVICE_ACCESS

    • EFI_VARIABLE_NON_VOLATILE

    • EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS

Otros requisitos de seguridad

Windows en plataformas SoC requiere los siguientes requisitos adicionales.

  • Microsoft ha definido el protocolo para recopilar entropía desde una plataforma UEFI. Aunque no es un requisito de UEFI, Windows requiere este protocolo en plataformas soC. Para obtener más información sobre este protocolo, consulte Protocolo de recopilación de entropía UEFI.

  • Novedades de base de datos de firma ueFI. Se ha adoptado un nuevo mecanismo para actualizar variables autenticadas en la sección 27 de UEFI 2.3.1. Windows requiere este mecanismo.

  • Entorno de ejecución de confianza. Microsoft ha desarrollado un protocolo EFI para interactuar con un entorno de ejecución de confianza (TrEE), similar en funcionalidad a un subconjunto de un módulo de plataforma segura (TCG) de grupo de computación segura (TCG). El protocolo EFI aprovecha en gran medida, "Protocolo TCG EFI", versión 1.2 Revisión 1.00, 9 de junio de 2006, por el grupo de computación de confianza.

    Para obtener más información, consulte Protocolo EFI del entorno de ejecución de confianza ueFI.

Requisitos del administrador de arranque de firmware

El administrador de arranque de firmware debe admitir el comportamiento de arranque predeterminado definido en la sección 3.3 de la especificación. Además, para admitir variables de arranque múltiple y definidas globalmente y los requisitos del Administrador de arranque de la sección 3.1 de la especificación son necesarios.

Requisitos de enlace de Arm de UEFI

El enlace de arm ueFI incluye requisitos específicos de la plataforma Arm necesaria para ser compatibles con la especificación UEFI. Windows requiere todo el contenido del enlace arm que se aplica a ARMv7. Dado que Windows no admite nada anterior a ARMv7, los requisitos del enlace que son específicos de ARMv6k y a continuación son opcionales.

El enlace especifica, por ejemplo, cómo se debe configurar la MMU y cómo se debe asignar la memoria física. El enlace también especifica que las llamadas realizadas a los protocolos y servicios ueFI deben realizarse solo en el ISA de Arm, lo que significa que el software que se ejecuta en Thumb2 o Thumb tendría que volver al modo Arm antes de llamar a funciones UEFI.

Requisitos de inicio del multiprocesador arm de UEFI

Microsoft ha desarrollado un protocolo para iniciar varios núcleos arm en una plataforma UEFI de varios procesadores. Windows requiere este protocolo en plataformas Arm que no admiten power State Coordination Interface (PSCI). Las plataformas que admiten PSCI no deben usar este protocolo. Para obtener más información sobre este protocolo, consulte el documento Inicio de multiprocesador en plataformas basadas en ARM ueFI en el sitio web de arquitectura de componentes ACPI (ACPICA).

Requisitos de configuración de la plataforma

El firmware es responsable de colocar el hardware del sistema en un estado bien definido antes de entregarlo al cargador del sistema operativo. En la tabla siguiente se definen los requisitos de configuración de la plataforma relacionados.

Requisito Descripción
Ruta de acceso de arranque El firmware debe inicializar la plataforma hasta el punto en el que Windows puede acceder al dispositivo de arranque a través de UEFI y cargar el kernel. Cualquier dispositivo implicado en la jerarquía para leer desde el dispositivo de arranque debe estar reloj y encendido a una velocidad razonable, dadas las consideraciones de rendimiento y energía. El núcleo base del procesador también debe ser reloj y encendido a una velocidad razonable, para que el sistema pueda arrancar de forma oportuna sin purgar la batería.
Recursos principales del sistema Los recursos principales del sistema que se exponen al sistema operativo a través de las tablas ACPI deben encenderse y estar en el reloj. Los recursos principales del sistema incluyen controladores de interrupción, temporizadores y controladores DMA que el sistema operativo debe administrar. Además, las interrupciones deben enmascararse mediante la llamada a ExitBootServices() hasta que el controlador de dispositivo asociado en el sistema operativo desenmascare y vuelva a habilitar las interrupciones en el dispositivo. Si las interrupciones están habilitadas durante los servicios de arranque, se supone que el firmware los administra.
Depuración Windows admite la depuración a través del host USB 3 (XHCI), el host USB 2 (EHCI)1, IEEE 1394, las interfaces de función USB y serie (así como adaptadores Ethernet PCI). Al menos uno de estos debe ser alimentado, reloj e inicializado por el firmware antes de la entrega del sistema operativo. Cualquier opción que se proporcione, debe tener un puerto expuesto para fines de depuración y el controlador debe estar asignado a la memoria o estar conectado a través de un bus periférico dedicado (no compartido).
Otros requisitos de configuración de la plataforma Cualquier configuración de relleno y multiplexación de patillas debe completarse en el firmware antes de entregar el control al cargador del sistema operativo.

Requisitos de instalación

Windows requiere que la partición del sistema operativo resida en una solución de almacenamiento con particiones GPT. El almacenamiento con particiones mbR se puede usar como almacenamiento de datos. Como se define en la especificación UEFI, una plataforma UEFI requiere una partición del sistema dedicada. Windows requiere esta partición del sistema dedicada, denominada partición del sistema EFI (ESP).

Requisito de interfaz de prueba de seguridad de hardware (HSTI)

La plataforma debe implementar la interfaz de prueba de seguridad de hardware y la plataforma es necesaria para compartir documentación y herramientas, tal y como se especifica en la Especificación de prueba de seguridad de hardware.

Requisitos mínimos de UEFI para Windows en plataformas SoC

Requisitos de UEFI para Windows 10 Mobile

Requisitos de UEFI para la compatibilidad con flashing USB