Protocole EFI de l’environnement d’exécution approuvé
Licences : Microsoft s’engage à vous accorder une licence sans frais, libre de redevances pour ses Revendications nécessaires à des conditions raisonnables et non discriminatoires uniquement pour faire, utiliser, vendre, offrir à la vente, importer ou distribuer toute implémentation de cette spécification. Les « revendications nécessaires » sont les revendications de brevets appartenant à Microsoft ou contrôlés par Microsoft qui sont techniquement nécessaires pour mettre en œuvre les parties requises (qui incluent également les éléments requis de parties facultatives) de cette spécification, où la fonctionnalité à l’origine de la contrefaçon est décrite en détail et non simplement référencée dans cette spécification.
1.0 Introduction
Ce document spécifie un protocole EFI pour interagir avec un environnement d’exécution approuvé (TrEE), implémentant la fonctionnalité TPM 2.0 par un sous-ensemble d’une spécification de bibliothèque de plateforme approuvée tcG (Trusted Platform Module 2.0). Ce document spécifie également les exigences de mesure du microprogramme de plateforme. Le protocole EFI défini ici tire largement parti de [TCG06a] et [TCG06b].
2.0 Structures de données et acronymes
2.1 Structures de données
Comme dans [TCG06a], toutes les valeurs de données DOIVENT être représentées au format Little-Endian. Les chaînes DOIVENT être représentées sous la forme d’un tableau d’octets ASCII avec le caractère le plus à gauche placé à l’emplacement de mémoire le plus bas.
2.2 Acronymes et conventions
(Pour les acronymes non définis ici, consultez [TCG06a])
Environnement d’exécution TrEETrusted
L’utilisation des termes « MUST » et « SHALL » dans ce document doit être interprétée conformément à [RFC2119].
3.0 Protocole EFI TrEE
Cette section fournit une description détaillée des EFI_TREE_PROTOCOL et des EFI_TREE_SERVICE_BINDING_PROTOCOL. Le protocole TrEE EFI est utilisé pour communiquer avec un TrEE.
3.1 Protocole de liaison de service EFI TrEE
Cette section définit le protocole de liaison de service TrEE EFI.
Résumé : le protocole de liaison de service EFI TrEE est utilisé pour localiser les appareils TrEE pris en charge par un pilote de protocole EFI TrEE et pour créer et détruire des instances de pilote enfant du protocole EFI TrEE qui peuvent utiliser le périphérique TrEE sous-jacent.
GUID - #define EFI_TREE_SERVICE_BINDING_PROTOCOL_GUID \ {0x4cf01d0a, 0xc48c, 0x4271, 0xa2, 0x2a, 0xad, 0x8e, 0x55, 0x97,\ 0x81, 0x88}
DescriptionUne application (ou un pilote) qui nécessite des services TrEE peut utiliser l’un des services de gestionnaire de protocole, tels que BS-LocateHandleBuffer>(), pour rechercher des appareils qui publient un protocole de liaison de service TrEE EFI. Chaque appareil avec un protocole de liaison de service EFI TrEE publié prend en charge le protocole EFI TrEE et peut être disponible pour utilisation.
Après un appel réussi au EFI_TREE_SERVICE_BINDING_PROTOCOL. La fonction CreateChild(), le pilote de protocole EFI TrEE enfant instance est prêt à être utilisé.
Avant qu’une application ou un pilote EFI ne termine l’exécution, chaque appel réussi au EFI_TREE_SERVICE_BINDING_PROTOCOL. La fonction CreateChild() doit être associée à un appel à la EFI_TREE_SERVICE_BINDING_PROTOCOL. Fonction DestroyChild().
3.2 Protocole EFI TrEE
Résumé : le protocole EFI TrEE est utilisé pour communiquer avec un TrEE , pour envoyer des commandes à un TrEE, l’utiliser pour des opérations d’exécution approuvées et pour fournir un accès au journal de microprogramme des mesures étendues dans le TrEE. Le protocole gère un journal des événements des mesures enregistrées dans le TrEE avec un format identique au journal des événements TCG 1.2 TCG (voir [TCG06b]) ; appelé Journal des événements TrEE TCG 1.2 dans cette spécification. Les implémenteurs peuvent créer des journaux d’événements supplémentaires avec d’autres formats, mais cette version du protocole ne définit pas un moyen de les récupérer.
GUID - #define EFI_TREE_PROTOCOL_GUID \ {0x607f766c, 0x7455, 0x42be, 0x93, 0x0b, 0xe4, 0xd7, 0x6d, 0xb2,\ 0x72, 0x0f}
Structure de l’interface de protocole -
typedef struct _EFI_TREE_PROTOCOL {
EFI_TREE_GET_CAPABILITYGetCapability;
EFI_TREE_GET_EVENT_LOGGetEventLog;
EFI_TREE_HASH_LOG_EXTEND_EVENTHashLogExtendEvent;
EFI_TREE_SUBMIT_COMMANDSubmitCommand;
} EFI_TREE_PROTOCOL;
Paramètres
GetCapability |
Ce service fournit des informations sur les fonctionnalités TrEE et microprogramme |
GetEventLog |
Obtenir un pointeur vers un journal des événements du microprogramme |
HashLogExtendEvent |
Ce service entraîne l’extension d’un événement par le pilote TrEE EFI et (éventuellement) l’écriture de l’événement dans le journal TrEE. |
SubmitCommand |
Ce service envoie une commande directement au TrEE. |
Description : activité TrEE EFI_TREE_PROTOCOL abstraite. Ce protocole instance fournit un service de démarrage et est instancié en tant que pilote de service de démarrage.
Les pilotes de service de démarrage sont arrêtés lorsque ExitBootServices ( ) est appelé et que toutes les ressources de mémoire consommées par les pilotes Boot Services sont publiées pour être utilisées dans l’environnement du système d’exploitation.
Ce service de démarrage doit créer un événement EVT_SIGNAL_EXIT_BOOT_SERVICES. Cet événement est notifié par le système lorsque ExitBootServices ( ) est appelé.
EVT_SIGNAL_EXIT_BOOT_SERVICES est un événement synchrone utilisé pour s’assurer que certaines activités se produisent après un appel à une fonction d’interface spécifique ; dans ce cas, il s’agit du nettoyage qui doit être effectué en réponse à la fonction ExitBootServices ( ). ExitBootServices ( ) ne peut pas propre pour le compte des pilotes qui ont été chargés dans le système. Les pilotes doivent le faire eux-mêmes en créant un événement dont le type est EVT_SIGNAL_EXIT_BOOT_SERVICES et dont la fonction de notification est une fonction au sein du pilote lui-même. Ensuite, lorsque ExitBootServices ( ) a terminé son nettoyage, il signale le type d’événement EVT_SIGNAL_EXIT_BOOT_SERVICES.
Pour plus d’informations sur l’implémentation de la façon dont un service de démarrage instancié en tant que pilote EFI crée cet événement EVT_SIGNAL_EXIT_BOOT_SERVICES requis, consultez la section 6.1 de [UEFI12].
3.3 EFI_TREE_PROTOCOL. GetCapability
L’appel de fonction GetCapability EFI_TREE_PROTOCOL fournit des informations sur la fonctionnalité de protocole et des informations d’état sur le TrEE.
Prototype
typedef
EFI_STATUS
(EFIAPI *EFI_TREE_GET_CAPABILITY) (
IN EFI_TREE_PROTOCOL *This,
IN OUT TREE_BOOT_SERVICE_CAPABILITY*ProtocolCapability,
);
Paramètres
Ce |
Indique le contexte d’appel. |
ProtocolCapability |
L’appelant alloue de la mémoire pour une structure TREE_BOOT_SERVICE_CAPABILITY et définit le champ de taille sur la taille de la structure allouée. L’appelé remplit les champs avec les informations de capacité du protocole EFI et les informations d’état TrEE actuelles jusqu’au nombre de champs qui correspondent à la taille de la structure transmise. |
Définitions associées
typedef struct _TREE_VERSION {
UINT8 Major;
UINT8 Minor;
} TREE_VERSION;
typedef UINT64 EFI_PHYSICAL_ADDRESS;
typedef UINT32 TREE_EVENT_LOG_BITMAP;
typedef UINT32 TREE_EVENT_LOG_FORMAT;
#define TREE_EVENT_LOG_FORMAT_TCG_1_2 0x00000001
typedef struct _TREE_BOOT_SERVICE_CAPABILITY {
UINT8 Size;
TREE_VERSION StructureVersion;
TREE_VERSION ProtocolVersion;
UINT32 HashAlgorithmBitmap;
TREE_EVENT_LOG_BITMAPSupportedEventLogs;
BOOLEAN TrEEPresentFlag;
UINT16MaxCommandSize;
UINT16MaxResponseSize;
UINT32ManufacturerID;
} TREE_BOOT_SERVICE_CAPABILITY;
#define TREE_BOOT_HASH_ALG_SHA1 0x00000001
#define TREE_BOOT_HASH_ALG_SHA256 0x00000002
#define TREE_BOOT_HASH_ALG_SHA384 0x00000004
#define TREE_BOOT_HASH_ALG_SHA512 0x00000008
Taille |
Taille allouée de la structure transmise |
StructureVersion |
Version de la structure TREE_BOOT_SERVICE_CAPABILITY elle-même. Pour cette version du protocole, la version principale doit avoir la valeur 1 et la version mineure la valeur 0. |
ProtocolVersion |
Version du protocole TrEE. Pour cette version du protocole, la version principale doit avoir la valeur 1 et la version mineure la valeur 0. |
HashAlgorithmBitMap |
Algorithmes de hachage pris en charge |
SupportedEventLogs |
Bitmap des formats de journal des événements pris en charge (voir ci-dessus) |
TrEEPresentFlag |
False = TrEE non présent |
MaxCommandSize |
Taille maximale (en octets) d’une commande pouvant être envoyée au TrEE |
MaxResponseSize |
Taille maximale (en octets) d’une réponse qui peut être fournie par le TrEE |
ManufacturerID |
ID du fournisseur de 4 octets (voir [TCG07], section « ID du fournisseur des fonctionnalités TPM » |
Description
L’appel de fonction Get Capability EFI_TREE_PROTOCOL fournit des informations sur la version et la fonctionnalité du protocole EFI, ainsi que des informations d’état sur le TrEE. L’appelant doit définir le champ Taille de la structure TREE_BOOT_SERVICE_CAPABILITY allouée. Il est prévu que les versions ultérieures de cet appel de fonction puissent ajouter des champs supplémentaires à la structure. La valeur Size transmise permet à la fonction de remplir uniquement les champs pour 2000 dont l’appelant a alloué la mémoire. Par exemple :
ProtocolCapability.Size = sizeof(TREE_BOOT_SERVICE_CAPABILITY);
Pour cette version de la spécification :
Si les paramètres This ou ProtocolCapability ont la valeur NULL, l’appel fonctionnel retourne EFI_INVALID_PARAMETER.
Si l’entrée ProtocolCapability.Size < sizeof(TREE_BOOT_SERVICE_CAPABILITY), la fonction définit ProtocolCapability.Size égale à sizeof(TREE_BOOT_SERVICE_CAPABILITY) comme défini dans cette spécification et retourne le code d’erreur EFI_BUFFER_TOO_SMALL, les valeurs des champs restants ne sont pas définies.
Les valeurs de retour suivantes DOIVENT être définies :
ProtocolCapability.StructureVersion.Major = 1
ProtocolCapability.StructureVersion.Minor = 0
ProtocolCapability.ProtocolVersion.Major = 1
ProtocolCapability.ProtocolVersion.Minor = 0
Si la plateforme n’a pas de TrEE, les valeurs suivantes DOIVENT être retournées :
ProtocolCapability.SupportedEventLogs = 0
ProtocolCapability.HashAlgorithmBitmap = 0
ProtocolCapability.TrEEPresentFlag = FALSE
ProtocolCapability.MaxCommandSize = 0
ProtocolCapability.MaxResponseSize = 0
ProtocolCapability.ManufacturerID = 0
Les valeurs minimales MaxCommandSize et MaxResponseSize DOIVENT être 0x500 (ou supérieures) pour Windows.
Codes d’état retournés
EFI_SUCCESS |
Opération exécutée avec succès. |
EFI_DEVICE_ERROR |
La commande a échoué. La variable ProtocolCapability n’est pas renseignée. |
EFI_INVALID_PARAMETER |
Un ou plusieurs paramètres sont incorrects. La variable ProtocolCapability n’est pas renseignée. |
EFI_BUFFER_TOO_SMALL |
La variable ProtocolCapability est trop petite pour contenir la réponse complète. Il sera partiellement rempli (le champ Taille obligatoire sera défini). |
3.4 EFI_TREE_PROTOCOL. GetEventLog
L’appel de fonction EFI_TREE_PROTOCOL Obtenir le journal des événements permet à un appelant de récupérer l’adresse d’un journal des événements donné et sa dernière entrée.
Prototype
typedef
EFI_STATUS
(EFIAPI *EFI_TREE_GET_EVENT_LOG) (
IN EFI_TREE_PROTOCOL *This,
IN TREE_EVENT_LOG_FORMATEventLogFormat,
OUT EFI_PHYSICAL_ADDRESS*EventLogLocation,
OUT EFI_PHYSICAL_ADDRESS*EventLogLastEntry,
OUT BOOLEAN*EventLogTruncated
);
Paramètres
EventLogFormat |
Type du journal des événements pour lequel les informations sont demandées. |
EventLogLocation |
Pointeur vers l’adresse mémoire du journal des événements. |
EventLogLastEntry |
Si le journal des événements contient plusieurs entrées, il s’agit d’un pointeur vers l’adresse du début de la dernière entrée dans le journal des événements en mémoire. Pour plus d’informations sur les valeurs retournées dans ce paramètre dans les cas spéciaux d’un journal des événements vide ou d’un journal des événements avec une seule entrée, consultez la section Description ci-dessous. |
EventLogTruncated |
Si le journal des événements manque au moins une entrée, car un événement aurait dépassé la zone allouée aux événements, cette valeur est définie sur TRUE. Sinon, la valeur est FALSE et le journal des événements est terminé. |
Description
Le microprogramme gère un journal des événements des mesures enregistrées dans le TrEE pendant le processus de démarrage. Pendant le processus de démarrage, avant l’initialisation de la plateforme UEFI, une entrée est effectuée dans le journal des événements pour chaque mesure étendue dans le TrEE. Dans l’environnement UEFI, chaque fois qu’un appel est effectué à HashLogExtendEvent pour étendre une mesure dans le TrEE, un événement est généralement enregistré dans le journal des événements contenant la mesure étendue. Si la zone allouée par le microprogramme pour le journal des événements était trop petite pour contenir tous les événements ajoutés, l’appel de fonction indique que le journal des événements a été tronqué et a des entrées manquantes. Cette version de la spécification nécessite uniquement la maintenance d’un journal des événements des mesures SHA1. Les versions futures de cette spécification peuvent conserver des journaux d’événements supplémentaires prenant en charge différents algorithmes de hachage.
La zone Journal des événements retournée par cette fonction est libérée lorsque ExitBootServices ( ) est appelé. Les appelants de cette méthode NE DOIVENT pas accéder à la zone après l’appel de ExitBootServices ( ). Pour cette version de la spécification :
Si EventLogFormat n’est pas égal à TREE_EVENT_LOG_FORMAT_TCG_1_2, l’appel de fonction DOIT retourner EFI_INVALID_PARAMETER.
Si aucun TrEE n’est présent, la fonction DOIT définir les valeurs suivantes et retourner EFI_SUCCESS :
EventLogLocation = NULL
EventLogLastEntry = NULL
EventLogTruncated = FALSE
La valeur EventLogLocation DOIT être définie sur le début du format de journal des événements spécifié en mémoire
Si le journal des événements spécifié :
ne contient aucun événement alors EventLogLastEntry DOIT être défini sur 0
contient exactement une entrée, puis EventLogLastEntry DOIT être défini sur la même valeur que EventLogLocation
contient plusieurs événements, puis EventLogLastEntry DOIT être défini sur l’adresse de début du dernier événement du journal des événements spécifié
Si un appel antérieur à EFI_TREE_PROTOCOL. HashLogExtendEvent a retourné EFI_VOLUME_FULL puis EventLogTruncated DOIT être défini sur TRUE, sinon il DOIT être défini sur FALSE.
Codes d’état retournés
EFI_SUCCESS |
Opération exécutée avec succès. |
EFI_INVALID_PARAMETER |
Un ou plusieurs paramètres sont incorrects (par exemple, demander un journal des événements dont le format n’est pas pris en charge). |
3,5 EFI_TREE_PROTOCOL. HashLogExtendEvent
L’appel de fonction EFI_TREE_PROTOCOL HashLogExtendEvent permet aux appelants d’étendre et éventuellement de journaliser des événements sans avoir besoin de connaître les commandes TPM réelles. L’opération d’extension se produit même si cette fonction ne peut pas créer d’entrée de journal des événements (par exemple, en raison du fait que le journal des événements est saturé).
Prototype
typedef
EFI_STATUS
(EFIAPI * EFI_TREE_HASH_LOG_EXTEND_EVENT) (
IN EFI_TREE_PROTOCOL*This,
IN UINT64Flags,
IN EFI_PHYSICAL_ADDRESSDataToHash,
IN UINT64DataToHashLen,
IN TrEE_EVENT*Event,
);
Paramètres
Ce |
Indique le contexte d’appel. |
Indicateurs |
Bitmap fournissant des informations supplémentaires (voir ci-dessous). |
DataToHash |
Adresse physique du début de la mémoire tampon de données à |
Haché. |
|
DataToHashLen |
Longueur en octets de la mémoire tampon référencée par DataToHash. |
Event |
Pointeur vers la mémoire tampon de données contenant des informations sur l’événement. |
Définitions associées
#pragma pack(1)
typedef struct _TrEE_EVENT {
UINT32Size;
TrEE_EVENT_HEADERHeader;
UINT8Event[ANYSIZE_ARRAY];
} TrEE_EVENT;
typedef struct _TrEE_EVENT_HEADER {
UINT32HeaderSize;
UINT16HeaderVersion;
TrEE_PCRINDEXPCRIndex;
TrEE_EVENTTYPEEventType;
} TrEE_EVENT_HEADER;
#pragma pack()
typedef UINT32 TrEE_PCRINDEX;
typedef UINT32 TrEE_EVENTTYPE;
Taille |
Taille totale de l’événement, y compris le composant Size, l’en-tête et les données de l’événement . |
HeaderSize |
Taille de l’en-tête d’événement lui-même (sizeof(TrEE_EVENT_HEADER)). |
HeaderVersion |
Version de l’en-tête. Pour cette version de cette spécification, la valeur doit être 1. |
PCRIndex |
Index de la PCR qui doit être étendue (0 - 23). |
EventType |
Type de l’événement qui doit être étendu (et éventuellement journalisé). |
Valeurs d’indicateur
La variable Flags est une bitmap qui fournit des données supplémentaires comme suit :
#define TREE_EXTEND_ONLY 0x0000000000000001
Ce bit doit être défini lorsqu’un événement doit être étendu mais non journalisé.
#define PE_COFF_IMAGE 0x0000000000000010
Ce bit doit être défini lorsque l’intention est de mesurer une image PE/COFF.
Description
L’appel de fonction EFI_TREE_PROTOCOL Hash Log Extend Event calcule la mesure d’une mémoire tampon de données (éventuellement contenant une image binaire PE/COFF) et provoque l’extension de la mesure par le pilote TrEE. En outre, le service crée éventuellement une entrée de journal des événements et l’ajoute au journal des événements pour chaque format de journal des événements pris en charge par le service. Le service permet à un appelant d’utiliser le TrEE sans rien savoir sur des commandes TrEE spécifiques.
L’utilisation de cette fonction pour mesurer les images PE/COFF doit être effectuée avant que des délocalisations aient été appliquées à l’image. Remarque : Utilisez cette méthode pour mesurer les images PE/COFF. En général, les implémentations qui chargent des images PE/COFF suppriment les données importantes pendant le processus de chargement de l’image et peuvent modifier l’alignement de la section d’image en mémoire. Le résultat net consiste à calculer le hachage d’une image en mémoire ne correspond pas à la mesure réelle de l’image, comme elle a été correctement calculée lorsqu’elle est chargée à partir du support de stockage.
Lors de l’appel, la fonction doit effectuer les actions suivantes :
Si l’un des paramètres This, DataToHash ou Event est NULL, la fonction DOIT retourner EFI_INVALID_PARAMETER.
Si Event.Size est inférieur à Event.Header.HeaderSize + sizeof(UINT32), la fonction DOIT retourner EFI_INVALID_PARAMETER.
Si Event.Header.PCRIndex n’est pas compris entre 0 et 23, inclus, la fonction DOIT retourner EFI_INVALID_PARAMETER.
Si la bitmap Flags a le PE_COFF_IMAGE bit SET, mais que l’image PE/COFF est endommagée ou non comprise, la fonction DOIT retourner EFI_UNSUPPORTED.
La fonction autorise n’importe quelle valeur pour le paramètre Event.Header.EventType.
La fonction DOIT calculer la synthèse (mesure) des données à partir de DataToHash avec une longueur de DataToHashLen. Lorsque le bit PE_COFF_IMAGE est défini, la fonction DOIT calculer la mesure de l’image PE/COFF conformément à la section « Mesure d’une image PE/COFF » dans l’Annexe A ci-dessous.
La fonction DOIT envoyer correctement la commande TPM2_PCR_Extend au TrEE pour étendre la pcr indiquée par Event.Header.PCRIndex avec le condensé de mesure. Si la commande ne peut pas être envoyée correctement, la fonction doit retourner EFI_DEVICE_ERROR. Si le microprogramme prend en charge plus d’algorithmes que SHA1, il peut calculer les synthèses à l’aide d’autres algorithmes et les étendre également.
Si un appel précédent à cette fonction a retourné EFI_VOLUME_FULL et que le bit TREE_EXTEND_ONLY est défini dans le paramètre Flags, la fonction DOIT retourner EFI_VOLUME_FULL. (Aucune tentative n’est effectuée pour ajouter l’entrée du journal des événements aux journaux des événements).)
La fonction DOIT générer une entrée de journal des événements TCG comme suit : (Remarque : La structure TCG_PCR_EVENT est définie dans [TCG06b] et doit être considérée comme alignée sur les octets.)
TCG_PCR_EVENT. PCRIndex = Event.Header.PCRIndex
TCG_PCR_EVENT. EventType = Event.Header.EventType
TCG_PCR_EVENT. Digest = <synthèse de mesure SHA1 calculée ci-dessus>
TCG_PCR_EVENT. EventSize = Event.Size - sizeof(UINT32) - Event.Header.HeaderSize
TCG_PCR_EVENT. Event = Event.Event (Remarque : il s’agit d’une copie mémoire d’octets EventSize)
La fonction PEUT générer des entrées de journal des événements similaires pour d’autres formats de journal des événements pris en charge.
Si l’entrée TCG_PCR_EVENT journal des événements créée ci-dessus ne correspond pas à la zone allouée pour le journal des événements TCG 1.2 TrEE, la fonction DOIT retourner EFI_VOLUME_FULL.
Si le microprogramme prend en charge des formats de journal des événements supplémentaires et que l’un des événements créés pour ces journaux d’événements dépasse la zone allouée au journal des événements, la fonction DOIT retourner EFI_VOLUME_FULL.
La fonction DOIT ajouter les événements créés à leurs journaux d’événements correspondants et le service DOIT mettre à jour son pointeur interne vers le début du dernier événement pour chaque journal des événements.
Codes d’état retournés.
|
EFI_SUCCESS |
Opération exécutée avec succès. |
EFI_DEVICE_ERROR |
La commande a échoué. |
EFI_VOLUME_FULL |
L’opération d’extension s’est produite, mais l’événement n’a pas pu être écrit dans un ou plusieurs journaux d’événements. |
EFI_INVALID_PARAMETER |
Un ou plusieurs paramètres sont incorrects. |
EFI_UNSUPPORTED |
Le type d’image PE/COFF n’est pas pris en charge. |
3,6 EFI_TREE_PROTOCOL. SubmitCommand
Ce service permet l’envoi de commandes au TrEE.
Prototype
typedef
EFI_STATUS
(EFIAPI *EFI_TREE_SUBMIT_COMMAND) (
IN EFI_TREE_PROTOCOL*This,
IN UINT32InputParameterBlockSize,
IN UINT8*InputParameterBlock,
IN UINT32OutputParameterBlockSize,
IN UINT8*OutputParameterBlock
);
Paramètres
|
Ce |
Indique le contexte d’appel. |
InputParameterBlockSize |
Taille du bloc de paramètres d’entrée TrEE. |
InputParameterBlock |
Pointeur vers le bloc de paramètres d’entrée TrEE. |
OutputParameterBlockSize |
Taille du bloc de paramètres de sortie TrEE. |
OutputParameterBlock |
Pointeur vers le bloc de paramètres de sortie TrEE. |
Description
L’appel de fonction EFI_TREE_PROTOCOL Submit Command fournit une fonctionnalité directe de l’appelant au TrEE du système.
L’appelant est responsable de la génération du flux d’octets de commande à envoyer au TrEE et il est également responsable de l’interprétation du flux d’octets résultant retourné par le TrEE. Les opérandes TrEE entrants et sortants pour chaque commande TrEE sont définis ailleurs.
Notez que les codes de status retournés reflètent le résultat de l’appel de la fonction et non la réussite (ou l’échec) de la commande TrEE sous-jacente.
Le module de plateforme sécurisée 2.0 ne DOIT pas retourner TPM2_RC_RETRY avant la fin de l’appel à ExitBootServices(). (La raison de cette exigence est que le code de retour bloquerait le processus de démarrage jusqu’à ce que la commande TPM puisse être supprimée.)
Le module TPM 2.0 DOIT avoir accès à son stockage persistant avant la fin de l’appel à ExitBootServices. Si l’implémentation de TPM 2.0 n’a peut-être pas accès au stockage persistant après l’appel à ExitBootServices, contactez Microsoft pour obtenir des exigences supplémentaires.
Codes d’état retournés
EFI_SUCCESS |
Le flux d’octets de commande a été correctement envoyé à l’appareil et une réponse a été reçue avec succès. |
EFI_DEVICE_ERROR |
La commande n’a pas été correctement envoyée à l’appareil ou une réponse n’a pas été reçue de l’appareil. |
EFI_INVALID_PARAMETER |
Un ou plusieurs paramètres sont incorrects. |
EFI_BUFFER_TOO_SMALL |
Le bloc de paramètres de sortie est trop petit. |
Références
[MSFT08] |
Microsoft Corporation, « Format de signature exécutable portable Windows Authenticode », version 1.0, 21 mars 2008. |
[RFC2119] |
Bradner, S., « Keywords for Use in RFC to Indicate Requirement Levels », IETF RFC 2119, mars 1997. |
[TCG06a] |
Trusted Computing Group, « TCG EFI Protocol », version 1.20 Révision 1.00, 9 juin 2006. |
[TCG06b] |
Trusted Computing Group, « TCG EFI Platform Specification », version 1.20 Revision 1.0, 7 juin 2006. |
[TCG07] |
Trusted Computing Group, « TCG Vendor ID Registry », version 1.0, révision 0.1, 31 août 2007. |
[UEFI12] |
UEFI, « Unified Extensible Firmware Interface Specification », version 2.3.1 Errata C, |
Juin 2012. |
Annexe A : Racine statique des mesures de confiance
Important
Annexe Une implémentation des mesures PCR[7] est obligatoire pour les systèmes InstantGo.
À un niveau élevé, le microprogramme est chargé de mesurer les composants suivants lors du démarrage :
Microprogramme de plateforme qui contient ou mesure les services de démarrage UEFI et les services d’exécution UEFI
Variables pertinentes pour la sécurité associées au microprogramme de la plateforme
Pilotes UEFI ou applications de démarrage chargés séparément
Variables associées aux pilotes UEFI chargés séparément ou aux applications de démarrage UEFI
Les mesures ci-dessus sont définies par les sections 5.1 à 5.5 de la spécification de la plateforme TCG EFI [TCG06b] et ne sont pas mentionnées plus loin dans le présent document. Les mesures dans PCR[1] et PCR[3] sont facultatives en fonction de la configuration de la plateforme.
Pour Windows, PCR[7] est utilisé pour refléter la stratégie de démarrage sécurisé UEFI 2.3.1. Cette stratégie s’appuie sur le microprogramme qui authentifie tous les composants de démarrage lancés avant l’environnement UEFI et le code d’initialisation de la plateforme UEFI (ou le code de microprogramme antérieur) qui enregistre de manière invariante les informations de stratégie de démarrage sécurisé dans le PCR[7].
Le microprogramme de plateforme adhérant à la stratégie doit donc mesurer les valeurs suivantes dans PCR[7] :
Contenu de la variable PK
Contenu de la variable KEK
Contenu de la variable EFI_IMAGE_SECURITY_DATABASE
Contenu de la variable EFI_IMAGE_SECURITY_DATABASE1
Entrées dans le EFI_IMAGE_SECURITY_DATABASE utilisées pour valider les pilotes EFI ou les applications de démarrage EFI dans le chemin de démarrage
Contenu de la variable SecureBoot
En raison de ce qui précède, les variables UEFI PK, KEK, EFI_IMAGE_SECURITY_DATABASE, EFI_IMAGE_SECURITY_DATABASE1 et SecureBoot NE DOIVENT PAS être mesurées en PCR[3].
En outre, si la plateforme fournit un débogueur de microprogramme qui peut être lancé avant l’environnement UEFI, elle DOIT enregistrer ce fait dans PCR[7]. De même, si la plateforme fournit un débogueur pour l’environnement UEFI, le lancement du débogueur DOIT être enregistré en PCR[7].
Note d’implémentation
La fonction UEFI LoadImage DOIT enregistrer les mesures en PCR[2] ou PCR[4] par événements décrits dans [TCG06b] et également en PCR[7] par événement décrit dans la section « Mesure de la configuration UEFI en PCR[7] » ci-dessous. Pour déterminer si une mesure d’image s’applique à PCR[2] ou PCR[4], LoadImage DOIT examiner le champ Sous-système dans l’image PE/COFF. Les valeurs IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER, IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER et IMAGE_SUBSYSTEM_EFI_ROM correspondent à PCR[2]. La valeur IMAGE_SUBSYSTEM_EFI_APPLICATION correspond à PCR[4]. Si l’image chargée est d’un autre type, elle DOIT être enregistrée en PCR[4]. Les images que LoadImage ne parvient pas à charger en raison (a) d’un échec de vérification de la signature ou (b) parce que l’image n’est pas conforme à la stratégie de démarrage sécurisé UEFI 2.3.1 actuellement appliquée n’ont pas besoin d’être mesurées dans un PCR.
Définitions associées
#define EV_EFI_VARIABLE_DRIVER_CONFIG \
0x80000001 /* Defined in [TCG06b] */
#define EV_EFI_ACTION 0x80000007 /* Defined in [TCG06b] */
#define EV_EFI_VARIABLE_AUTHORITY 0x800000E0
This specification requires a modified TCG structure definition for EFI_VARIABLE_DATA. The revised structure is:
typedef struct {
EFI_GUIDVariableName;
UINT64 UnicodeNameLength; // The TCG Defintion used UINTN
UINT64 VariableDataLength; // The TCG Defintion used UINTN
CHAR16 UnicodeName[1];
INT8 VariableData[1];
} EFI_VARIABLE_DATA;
Mesure d’une image PE/COFF
Lors de la mesure d’une image PE/COFF, l’EventType doit être défini dans [TCG06b] (par exemple, lors de la mesure d’une application de démarrage EFI, l’EventType doit être EV_EFI_BOOT_SERVICES_APPLICATION) et la valeur Event doit être la valeur de la structure EFI_IMAGE_LOAD_EVENT définie dans [TCG06b].
Le service HashLogExtendEvent DOIT hacher l’image PE/COFF conformément à la procédure spécifiée dans la section « Calcul du hachage d’image PE » de [MSFT08].
Mesure de la configuration UEFI en PCR[7]
Pour tous les événements de valeur de variable EFI, EventType doit être EV_EFI_VARIABLE_DRIVER_CONFIG défini ci-dessus et la valeur Event doit être la valeur de la structure EFI_VARIABLE_DATA définie ci-dessus dans cette spécification (cette structure doit être considérée comme alignée sur les octets). La synthèse de mesure doit être le hachage SHA-1 des données d’événement, qui est la structure EFI_VARIABLE_DATA. (Remarque : Il s’agit d’une synthèse différente de celle spécifiée par [TCG06b].) The EFI_VARIABLE_DATA. La valeur UnicodeNameLength est le nombre de caractères CHAR16 (et non le nombre d’octets). The EFI_VARIABLE_DATA. Le contenu UnicodeName NE DOIT PAS inclure de terminateur Null. Si la lecture de la variable EFI retourne EFI_NOT_FOUND, le EFI_VARIABLE_DATA. Le champ VariableDataLength DOIT être défini sur zéro et EFI_VARIABLE_DATA. Le champ VariableData aura une taille de zéro.
Si la plateforme fournit un mode débogueur de microprogramme qui peut être utilisé avant l’environnement UEFI ou si la plateforme fournit un débogueur pour l’environnement UEFI, la plateforme étend un événement de EV_EFI_ACTION comme spécifié dans [TCG06b] en PCR[7] avant d’autoriser l’utilisation du débogueur. La chaîne d’événement doit être « Mode de débogage UEFI ». En outre, la plateforme DOIT créer une entrée de journal des événements TCG comme suit :
TCG_PCR_EVENT. PCRIndex = 7
TCG_PCR_EVENT. EventType = EV_EFI_ACTION
TCG_PCR_EVENT. Digest = <synthèse SHA-1 de la valeur de chaîne « Mode de débogage UEFI » sans le caractère NULL de fin>
TCG_PCR_EVENT. EventSize = strlen(« UEFI Debug Mode »)
TCG_PCR_EVENT. Event = « UEFI Debug Mode »
La plateforme PEUT générer des entrées de journal des événements similaires pour d’autres formats de journal des événements pris en charge.
Avant d’exécuter un code non authentifié par chiffrement comme étant fourni par le fabricant de la plateforme, le microprogramme du fabricant de la plateforme DOIT mesurer les valeurs suivantes dans l’ordre indiqué à l’aide du type d’événement EV_EFI_VARIABLE_DRIVER_CONFIG à PCR[7] :
Valeur de la variable SecureBoot
Valeur de variable PK
Valeur de la variable KEK
Valeur de variable EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE
Valeur de variable EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE1
Si la plateforme prend en charge la modification de l’une des variables de stratégie UEFI suivantes une fois qu’elles ont été mesurées initialement en PCR[7] et avant que ExitBootServices ( ) ne soit terminé sans redémarrer la plateforme de manière inconditionnelle, elle DOIT mesurer à nouveau la variable immédiatement après modification. En outre, le processus de mise à jour normal pour définir l’une des variables UEFI ci-dessous DOIT se produire avant la mesure initiale dans PCR[7] ou une fois l’appel à ExitBootServices() terminé.
Valeur de la variable SecureBoot
Valeur de variable PK
Valeur de la variable KEK
Valeur de variable EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE
Valeur de variable EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE1
Le système DOIT mesurer l’événement EV_SEPARATOR en PCR[7]. (Cela se produit en même temps que le séparateur est mesuré en PCR[0] à PCR[7].)
Avant de lancer un pilote EFI ou une application de démarrage EFI (et que le lancement soit dû au fait que le gestionnaire de démarrage EFI sélectionne une image à partir des variables UEFI DriverOrder ou BootOrder ou une image déjà lancée appelant la fonction UEFI LoadImage(), le microprogramme UEFI doit mesurer l’entrée dans la variable EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE qui a été utilisée pour valider l’image EFI dans pcr[7]. La mesure doit se produire conjointement avec la charge de l’image. Pour cet événement, l’EventType doit être EV_EFI_VARIABLE_AUTHORITY et la valeur Event doit être la valeur de la structure EFI_VARIABLE_DATA (la structure est définie ci-dessus dans cette spécification avec une définition différente de la spécification TCG). The EFI_VARIABLE_DATA. La valeur VariableData doit être la valeur EFI_SIGNATURE_DATA de l’EFI_SIGNATURE_LIST qui contenait l’autorité utilisée pour valider l’image et l’EFI_VARIABLE_DATA. VariableName doit être défini sur EFI_IMAGE_SECURITY_DATABASE_GUID. The EFI_VARIABLE_DATA. UnicodeName doit être défini sur la valeur de EFI_IMAGE_SECURITY_DATABASE. La valeur ne doit pas inclure le caractère NULL de fin.
Avant de lancer des pilotes EFI ou des applications de démarrage EFI supplémentaires, le microprogramme UEFI doit case activée si l’entrée dans la variable EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE qui valide l’image EFI a déjà été mesurée avec le type d’événement EV_EFI_VARIABLE_AUTHORITY dans PCR[7]. Si ce n’est pas le cas, il DOIT être mesuré comme décrit à l’étape précédente. Si elle a été mesurée précédemment, elle NE DOIT PAS être mesurée à nouveau.
Notes
Un exemple de mesure pour les mesures PCR[7] est disponible sur demande de Microsoft.