Protocollo EFI dell'ambiente di esecuzione attendibile

Licenze: Microsoft accetta di concedere all'utente una licenza gratuita senza alcun addebito alle sue richieste necessarie in termini ragionevoli e non discriminatori esclusivamente per effettuare, usare, vendere, offrire in vendita, importare o distribuire qualsiasi implementazione di questa specifica. "Richieste necessarie" sono quelle richieste di brevetti di proprietà di Microsoft o controllati da Microsoft che sono tecnicamente necessari per implementare le parti richieste (che includono anche gli elementi obbligatori di parti facoltative) di questa specifica, in cui la funzionalità che causa la violazione viene descritta in dettaglio e non solo a cui si fa riferimento in questa specifica.

1.0 Introduzione

Questo documento specifica un protocollo EFI per l'interazione con un ambiente di esecuzione attendibile (TrEE), che implementa la funzionalità TPM 2.0 per ogni subset di una specifica TCG (Trusted Computing Group) Trusted Platform Module 2.0. Questo documento specifica anche i requisiti di misurazione del firmware della piattaforma. Il protocollo EFI definito nel presente documento sfrutta in larga misura [TCG06a] e [TCG06b].

2.0 Strutture dati e acronimi

2.1 Strutture dei dati

Come in [TCG06a], tutti i valori di dati devono essere rappresentati in formato Little-Endian. Le stringhe devono essere rappresentate come matrice di byte ASCII con il carattere più a sinistra posizionato nella posizione di memoria più bassa.

2.2 Acronimi e convenzioni

(Per gli acronimi non definiti nel presente documento, vedere [TCG06a])

Ambiente di esecuzione TrEETrusted

L'utilizzo dei termini "MUST" e "SHALL" in questo documento deve essere interpretato in conformità con [RFC2119].

Protocollo EFI TrEE 3.0

In questa sezione viene fornita una descrizione dettagliata delle EFI_TREE_PROTOCOL e delle EFI_TREE_SERVICE_BINDING_PROTOCOL. Il protocollo EFI TrEE viene usato per comunicare con un TrEE.

3.1 TrEE EFI Service Binding Protocol

Questa sezione definisce il protocollo di associazione del servizio TrEE EFI.

Riepilogo : il protocollo di associazione del servizio EFI TrEE viene usato per individuare i dispositivi TrEE supportati da un driver del protocollo EFI TrEE e per creare ed eliminare le istanze del driver figlio del protocollo EFI TrEE che possono usare il dispositivo TrEE sottostante.

GUID - #define EFI_TREE_SERVICE_BINDING_PROTOCOL_GUID \ {0x4cf01d0a, 0xc48c, 0x4271, 0xa2, 0x2a, 0xad, 0x8e, 0x55, 0x97,\ 0x81, 0x88}

DescrizioneUn'applicazione (o un driver) che richiede servizi TrEE può usare uno dei servizi del gestore di protocollo, ad esempio BS-LocateHandleBuffer>(), per cercare i dispositivi che pubblicano un protocollo di associazione del servizio TrEE EFI. Ogni dispositivo con un protocollo EFI TrEE Service Binding Protocol supporta il protocollo EFI TrEE e può essere disponibile per l'uso.

Dopo una chiamata al EFI_TREE_SERVICE_BINDING_PROTOCOL. Funzione CreateChild(), l'istanza figlio del driver EFI TrEE Protocol è pronta per l'uso.

Prima che un'applicazione o un driver EFI termini l'esecuzione, ogni chiamata riuscita al EFI_TREE_SERVICE_BINDING_PROTOCOL. La funzione CreateChild() deve essere associata a una chiamata al EFI_TREE_SERVICE_BINDING_PROTOCOL. Funzione DestroyChild().

3.2 Protocollo TrEE EFI

Riepilogo - Il protocollo EFI TrEE viene usato per comunicare con un TrEE - per inviare comandi a un TrEE, usarlo per le operazioni di esecuzione attendibili e per fornire l'accesso al log del firmware delle misurazioni estese in TrEE. Il protocollo gestisce un registro eventi delle misurazioni registrate in TrEE con un formato identico al registro eventi TCG 1.2 (vedere [TCG06b]); indicato come Log eventi TrEE Event Log Format TCG 1.2 in questa specifica. Gli implementatori possono creare altri registri eventi con altri formati, ma questa versione del protocollo non definisce un modo per recuperarli.

GUID - #define EFI_TREE_PROTOCOL_GUID \ {0x607f766c, 0x7455, 0x42be, 0x93, 0x0b, 0xe4, 0xd7, 0x6d, 0xb2,\ 0x72, 0x0f}

Struttura dell'interfaccia del protocollo -

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;

Parameters

Descrizione : l'EFI_TREE_PROTOCOL astrae l'attività TrEE. Questa istanza di protocollo fornisce un servizio di avvio e viene creata un'istanza come driver del servizio di avvio.

I driver del servizio di avvio vengono terminati quando exitBootServices ( ) viene chiamato e tutte le risorse di memoria utilizzate dai driver dei servizi di avvio vengono rilasciate per l'uso nell'ambiente del sistema operativo.

Questo servizio di avvio deve creare un evento EVT_SIGNAL_EXIT_BOOT_SERVICES. Questo evento verrà informato dal sistema quando viene richiamato ExitBootServices ( ).

EVT_SIGNAL_EXIT_BOOT_SERVICES è un evento sincrono usato per garantire che determinate attività si verifichino dopo una chiamata a una funzione di interfaccia specifica; in questo caso, ovvero la pulizia che deve essere eseguita in risposta alla funzione ExitBootServices ( ). ExitBootServices ( ) non può eseguire la pulizia per conto dei driver caricati nel sistema. I driver devono farlo per se stessi creando un evento il cui tipo è EVT_SIGNAL_EXIT_BOOT_SERVICES e la cui funzione di notifica è una funzione all'interno del driver stesso. Quindi, quando ExitBootServices ( ) ha completato la pulizia, segnala il tipo di evento EVT_SIGNAL_EXIT_BOOT_SERVICES.

Per informazioni dettagliate sull'implementazione di un'istanza di un servizio di avvio come driver EFI crea questo evento EVT_SIGNAL_EXIT_BOOT_SERVICES necessario, vedere la sezione 6.1 di [UEFI12].

3.3 EFI_TREE_PROTOCOL. GetCapability

La chiamata di funzione EFI_TREE_PROTOCOL GetCapability fornisce informazioni sulle funzionalità del protocollo e informazioni sullo stato relative a TrEE.

Prototipo

typedef
EFI_STATUS
(EFIAPI *EFI_TREE_GET_CAPABILITY) (
  IN EFI_TREE_PROTOCOL      *This,
  IN OUT TREE_BOOT_SERVICE_CAPABILITY*ProtocolCapability,
);

Parametri

Definizioni correlate

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

Descrizione

La chiamata di funzione Get Capability EFI_TREE_PROTOCOL fornisce informazioni sulla versione e sulla funzionalità del protocollo EFI, nonché informazioni sullo stato relative a TrEE. Il chiamante deve impostare il campo Dimensioni della struttura TREE_BOOT_SERVICE_CAPABILITY allocata. È previsto che le versioni future di questa chiamata di funzione possano aggiungere altri campi alla struttura. Il valore Size passato in consentirà alla funzione di popolare solo i campi per cui il chiamante ha allocato la memoria. Ad esempio:

ProtocolCapability.Size = sizeof(TREE_BOOT_SERVICE_CAPABILITY);

Per questa versione della specifica:

1. Se i parametri This o ProtocolCapability sono NULL, la chiamata funzionale restituirà EFI_INVALID_PARAMETER.

2. Se l'input ProtocolCapability.Sizeof < (TREE_BOOT_SERVICE_CAPABILITY) la funzione imposterà ProtocolCapability.Size uguale a sizeof(TREE_BOOT_SERVICE_CAPABILITY) come definito in questa specifica e restituirà il codice di errore EFI_BUFFER_TOO_SMALL, i valori dei campi rimanenti non saranno definiti.

3. È necessario impostare i valori restituiti seguenti:

   ProtocolCapability.StructureVersion.Major = 1

   ProtocolCapability.StructureVersion.Minor = 0

   ProtocolCapability.ProtocolVersion.Major = 1

   ProtocolCapability.ProtocolVersion.Minor = 0

4. Se la piattaforma non ha un TrEE, devono essere restituiti i valori seguenti:

   ProtocolCapability.SupportedEventLogs = 0

   ProtocolCapability.HashAlgorithmBitmap = 0

   ProtocolCapability.TrEEPresentFlag = FALSE

   ProtocolCapability.MaxCommandSize = 0

   ProtocolCapability.MaxResponseSize = 0

   ProtocolCapability.ManufacturerID = 0

5. Il valore minimo di MaxCommandSize e MaxResponseSize deve essere 0x500 (o maggiore) per Windows.

Codici di stato restituiti

3.4 EFI_TREE_PROTOCOL. GetEventLog

La chiamata alla funzione Get Event Log EFI_TREE_PROTOCOL consente a un chiamante di recuperare l'indirizzo di un determinato registro eventi e l'ultima voce.

Prototipo

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
);

Parameters

Descrizione

Il firmware gestisce un registro eventi delle misurazioni registrate nel TrEE durante il processo di avvio. Durante il processo di avvio, prima dell'inizializzazione della piattaforma UEFI, viene effettuata una voce nel registro eventi per ogni misura estesa in TrEE. Nell'ambiente UEFI ogni volta che viene effettuata una chiamata a HashLogExtendEvent per estendere una misurazione nel TrEE, un evento viene in genere registrato nel registro eventi contenente la misurazione estesa. Se l'area allocata dal firmware per il registro eventi è troppo piccola per contenere tutti gli eventi aggiunti, la chiamata alla funzione indica che il registro eventi è stato troncato e ha voci mancanti. Questa versione della specifica richiede solo la manutenzione di un registro eventi delle misurazioni SHA1. Le versioni future di questa specifica possono mantenere registri eventi aggiuntivi che supportano algoritmi hash diversi.

L'area log eventi restituita da questa funzione viene rilasciata quando viene chiamato ExitBootServices ( ). I chiamanti di questo metodo non DEVONO accedere all'area dopo che ExitBootServices ( ) è stato chiamato. Per questa versione della specifica:

1. Se EventLogFormat non è uguale a TREE_EVENT_LOG_FORMAT_TCG_1_2, la chiamata alla funzione DEVE restituire EFI_INVALID_PARAMETER.

2. Se non è presente trEE, la funzione DEVE impostare i valori seguenti e restituire EFI_SUCCESS:

   1. EventLogLocation = NULL

   2. EventLogLastEntry = NULL

   3. EventLogTruncated = FALSE

3. Il valore EventLogLocation deve essere impostato sull'inizio del formato del registro eventi specificato in memoria

4. Se il registro eventi specificato:

   1. non contiene eventi e quindi EventLogLastEntry DEVE essere impostato su 0

   2. contiene esattamente una voce e quindi EventLogLastEntry DEVE essere impostata sullo stesso valore di EventLogLocation

   3. contiene più eventi e quindi EventLogLastEntry DEVE essere impostato sull'indirizzo iniziale dell'ultimo evento del registro eventi specificato

5. Se una chiamata precedente a EFI_TREE_PROTOCOL. HashLogExtendEvent restituito EFI_VOLUME_FULL quindi EventLogTruncated DEVE essere impostato su TRUE, altrimenti deve essere impostato su FALSE.

Codici di stato restituiti

3.5 EFI_TREE_PROTOCOL. HashLogExtendEvent

La chiamata di funzione hashLogExtendEvent EFI_TREE_PROTOCOL fornisce ai chiamanti l'opportunità di estendere e facoltativamente registrare gli eventi senza richiedere conoscenza dei comandi TPM effettivi. L'operazione di estensione si verificherà anche se questa funzione non può creare una voce del registro eventi (ad esempio a causa del log eventi pieno).

Prototipo

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,
);

Parameters

Definizioni correlate

#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;

Contrassegno valori

La variabile Flags è una bitmap che fornisce dati aggiuntivi come indicato di seguito:

#define TREE_EXTEND_ONLY 0x0000000000000001

Questo bit viene impostato quando un evento deve essere esteso ma non registrato.

#define PE_COFF_IMAGE 0x0000000000000010

Questo bit deve essere impostato quando la finalità consiste nella misura di un'immagine PE/COFF.

Descrizione

La chiamata EFI_TREE_PROTOCOL alla funzione evento Hash Log Extend Event calcola la misurazione di un buffer di dati (possibilmente contenente un'immagine binaria PE/COFF) e causa l'estensione della misurazione del driver TrEE. Inoltre, il servizio crea facoltativamente una voce del registro eventi e la aggiunge al registro eventi per ogni formato di log eventi supportato dal servizio. Il servizio consente a un chiamante di usare il TrEE senza sapere nulla sui comandi TrEE specifici.

L'uso di questa funzione per misurare le immagini PE/COFF deve essere eseguita prima che le rilocazione siano state applicate all'immagine. Nota: usare attenzione usando questo metodo per misurare le immagini PE/COFF. In genere le implementazioni che caricano immagini PE/COFF strisciano dati importanti durante il processo di caricamento dall'immagine e possono modificare l'allineamento della sezione dell'immagine in memoria. Il risultato netto calcola l'hash di un'immagine in memoria non corrisponde alla misura effettiva per l'immagine calcolata correttamente quando viene caricato dal supporto di archiviazione.

Al termine della chiamata, la funzione eseguirà le azioni seguenti:

1. Se uno dei parametri This, DataToHash o Event sono NULL, la funzione DEVE restituire EFI_INVALID_PARAMETER.

2. Se event.size è minore di Event.Header.HeaderSize + sizeof(UINT32), la funzione DEVE restituire EFI_INVALID_PARAMETER.

3. Se event.Header.PCRIndex non è compreso tra 0 e 23, inclusiva, la funzione DEVE restituire EFI_INVALID_PARAMETER.

4. Se la bitmap Flags ha il set di PE_COFF_IMAGE bit, ma l'immagine PE/COFF è danneggiata o non ha compreso che la funzione DEVE restituire EFI_UNSUPPORTED.

5. La funzione consente qualsiasi valore per il parametro Event.Header.EventType.

6. La funzione DEVE calcolare il digest (misurazione) dei dati a partire da DataToHash con una lunghezza di DataToHashLen. Quando viene impostato il bit di PE_COFF_IMAGE, la funzione DEVE calcolare la misura dell'immagine PE/COFF in base a "Misurazione di un'immagine PE/COFF" nell'appendice A seguente.

7. La funzione DEVE inviare correttamente il comando TPM2_PCR_Extend al TrEE per estendere il PCR indicato da Event.Header.PCRIndex con il digest di misurazione. Se il comando non può essere inviato correttamente, la funzione deve restituire EFI_DEVICE_ERROR. Se il firmware supporta più algoritmi rispetto a SHA1, può calcolare i digest usando altri algoritmi e estenderli anche.

8. Se una chiamata precedente a questa funzione ha restituito EFI_VOLUME_FULL e il bit di TREE_EXTEND_ONLY viene impostato nel parametro Flags, la funzione DEVE restituire EFI_VOLUME_FULL. Non viene eseguito alcun tentativo di aggiungere la voce del registro eventi al registro eventi.

9. La funzione DEVE compilare una voce del registro eventi TCG come indicato di seguito: (Nota: la struttura TCG_PCR_EVENT è definita in [TCG06b] e deve essere considerata allineata a byte.

   1. TCG_PCR_EVENT. PCRIndex = Event.Header.PCRIndex

   2. TCG_PCR_EVENT. EventType = Event.Header.EventType

   3. TCG_PCR_EVENT. Digest = <il digest di misurazione SHA1 calcolato in precedenza>

   4. TCG_PCR_EVENT. EventSize = Event.Size - sizeof(UINT32) - Event.Header.HeaderSize

   5. TCG_PCR_EVENT. Event = Event.Event (Nota: si tratta di una copia di memoria dei byte EventSize)

10. La funzione PUÒ compilare voci simili del registro eventi per altri formati di log eventi supportati.

11. Se la voce del registro eventi TCG_PCR_EVENT creata in precedenza non rientra nell'area allocata per il formato del registro eventi TrEE TCG 1.2, la funzione DEVE restituire EFI_VOLUME_FULL.

12. Se il firmware supporta formati aggiuntivi del registro eventi e uno degli eventi creati per tali log eventi supera l'area allocata per il registro eventi, la funzione DEVE restituire EFI_VOLUME_FULL.

13. La funzione DEVE aggiungere gli eventi creati ai log eventi corrispondenti e il servizio DEVE aggiornare il puntatore interno all'inizio dell'ultimo evento per ogni registro eventi.

Codici di stato restituiti.

3.6 EFI_TREE_PROTOCOL. SubmitCommand

Questo servizio consente l'invio di comandi a TrEE.

Prototipo

typedef
EFI_STATUS
(EFIAPI *EFI_TREE_SUBMIT_COMMAND) (
  IN EFI_TREE_PROTOCOL*This,
  IN UINT32InputParameterBlockSize,
  IN UINT8*InputParameterBlock,
  IN UINT32OutputParameterBlockSize,
  IN UINT8*OutputParameterBlock 
);

Parameters

Descrizione

La chiamata alla funzione Invia comando EFI_TREE_PROTOCOL fornisce una funzionalità pass-through dal chiamante al TrEE del sistema.

Il chiamante è responsabile della compilazione del flusso byte del comando da inviare al TrEE ed è responsabile anche dell'interpretazione del flusso byte risultante restituito dal TrEE. Gli operandi TrEE in e out per ogni comando TrEE sono definiti altrove.

Si noti che i codici di stato restituiti riflettono il risultato della chiamata alla funzione e non il successo (o l'errore) del comando TrEE sottostante.

Il TPM 2.0 non deve restituire TPM2_RC_RETRY prima del completamento della chiamata a ExitBootServices(). Il motivo di questo requisito è che il codice restituito blocca il processo di avvio fino a quando il comando TPM non può essere completato.

Il TPM 2.0 deve avere accesso alla relativa risorsa di archiviazione persistente prima del completamento della chiamata a ExitBootServices. Se l'implementazione di TPM 2.0 potrebbe non avere accesso all'archiviazione persistente dopo la chiamata a ExitBootServices, contattare Microsoft per ulteriori requisiti.

Codici di stato restituiti

Riferimenti

Appendice A: Radice statica delle misurazioni di attendibilità

A livello generale, il firmware è responsabile della misurazione dei componenti seguenti durante l'avvio:

• Firmware della piattaforma che contiene o misura i servizi di avvio UEFI e i servizi di runtime UEFI

• Variabili rilevanti per la sicurezza associate al firmware della piattaforma

• Driver UEFI o applicazioni di avvio caricate separatamente

• Variabili associate a driver UEFI caricati separatamente o applicazioni di avvio UEFI

Le misurazioni precedenti sono definite dalla specifica della piattaforma TCG EFI [TCG06b] sezioni 5.1 - 5.5 e non vengono indicate ulteriormente. Le misurazioni in PCR[1] e PCR[3] sono facoltative a seconda della configurazione della piattaforma.

Per Windows, PCR[7] viene usato per riflettere i criteri di avvio sicuro UEFI 2.3.1. Questo criterio si basa sul firmware che autentica tutti i componenti di avvio avviati prima dell'ambiente UEFI e il codice di inizializzazione della piattaforma UEFI (o codice firmware precedente) registrando invariantemente le informazioni sui criteri di avvio sicuro in PCR[7].

Il firmware della piattaforma che segue i criteri deve pertanto misurare i valori seguenti in PCR[7]:

1. Contenuto della variabile PK

2. Contenuto della variabile KEK

3. Contenuto della variabile EFI_IMAGE_SECURITY_DATABASE

4. Contenuto della variabile EFI_IMAGE_SECURITY_DATABASE1

5. Voci nella EFI_IMAGE_SECURITY_DATABASE usate per convalidare i driver EFI o le applicazioni di avvio EFI nel percorso di avvio

6. Contenuto della variabile SecureBoot

A causa delle variabili UEFI PK, KEK, EFI_IMAGE_SECURITY_DATABASE, EFI_IMAGE_SECURITY_DATABASE1 e SecureBoot NON devono essere misurate in PCR[3].

Inoltre, se la piattaforma fornisce un debugger del firmware che può essere avviato prima dell'ambiente UEFI, deve registrare questo fatto in PCR[7]. Analogamente, se la piattaforma fornisce un debugger per l'ambiente UEFI, l'avvio del debugger DEVE essere registrato in PCR[7].

Nota sull'implementazione

La funzione UEFI LoadImage deve registrare le misurazioni in PCR[2] o PCR[4] per eventi descritti in [TCG06b] e anche PCR[7] per eventi descritti nella sezione "Misurazione della configurazione UEFI in PCR[7]" di seguito. Per determinare se una misura dell'immagine si applica a PCR[2] o PCR[4], LoadImage DEVE esaminare il campo Sottosistema nell'immagine PE/COFF. I valori IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER, IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER e IMAGE_SUBSYSTEM_EFI_ROM corrispondono a PCR[2]. Il valore IMAGE_SUBSYSTEM_EFI_APPLICATION corrisponde a PCR[4]. Se l'immagine caricata è un altro tipo, deve essere registrata in PCR[4]. Le immagini che LoadImage non vengono caricate a causa di un errore di verifica della firma (a) o (b) perché l'immagine non è conforme ai criteri di avvio protetto UEFI 2.3.1 attualmente applicati non devono essere misurati in un PCR.

Definizioni correlate

#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;

Misurazione di un'immagine PE/COFF

Quando si misura un'immagine PE/COFF, EventType deve essere definito in [TCG06b] (ad esempio, quando si misura un'applicazione di avvio EFI, eventType deve essere EV_EFI_BOOT_SERVICES_APPLICATION) e il valore Event deve essere il valore della struttura EFI_IMAGE_LOAD_EVENT definita in [TCG06b].

Il servizio HashLogExtendEvent DEVE eseguire l'hash dell'immagine PE/COFF in base alla procedura specificata nella sezione "Calcolo dell'hash dell'immagine PE" di [MSFT08].

Misurazione della configurazione UEFI in PCR[7]

Per tutti gli eventi di valore della variabile EFI, EventType deve essere EV_EFI_VARIABLE_DRIVER_CONFIG definito in precedenza e il valore Event deve essere il valore della struttura EFI_VARIABLE_DATA definita in precedenza in questa specifica (questa struttura deve essere considerata allineata ai byte). Il digest di misurazione deve essere l'hash SHA-1 dei dati dell'evento, ovvero la struttura EFI_VARIABLE_DATA. Nota: si tratta di un digest diverso da quello specificato da [TCG06b].) The EFI_VARIABLE_DATA. Il valore UnicodeNameLength è il numero di caratteri CHAR16 (non il numero di byte). The EFI_VARIABLE_DATA. Il contenuto di UnicodeName NON DEVE includere un carattere di terminazione Null. Se la lettura della variabile EFI restituisce EFI_NOT_FOUND, il EFI_VARIABLE_DATA. Il campo VariableDataLength deve essere impostato su zero e EFI_VARIABLE_DATA. Il campo VariableData avrà una dimensione pari a zero.

1. Se la piattaforma fornisce una modalità del debugger del firmware che può essere usata prima dell'ambiente UEFI o se la piattaforma fornisce un debugger per l'ambiente UEFI, la piattaforma estenderà un evento EV_EFI_ACTION come specificato in [TCG06b] in PCR[7] prima di consentire l'uso del debugger. La stringa di evento deve essere "Modalità di debug UEFI". Inoltre, la piattaforma DEVE creare una voce del registro eventi TCG come indicato di seguito:

   1. TCG_PCR_EVENT. PCRIndex = 7

   2. TCG_PCR_EVENT. EventType = EV_EFI_ACTION

   3. TCG_PCR_EVENT. Digest = <digest SHA-1 del valore stringa "Modalità di debug UEFI" senza il carattere NULL di terminazione>

   4. TCG_PCR_EVENT. EventSize = strlen("modalità di debug UEFI")

   5. TCG_PCR_EVENT. Evento = "Modalità di debug UEFI"

   La piattaforma PUÒ compilare voci del registro eventi simili per altri formati di registro eventi supportati.

2. Prima di eseguire codice non autenticato in modo crittografico come fornito dal produttore della piattaforma, il firmware del produttore della piattaforma DEVE misurare i valori seguenti nell'ordine elencato usando il tipo di evento EV_EFI_VARIABLE_DRIVER_CONFIG a PCR[7]:

   1. Valore della variabile SecureBoot

   2. Valore della variabile PK

   3. Valore della variabile KEK

   4. Valore della variabile EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE

   5. Valore della variabile EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE1

3. Se la piattaforma supporta la modifica di una delle variabili dei criteri UEFI seguenti dopo che sono state misurate inizialmente in PCR[7] e prima che ExitBootServices ( ) sia stata completata senza riavviare in modo incondizionato la piattaforma, deve misurare nuovamente la variabile immediatamente dopo la modifica. Inoltre, il normale processo di aggiornamento per l'impostazione di una qualsiasi delle variabili UEFI seguenti DEVE verificarsi prima della misurazione iniziale in PCR[7] o dopo il completamento della chiamata a ExitBootServices().

   1. Valore della variabile SecureBoot

   2. Valore della variabile PK

   3. Valore della variabile KEK

   4. Valore della variabile EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE

   5. Valore della variabile EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE1

4. Il sistema deve misurare l'evento EV_SEPARATOR in PCR[7]. (Questo si verifica contemporaneamente il separatore viene misurato in PCR[0] tramite PCR[7].)

5. Prima di avviare un driver EFI o un'applicazione di avvio EFI (e indipendentemente dal fatto che l'avvio sia dovuto alla selezione di un'immagine dalle variabili DriverOrder o BootOrder UEFI o da un'immagine già avviata chiamando la funzione UEFI LoadImage(), il firmware UEFI deve misurare la voce nella variabile EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE usata per convalidare l'immagine EFI in PCR[7]. La misura deve essere eseguita insieme al carico dell'immagine. Per questo evento, EventType deve essere EV_EFI_VARIABLE_AUTHORITY e il valore Event deve essere il valore della struttura EFI_VARIABLE_DATA (la struttura è definita in precedenza in questa specifica con una definizione diversa rispetto alla specifica TCG). The EFI_VARIABLE_DATA. Il valore VariableData deve essere il valore EFI_SIGNATURE_DATA del EFI_SIGNATURE_LIST che conteneva l'autorità usata per convalidare l'immagine e il EFI_VARIABLE_DATA. VariableName deve essere impostato su EFI_IMAGE_SECURITY_DATABASE_GUID. The EFI_VARIABLE_DATA. UnicodeName deve essere impostato sul valore di EFI_IMAGE_SECURITY_DATABASE. Il valore non include il carattere NULL di terminazione.

6. Prima di avviare eventuali driver EFI aggiuntivi o applicazioni di avvio EFI, il firmware UEFI verifica se la voce nella variabile EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE che convalida l'immagine EFI è stata misurata in precedenza con il tipo di evento EV_EFI_VARIABLE_AUTHORITY in PCR[7]. In caso contrario, deve essere misurato come descritto nel passaggio precedente. Se è stata misurata in precedenza, NON DEVE essere misurata di nuovo.