Partager via

Exigences UEFI pour les éditions De Windows sur les plateformes SoC

  • Article

Cet article décrit les exigences UEFI qui s’appliquent aux Windows 10 pour les éditions de bureau (Famille, Professionnel, Entreprise et Éducation) et Windows 10 Mobile. Pour obtenir des exigences supplémentaires qui s’appliquent uniquement à Windows 10 Mobile, consultez Exigences UEFI pour Windows 10 Mobile.

Résumé des exigences

Le tableau suivant répertorie toutes les exigences actuelles de conformité UEFI telles que définies dans la spécification UEFI (section 2.6 de la spécification UEFI 2.3.1). Dans ce tableau, le terme Spécification Windows explicite identifie tout protocole ou service appelé directement par un composant Windows. Bien que seuls ces services soient explicitement utilisés par Windows, d’autres services et protocoles répertoriés peuvent être implicitement ou explicitement requis par une implémentation de microprogramme de base, des pilotes de périphérique EFI ou par des chaînes d’outils de développement et de déploiement.

Microsoft accueille les commentaires et commentaires des implémenteurs sur cet ensemble d’exigences. Pour toutes les exigences de conformité UEFI qui ne sont pas requises par le système d’exploitation ou le microprogramme, nous avons l’intention de passer en revue UEFI.org d’assouplir ces exigences de conformité pour cette classe d’appareil.

Pour plus d’informations sur les exigences spécifiques, consultez les sections après le tableau.

Condition requise Section spécification UEFI Notes
Table système EFI 4.3 Spécification Windows explicite
Services de démarrage EFI 6.0
Services d’événements, de minuteur et de tâches 6.1
Services de mémoire 6.2 Spécification Windows explicite'
Services de gestionnaire de protocole 6.3 Spécification Windows explicite
Services d’image 6.4 Spécification Windows explicite
Services divers 6.5 Spécification Windows explicite
Services de runtime EFI 7.0
Services de temps 7.3 Spécification Windows explicite
Services de variables 7.2 Spécification Windows explicite
Services divers 7.5 Spécification Windows explicite
Protocoles UEFI requis
Protocole d’image chargé par EFI 8.1
Protocole de chemin d’appareil d’image chargé par EFI 8,2
Protocole de chemin d’accès d’appareil EFI 9.2 Spécification Windows explicite
Protocole d’utilitaires de chemin d’accès d’appareil EFI 9.5
Protocole de décompression EFI 18.5
Protocole d’interpréteur EBC 20.11
Protocoles UEFI requis de manière conditionnelle
Protocole d’entrée de texte simple EFI 11.3 Spécification Windows explicite
Protocole EX d’entrée de texte simple EFI 11.2
Protocole de sortie de texte simple EFI 11,4
Protocole de sortie graphique EFI 11.9 Spécification Windows explicite
Protocole découvert EDID EFI 11.9.1
Protocole actif EDID EFI 11.9.1
Protocole EFI block IO 12.8 Spécification Windows explicite
Protocole D’E/S de disque EFI 12.7
Protocole de système de fichiers simple EFI 12,4
Protocole de classement Unicode EFI 12.10
Protocole réseau simple EFI 21,1
Protocole de code de base PXE EFI 21,3
Protocole des services d’intégrité de démarrage EFI 21,5
Protocole EFI d’E/S série 11,8
Liaison UEFI Arm 2.3.5 Spécification Windows explicite
Spécifications de sécurité
Démarrage sécurisé 27.0 Spécification Windows explicite
Configuration requise pour le gestionnaire de démarrage 3.1, 3.3 Spécification Windows explicite

Configuration requise pour la table système EFI

La table système EFI doit être conforme à la définition standard au niveau de la révision implémentée. La table de configuration pointée par la table système EFI doit inclure les deux GUID et leurs pointeurs associés décrits dans le tableau suivant.

GUID Description
EFI_ACPI_Table GUID Ce GUID doit pointer vers le pointeur de description du système racine (RSDP) ACPI pour la plateforme.
SMBIOS_Table GUID Ce GUID doit pointer vers la structure du point d’entrée SMBIOS.

Windows nécessite la spécification SMBIOS, au niveau de révision 2.4 ou supérieur. Les sections 3.2, « Structures et données requises », et 4, « Directives de conformité », sont obligatoires. Un test de compatibilité Windows SMBIOS est disponible.

Conditions requises pour les services de démarrage EFI

Le tableau suivant répertorie les exigences des services de démarrage EFI pour Windows.

Service de démarrage EFI Condition requise
Services de mémoire Windows nécessite tous les services de mémoire.
Services de gestionnaire de protocole Windows nécessite les services de gestionnaire de protocole suivants :

OpenProtocol()
CloseProtocol()
LocateDevicePath()
LocateHandle()
Services d’image Windows nécessite les services d’image suivants :

ExitBootServices()
Services de démarrage divers Windows nécessite les divers services de démarrage suivants :

Stall()

Note: L’implémentation Stall() doit avoir une erreur déterministe (reproductible) de telle sorte que la correction ou l’annulation d’erreur puisse être effectuée de manière fiable.

Conditions requises pour les services d’exécution EFI

Le tableau suivant répertorie les exigences des services d’exécution EFI pour Windows.

Service runtime EFI Condition requise
Services de temps Windows nécessite les services de temps suivants :

GetTime()
SetTime()

Note: Les services de temps sont uniquement appelés pendant le démarrage (avant ExitBootServices()) pour accéder au matériel de l’heure de la journée de la plateforme.
Services de variables Tous les services de variables UEFI sont requis pour gérer plusieurs appareils de démarrage et variables de sécurité sur la classe de systèmes cible.
Services d’exécution divers Windows nécessite les divers services d’exécution suivants :

ResetSystem()

Note: L’implémentation ResetSystem() doit prendre en charge les options de réinitialisation et d’arrêt.

Configuration requise pour le protocole

Le tableau suivant décrit les protocoles UEFI requis par Windows pour accomplir des fonctions spécifiques pendant le démarrage.

Protocol Condition requise
Protocole de sortie graphique Windows nécessite le protocole GOP (Graphics Output Protocol). Les exigences spécifiques de la mémoire tampon de trame sont les suivantes :

Pour les affichages intégrés, HorizontalResolution et VerticalResoluton doivent être la résolution native du panneau.

Pour les affichages externes, HorizontalResolution et VerticalResoluton doivent être la résolution native de l’affichage ou, si cela n’est pas pris en charge, les valeurs les plus élevées prises en charge par la carte vidéo et l’affichage connecté.

PixelsPerScanLine doit être égal à HorizontalResolution.

PixelFormat doit être PixelBlueGreenRedReserved8BitPerColor. Une mémoire tampon de trame physique est requise ; PixelBltOnly n’est pas pris en charge.

Lorsque l’exécution est transmise à une application de démarrage UEFI, le gestionnaire de démarrage du microprogramme et le microprogramme ne doivent pas utiliser la mémoire tampon de trame à quelque fin que ce soit. La mémoire tampon de trame doit continuer à être analysée une fois les services de démarrage arrêtés.
Autre sortie d’affichage Le microprogramme UEFI doit prendre en charge le démarrage à l’aide de n’importe quel connecteur d’affichage pris en charge par le matériel. Si un panneau interne est connecté et visible, le panneau interne doit être utilisé. Toutes les sorties qui ont des affichages physiquement connectés doivent afficher l’écran de démarrage. Pour les affichages connectés, le microprogramme UEFI doit :

Initialisez la sortie avec le mode natif de l’affichage, si la résolution native peut être déterminée.

Si un mode natif n’est pas possible, il doit être initialisé vers le mode compatible le plus élevé.

Si les fonctionnalités d’affichage ne peuvent pas être déterminées, l’affichage connecté doit être initialisé dans un mode connu pour être compatible avec autant de moniteurs que possible (généralement 640 x 480 ou 1 024 x 768, à 60 Hz).
Entrée au démarrage Le protocole EFI Simple Text Input Protocol est requis pour effectuer des choix de démarrage ou d’autres sélections de menu sur les systèmes qui ont des claviers intégrés ou des claviers attachés. Pour les systèmes sans clavier, trois boutons sont recommandés dans l’environnement de démarrage :

Bouton Démarrer
Bouton Augmenter le volume
Bouton Réduire le volume

Les appuis sur les boutons doivent être signalés via le protocole EFI Simple Text Input Protocol en les mappant aux touches de clavier suivantes, respectivement :

Touche Windows
Flèche vers le haut
Flèche vers le bas
Démarrage du stockage local Windows nécessite la prise en charge du protocole d’E/S de bloc et du protocole device path pour la solution de stockage qui contient la partition système EFI et la partition du système d’exploitation Windows. Pour le démarrage à partir d’un stockage flash qui nécessite un nivellement de l’usure ou une autre gestion flash, cela doit être implémenté dans le microprogramme (et non dans une application UEFI).

Spécifications de sécurité

Windows a des exigences de sécurité dans les domaines du démarrage sécurisé, du démarrage mesuré, du chiffrement et de la protection des données. Ces exigences sont détaillées dans le tableau suivant. En outre, pour les domaines dans lesquels le matériel SoC empêche la conformité à la norme existante (TPM, RTC, etc.), des exigences supplémentaires sont en cours de développement. Ceux-ci sont décrits à la fin du tableau.

Domaine Condition requise
Général

  • Condition requise 1 : OBLIGATOIRE. La plateforme doit être conforme à toutes les exigences spécifiées dans cette section.

  • Condition 2 : OBLIGATOIRE. Les plateformes doivent être de la classe UEFI 3 sans module de prise en charge de compatibilité installé ou installable. L’émulation du BIOS et le démarrage hérité du PC/AT doivent être désactivés.
Démarrage sécurisé UEFI

  • Condition requise 3 : OBLIGATOIRE. Le démarrage sécurisé tel que défini dans la section 27 d’UEFI v2.3.1 doit être fourni avec une base de données de signatures (EFI_IMAGE_SECURITY_DATABASE) nécessaire pour démarrer la machine en toute sécurité préconfigurée. Le contenu initial de la base de données de signature est déterminé par l’OEM, en fonction des pilotes UEFI tiers requis, des besoins de récupération et du chargeur de démarrage du système d’exploitation installé sur la machine, mais une signature EFI_CERT_X509 fournie par Microsoft doit être incluse. Aucune signature supplémentaire ne sera présente.

  • Condition requise 4 : OBLIGATOIRE. La présence de la base de données de signatures UEFI « interdite » (EFI_IMAGE_SECURITY_DATABASE1) est requise.

  • Condition requise 5 : OBLIGATOIRE. Une clé KEK UEFI fournie par Microsoft doit être incluse dans la base de données UEFI KEK. Aucune clé KEK supplémentaire ne sera présente. Microsoft fournit la clé KEK sous la forme d’une signature EFI_CERT_X509.

  • Condition requise 6 : OBLIGATOIRE. Une clépub PK doit être présente et stockée dans le flash du microprogramme. Remarque : Étant donné que PKpriv (l’équivalent de clé privée de PKpub) contrôle la stratégie de démarrage sécurisé sur tous les appareils approvisionnés avec PKpub, sa protection et son utilisation doivent être étroitement surveillées.

  • Condition requise 7 : OBLIGATOIRE. Les bases de données de signature initiales doivent être stockées dans le microprogramme flash et peuvent être mises à jour uniquement avec une mise à jour du microprogramme signée par l’OEM ou via l’écriture de variable authentifiée UEFI.

  • Condition requise 8 : OBLIGATOIRE. Les images du chemin de démarrage qui échouent à la vérification de signature ne doivent pas être exécutées, et la raison de l’échec doit être ajoutée à l’EFI_IMAGE_EXECUTION_TABLE. En outre, l’approche recommandée dans ces situations est que le gestionnaire de démarrage UEFI lance la récupération selon une stratégie spécifique à l’OEM.

  • Condition 9 : OBLIGATOIRE. La substitution d’utilisateur physiquement présente ne doit pas être autorisée pour les images UEFI qui échouent à la vérification de la signature.

  • Condition requise 10 : FACULTATIF. Un OEM peut implémenter la possibilité pour un utilisateur physiquement présent de désactiver le démarrage sécurisé avec accès aupriv PK ou avec présence physique via la configuration du microprogramme. L’accès à la configuration du microprogramme peut être protégé par des moyens spécifiques à la plateforme (mot de passe administrateur, carte intelligent, configuration statique, etc.)

  • Condition requise 11 : OBLIGATOIRE si la condition 10 est implémentée. Si le démarrage sécurisé est désactivé, toutes les variables UEFI existantes ne sont pas accessibles.

  • Condition requise 12 : FACULTATIF. Un OEM peut implémenter la possibilité pour un utilisateur physiquement présent de choisir entre deux modes de démarrage sécurisé dans la configuration du microprogramme : « Personnalisé » et « Standard ». Le mode personnalisé offre plus de flexibilité, comme indiqué dans la section suivante.

  • Condition requise 13 : OBLIGATOIRE si la condition 12 est implémentée. Il est possible de réactiver un démarrage sécurisé désactivé en mode personnalisé en définissant un PK spécifique au propriétaire. L’administration doit continuer comme défini dans la section 27.5 de la spécification UEFI v2.3.1 : Échange de microprogrammes/de clés de système d’exploitation. En mode personnalisé, le propriétaire de l’appareil peut définir son choix de signatures dans les bases de données de signature.

  • Condition requise 14 : OBLIGATOIRE si la condition 12 est implémentée. La configuration du microprogramme doit indiquer si le démarrage sécurisé est activé et s’il est utilisé en mode Standard ou Personnalisé. La configuration du microprogramme doit fournir une option permettant de revenir du mode Personnalisé au mode Standard.

  • Condition requise 15 : OBLIGATOIRE. Si les paramètres du microprogramme sont réinitialisés aux paramètres d’usine par défaut, toutes les variables protégées personnalisées doivent être effacées et lapublication PK d’origine doit être rétablie avec les bases de données de signature d’origine approvisionnées par le fabricant.

  • Condition requise 16 : OBLIGATOIRE. La signature du pilote doit utiliser l’option Authenticode (WIN_CERT_TYPE_PKCS_SIGNED_DATA).

  • Condition requise 17 : OBLIGATOIRE. Prise en charge du EFI_IMAGE_EXECUTION_INFO_TABLE (c’est-à-dire la création et le stockage d’informations sur les images démarrées ou non démarrées pendant le démarrage).

  • Condition requise 18 : OBLIGATOIRE. Prise en charge de GetVariable() pour le EFI_IMAGE_SECURITY_DATABASE (base de données de signatures autorisée et interdite).

  • Condition requise 19 : OBLIGATOIRE. Prise en charge de SetVariable() pour le EFI_IMAGE_SECURITY_DATABASE (base de données de signature autorisée et interdite), à l’aide de la clé KEK Microsoft pour l’authentification.

  • Condition requise 20 : OBLIGATOIRE. EFI_HASH_SERVICE_BINDING_PROTOCOL : Prise en charge du service : CreateChild(), DestroyChild().

  • Condition requise 21 : OBLIGATOIRE. EFI_HASH_PROTOCOL. Prise en charge du service : Hash(). Prise en charge des algorithmes de hachage SHA_1 et SHA-256. Doit prendre en charge le passage d’un message d’une longueur d’au moins 10 Mbytes.
Démarrage mesuré UEFI

Les exigences suivantes n’impliquent pas la nécessité d’une implémentation TPM TCG : Elles impliquent toutefois la nécessité de fonctionnalités équivalentes pour les zones affectées.

La prise en charge de la plateforme peut être assurée par une implémentation de microprogramme d’un module de plateforme sécurisée s’exécutant dans l’environnement d’exécution sécurisée, en superposant le moteur d’accélération de chiffrement et en tirant parti du stockage isolé. Microsoft peut être en mesure de fournir un logiciel de référence pour une telle implémentation TPM pour une utilisation par le fournisseur. Cette question fait l’objet d’autres discussions.

  • Condition requise 22 : OBLIGATOIRE. La plateforme doit être conforme au protocole EFI spécifié dans le protocole EFI de l’environnement d’exécution approuvé UEFI.

  • Condition requise 23 : OBLIGATOIRE. La plateforme doit adhérer à la spécification de la plateforme TCG EFI avec les ajouts suivants :

    • Sur les plateformes prenant en charge l’interface définie dans le protocole TrEE EFI, le digest de PKpub doit être étendu à TPM PCR[03] en tant qu’événement EV_EFI_VARIABLE_CONFIG.

    • La synthèse du contenu de la liste de la base de données de signatures autorisées (voir la section 27.8 de la spécification UEFI v2.3.1) doit être étendue dans le démarrage mesuré en tant qu’événement EV_EFI_VARIABLE_CONFIG. L’opération d’extension doit être effectuée au pcrp du module de plateforme sécurisée (TPM)[03].

    • Il doit être possible pour un client UEFI de lire et d’analyser la liste des certificats à l’aide de la variable EFI_IMAGE_SECURITY_DATABASE et de valider la synthèse par rapport à la valeur étendue.

    • TCG_PCR_EVENT valeurs de synthèse doivent être SHA-256, et non SHA-1.

  • Condition requise 24 : OBLIGATOIRE. La plateforme doit implémenter le MemoryOverwriteRequestControl défini dans la spécification d’atténuation des attaques de réinitialisation de la plateforme TCG.
Chiffrement

  • Condition requise 25 : OBLIGATOIRE. La plateforme doit fournir le EFI_HASH_PROTOCOL (UEFI v2.3.1, section 27.4) pour le déchargement des opérations de hachage de chiffrement. SHA-256 doit être pris en charge.

  • Condition requise 26 : OBLIGATOIRE. La plateforme doit prendre en charge les EFI_RNG_PROTOCOL définies par Microsoft pour la lecture de l’entropie avant le système d’exploitation.
Protection des données

  • Condition requise 27 : OBLIGATOIRE. La plateforme doit prendre en charge les variables EFI avec n’importe quelle combinaison des attributs de variable UEFI suivants :

    • EFI_VARIABLE_BOOTSERVICE_ACCESS

    • EFI_VARIABLE_NON_VOLATILE

    • EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS
Autres exigences de sécurité

Les exigences supplémentaires suivantes sont requises par Windows sur les plateformes SoC.

  • Microsoft a défini un protocole pour collecter l’entropie à partir d’une plateforme UEFI. Bien qu’il ne s’agit pas d’une exigence UEFI, ce protocole est requis par Windows sur les plateformes SoC. Pour plus d’informations sur ce protocole, consultez Protocole de collecte d’entropie UEFI.

  • Base de données de signature UEFI Mises à jour. Un nouveau mécanisme de mise à jour des variables authentifiées a été adopté dans la section 27 de UEFI 2.3.1. Ce mécanisme est requis par Windows.

  • Environnement d’exécution approuvé. Microsoft a développé un protocole EFI pour interagir avec un environnement d’exécution approuvé (TrEE), similaire en termes de fonctionnalités à un sous-ensemble d’un module de plateforme sécurisée (TPM) du groupe d’informatique approuvé (TCG). Le protocole EFI tire largement parti du « protocole TCG EFI », version 1.2, révision 1.00, 9 juin 2006, par le groupe d’informatique approuvé.

    Pour plus d’informations, consultez Protocole EFI de l’environnement d’exécution approuvé UEFI.

Configuration requise pour le gestionnaire de démarrage du microprogramme

Le gestionnaire de démarrage du microprogramme doit prendre en charge le comportement de démarrage par défaut défini dans la section 3.3 de la spécification. En outre, pour la prise en charge de plusieurs démarrages, des variables définies globalement et les exigences du gestionnaire de démarrage de la section 3.1 de la spécification sont requises.

Exigences de liaison UEFI Arm

La liaison UEFI Arm inclut des exigences spécifiques à la plateforme Arm nécessaire pour être conforme aux spécifications UEFI. Windows nécessite tout ce qui se trouve dans la liaison Arm applicable à ARMv7. Étant donné que Windows ne prend en charge aucun élément antérieur à ARMv7, les exigences de la liaison qui sont spécifiques à ARMv6k et ci-dessous sont facultatives.

La liaison spécifie, par exemple, comment la MMU doit être configurée et comment la mémoire physique doit être mappée. La liaison spécifie également que les appels effectués aux protocoles et services UEFI doivent être effectués uniquement dans l’ISA Arm, ce qui signifie que les logiciels exécutés dans Thumb2 ou Thumb doivent revenir en mode Arm avant d’appeler des fonctions UEFI.

Exigences de démarrage du multiprocesseur UEFI Arm

Microsoft a développé un protocole pour démarrer plusieurs cœurs Arm sur une plateforme UEFI multiprocesseur. Ce protocole est requis par Windows sur les plateformes Arm qui ne prennent pas en charge l’interface PSCI (Power State Coordination Interface). Les plateformes qui prennent en charge PSCI ne doivent pas utiliser ce protocole. Pour plus d’informations sur ce protocole, consultez le document démarrage multiprocesseur sur les plateformes UEFI Arm sur le site Web ACPI Component Architecture (ACPICA).

Configuration requise de la plateforme

Le microprogramme est chargé de placer le matériel système dans un état bien défini avant de le remettre au chargeur du système d’exploitation. Le tableau suivant définit les exigences de configuration de la plateforme associées.

Condition requise Description
Chemin de démarrage Le microprogramme doit initialiser la plateforme au point où Windows peut accéder au périphérique de démarrage via UEFI et charger le noyau. Tout appareil impliqué dans la hiérarchie à lire à partir du périphérique de démarrage doit être cadencé et alimenté à un débit raisonnable, compte tenu des considérations relatives aux performances et à la puissance. Le cœur du processeur de base lui-même doit également être cadencé et alimenté à un rythme raisonnable, afin que le système puisse démarrer en temps opportun sans vider la batterie.
Ressources système principales Les ressources système principales exposées au système d’exploitation via des tables ACPI doivent être mises sous tension et cadencées. Les ressources système principales incluent les contrôleurs d’interruption, les minuteurs et les contrôleurs DMA qui doivent être gérés par le système d’exploitation. En outre, les interruptions doivent être masquées par l’appel à ExitBootServices() jusqu’à ce que le pilote de périphérique associé dans le système d’exploitation démasque et réactive les interruptions sur l’appareil. Si les interruptions sont activées pendant les services de démarrage, il est supposé que le microprogramme les gère.
Débogage Windows prend en charge le débogage via l’hôte USB 3 (XHCI), l’hôte USB 2 (EHCI)1, IEEE 1394, les interfaces de fonction série et USB (ainsi que les adaptateurs Ethernet PCI). Au moins l’un d’entre eux doit être alimenté, cadencé et initialisé par le microprogramme avant la remise du système d’exploitation. Quelle que soit l’option fournie, elle doit disposer d’un port exposé à des fins de débogage, et le contrôleur doit être mappé en mémoire ou connecté via un bus périphérique dédié (non partagé).
Autres exigences de configuration de la plateforme Toute configuration de multiplexage de broches et de pavés doit être effectuée dans le microprogramme avant de remettre le contrôle au chargeur du système d’exploitation.

Configuration requise

Windows nécessite que la partition du système d’exploitation réside sur une solution de stockage partitionnée GPT. Le stockage partitionné MBR peut être utilisé comme stockage de données. Comme défini dans la spécification UEFI, une plateforme UEFI nécessite une partition système dédiée. Windows nécessite cette partition système dédiée, appelée partition système EFI (ESP).

Configuration requise pour l’interface de test de sécurité matérielle (HSTI)

La plateforme doit implémenter l’interface de test de sécurité matérielle, et la plateforme est requise pour partager la documentation et les outils comme spécifié dans la spécification de testabilité de sécurité matérielle.

Exigences UEFI minimales pour Windows sur les plateformes SoC

Exigences UEFI pour Windows 10 Mobile

Exigences UEFI pour la prise en charge du flash USB