Freigeben über


Vertrauenswürdige Ausführungsumgebung – EFI-Profil

Lizenzierung: Microsoft stimmt ihnen zu, dass Sie keine gebührenpflichtige, gebührenfreie Lizenz für ihre erforderlichen Ansprüche auf angemessene und nicht diskriminierende Bedingungen gewähren, ausschließlich für die Erstellung, Nutzung, Verkauf, Verkauf, Import oder Verteilung einer Implementierung dieser Spezifikation. „Notwendige Ansprüche“ sind die Ansprüche von Microsoft-eigenen oder von Microsoft kontrollierten Patenten, die technisch notwendig sind, um die erforderlichen Teile (die auch die erforderlichen Elemente optionaler Teile enthalten) dieser Spezifikation zu implementieren, wobei die Funktionalität, die die Verletzung verursacht, detailliert beschrieben wird und in dieser Spezifikation nicht nur referenziert.

1.0 Einführung

Dieses Dokument gibt ein EFI-Protokoll für die Interaktion mit einer vertrauenswürdigen Ausführungsumgebung (TrEE) an, die TPM 2.0-Funktionalität pro Teilmenge einer Trusted Computing Group (TCG) Trusted Platform Module 2.0 Library-Spezifikation implementiert. Dieses Dokument legt auch die Messanforderungen für Plattform-Firmware fest. Das hier definierte EFI-Protokoll nutzt in hohem Maße [TCG06a] und [TCG06b].

2.0 Datenstrukturen und Acronyms

2.1 Datenstrukturen

Wie in [TCG06a] MÜSSEN alle Datenwerte im Little-Endian-Format dargestellt werden. Strings MÜSSEN als Array von ASCII-Bytes dargestellt werden, wobei das Zeichen ganz links an der niedrigsten Speicherstelle platziert wird.

2.2 Akronyme und Konventionen

(Für hier nicht definierte Akronyme siehe [TCG06a])

TrEE Vertrauenswürdigen Ausführungsumgebung

Die Verwendung der Begriffe „MUSS“ und „SOLL“ in diesem Dokument sind gemäß [RFC2119] auszulegen.

3.0 EFI TrEE-Protokoll

Dieser Abschnitt enthält eine detaillierte Beschreibung des EFI_TREE_PROTOCOL und des EFI_TREE_SERVICE_BINDING_PROTOCOL. Das EFI TrEE-Protokoll wird verwendet, um mit einem TrEE zu kommunizieren.

3.1 TrEE EFI-Dienstbindungsprotokoll

Dieser Abschnitt definiert das TrEE EFI-Dienstbindungsprotokoll.

Zusammenfassung : Das EFI TrEE-Dienstbindungsprotokoll wird verwendet, um TrEE-Geräte zu lokalisieren, die von einem EFI TrEE-Protokolltreiber unterstützt werden, und um untergeordnete Treiberinstanzen des EFI TrEE-Protokolls zu erstellen und zu zerstören, die das zugrunde liegende TrEE-Gerät verwenden können.

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

Beschreibung Eine Anwendung (oder ein Treiber), die TrEE-Dienste benötigt, kann einen der Protokoll-Handler-Dienste wie BS->LocateHandleBuffer() verwenden, um nach Geräten zu suchen, die ein EFI TrEE-Dienstbindungsprotokoll veröffentlichen. Jedes Gerät mit einem veröffentlichten EFI TrEE-Dienstbindungsprotokoll unterstützt das EFI TrEE-Protokoll und kann möglicherweise verwendet werden.

Nach einem erfolgreichen Aufruf des EFI_TREE_SERVICE_BINDING_PROTOCOL. CreateChild() -Funktion, die untergeordnete EFI TrEE-Protokoll-Treiberinstanz ist für die Verwendung bereit.

Bevor eine EFI-Anwendung oder ein Treiber die Ausführung beendet, muss jeder erfolgreiche Aufruf der Funktion EFI_TREE_SERVICE_BINDING_PROTOCOL.CreateChild() mit einem Aufruf der Funktion EFI_TREE_SERVICE_BINDING_PROTOCOL.DestroyChild() abgeglichen werden.

3.2 TrEE EFI-Protokoll

Zusammenfassung - Das EFI TrEE-Protokoll wird verwendet, um mit einem TrEE zu kommunizieren – um Befehle an einen TrEE zu senden, es für vertrauenswürdige Ausführungsoperationen zu verwenden und um Zugriff auf das Firmware-Protokoll von Messungen bereitzustellen, die in dem TrEE erweitert wurden. Das Protokoll verwaltet ein Ereignisprotokoll der im TrEE aufgezeichneten Messungen mit einem Format, das mit dem TCG 1.2 TCG-Ereignisprotokoll identisch ist (siehe [TCG06b]); in dieser Spezifikation als TCG 1.2-Ereignisprotokoll im TrEE-Ereignisprotokollformat bezeichnet. Implementierer können zusätzliche Ereignisprotokolle mit anderen Formaten erstellen, aber diese Version des Protokolls definiert keine Möglichkeit, sie abzurufen.

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

Struktur der Protokollschnittstelle -

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;

Parameter

GetCapability

Dieser Dienst stellt Informationen über die TrEE- und Firmware-Funktionen bereit

GetEventLog

Abrufen eines Zeigers auf ein Firmware-Ereignisprotokoll

HashLogExtendEvent

Dieser Dienst bewirkt, dass der EFI TrEE-Treiber ein Ereignis erweitert und (optional) das Ereignis in das TrEE-Protokoll schreibt.

SubmitCommand

Dieser Dienst sendet einen Befehl direkt an den TrEE.

Beschreibung - Das EFI_TREE_PROTOCOL abstrahiert die TrEE-Aktivität. Diese Protokollinstanz stellt einen Startdienst bereit und wird als Startdiensttreiber instanziiert.

Startdiensttreiber werden beendet, wenn ExitBootServices ( ) aufgerufen wird, und alle Speicherressourcen, die von den Startdiensten Treibern verwendet werden, werden für die Verwendung in der Betriebssystemumgebung freigegeben.

Dieser Startdienst muss ein EVT_SIGNAL_EXIT_BOOT_SERVICES-Ereignis erstellen. Dieses Ereignis wird vom System benachrichtigt, wenn ExitBootServices ( ) aufgerufen wird.

EVT_SIGNAL_EXIT_BOOT_SERVICES ist ein synchrones Ereignis, das verwendet wird, um sicherzustellen, dass bestimmte Aktivitäten nach einem Aufruf einer bestimmten Schnittstellenfunktion stattfinden; in diesem Fall ist dies die Bereinigung, die als Reaktion auf die Funktion ExitBootServices ( ) durchgeführt werden muss. ExitBootServices ( ) kann keine Treiber bereinigen, die in das System geladen wurden. Die Treiber müssen dies selbst tun, indem sie ein Ereignis erstellen, dessen Typ EVT_SIGNAL_EXIT_BOOT_SERVICES ist und dessen Benachrichtigungsfunktion eine Funktion innerhalb des Treibers selbst ist. Wenn ExitBootServices ( ) dann seine Bereinigung beendet hat, signalisiert es den Ereignistyp EVT_SIGNAL_EXIT_BOOT_SERVICES.

Details zur Implementierung, wie ein Startdienst als EFI-Treiber instanziiert wird, wird dieses erforderliche EVT_SIGNAL_EXIT_BOOT_SERVICES-Ereignis erstellt, siehe Abschnitt 6.1 von [UEFI12].

3.3 EFI_TREE_PROTOCOL.GetCapability

Der EFI_TREE_PROTOCOL GetCapability-Funktionsaufruf liefert Protokollfähigkeitsinformationen und Zustandsinformationen über den TrEE.

Prototyp

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

Parameter

Dieser

Gibt den aufrufenden Kontext an.

ProtocolCapability

Der Aufrufer weist Speicher für eine TREE_BOOT_SERVICE_CAPABILITY-Struktur zu und setzt das Größenfeld auf die Größe der zugeordneten Struktur. Der Aufgerufene füllt die Felder mit den EFI-Protokollfähigkeitsinformationen und den aktuellen TrEE-Statusinformationen bis zu der Anzahl von Feldern aus, die in die Größe der übergebenen Struktur passen.

Verwandte Definitionen

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

Größe

Zugewiesene Größe der übergebenen Struktur

StructureVersion

Version der Struktur TREE_BOOT_SERVICE_CAPABILITY selbst. Für diese Version des Protokolls wird die Hauptversion auf 1 und die Nebenversion auf 0 zu setzen.

ProtocolVersion

Version des TrEE-Protokolls. Für diese Version des Protokolls wird die Hauptversion auf 1 und die Nebenversion auf 0 zu setzen.

HashAlgorithmBitMap

Unterstützte Hash-Algorithmen

SupportedEventLogs

Bitmap der unterstützten Ereignisprotokollformate (siehe oben)

TrEEPresentFlag

False = TrEE nicht vorhanden

MaxCommandSize

Maximale Größe (in Bytes) eines Befehls, der an TrEE gesendet werden kann

MaxResponseSize

Maximale Größe (in Bytes) einer Antwort, die von TrEE bereitgestellt werden kann

HerstellerID

4-Byte-Vendor-ID (siehe [TCG07], Abschnitt „TPM Capabilities Vendor ID“)

Beschreibung

Der Funktionsaufruf EFI_TREE_PROTOCOL Get Capability liefert EFI-Protokollversions- und Fähigkeitsinformationen sowie Zustandsinformationen über den TrEE. Der Aufrufer muss das Größen-Feld der zugewiesenen TREE_BOOT_SERVICE_CAPABILITY-Struktur setzen. Es wird erwartet, dass zukünftige Versionen dieses Funktionsaufrufs der Struktur zusätzliche Felder hinzufügen können. Der übergebene Größenwert ermöglicht es der Funktion, nur Felder zu füllen, für die der Aufrufer Speicher zugewiesen hat. Beispiel:

ProtocolCapability.Size = sizeof(TREE_BOOT_SERVICE_CAPABILITY);

Für diese Version der Spezifikation:

  1. Wenn die Parameter This oder ProtocolCapability NULL sind, gibt der Funktionsaufruf EFI_INVALID_PARAMETER zurück.

  2. Wenn die Eingabe ProtocolCapability.Size < sizeof(TREE_BOOT_SERVICE_CAPABILITY) ist, setzt die Funktion ProtocolCapability.Size gleich sizeof(TREE_BOOT_SERVICE_CAPABILITY), wie in dieser Spezifikation definiert, und gibt den Fehlercode EFI_BUFFER_TOO_SMALL zurück, die Werte der verbleibenden Felder sind undefiniert.

  3. Folgende Rückgabewerte MÜSSEN gesetzt werden:

    ProtocolCapability.StructureVersion.Major = 1

    ProtocolCapability.StructureVersion.Minor = 0

    ProtocolCapability.ProtocolVersion.Major = 1

    ProtocolCapability.ProtocolVersion.Minor = 0

  4. Wenn die Plattform kein TrEE hat, MÜSSEN die folgenden Werte zurückgegeben werden:

    ProtocolCapability.SupportedEventLogs = 0

    ProtocolCapability.HashAlgorithmBitmap = 0

    ProtocolCapability.TrEEPresentFlag = FALSE

    ProtocolCapability.MaxCommandSize = 0

    ProtocolCapability.MaxResponseSize = 0

    ProtocolCapability.ManufacturerID = 0

  5. Die minimale MaxCommandSize und MaxResponseSize MUSS 0x500 (oder größer) für Windows sein.

Zurückgegebene Statuscodes

EFI_SUCCESS

Operation erfolgreich abgeschlossen.

EFI_DEVICE_ERROR

Der Befehl war nicht erfolgreich. Die ProtocolCapability-Variable wird nicht ausgefüllt.

EFI_INVALID_PARAMETER

Einer oder mehrere der Parameter sind falsch. Die ProtocolCapability-Variable wird nicht ausgefüllt.

EFI_BUFFER_TOO_SMALL

Die ProtocolCapability-Variable ist zu klein, um die vollständige Antwort aufzunehmen. Es wird teilweise ausgefüllt (erforderliches Feld Größe wird gesetzt).

3.4 EFI_TREE_PROTOCOL.GetEventLog

Der Funktionsaufruf EFI_TREE_PROTOCOL Get Event Log ermöglicht es einem Aufrufer, die Adresse eines bestimmten Ereignisprotokolls und seinen letzten Eintrag abzurufen.

Prototyp

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

Parameter

EventLogFormat

Der Typ des Ereignisprotokolls, für das die Informationen angefordert werden.

EventLogLocation

Ein Zeiger auf die Speicheradresse des Ereignisprotokolls.

EventLogLastEntry

Wenn das Ereignisprotokoll mehr als einen Eintrag enthält, ist dies ein Zeiger auf die Adresse des Beginns des letzten Eintrags im Ereignisprotokoll im Speicher. Informationen darüber, welche Werte in diesem Parameter in den Sonderfällen eines leeren Ereignisprotokolls oder eines Ereignisprotokolls mit nur einem Eintrag zurückgegeben werden, finden Sie im Abschnitt „Beschreibung“ weiter unten.

EventLogTruncated

Wenn im Ereignisprotokoll mindestens ein Eintrag fehlt, weil ein Ereignis den für Ereignisse zugewiesenen Bereich überschritten hätte, wird dieser Wert auf TRUE gesetzt. Andernfalls ist der Wert FALSE und das Ereignisprotokoll ist vollständig.

Beschreibung

Die Firmware verwaltet ein Ereignisprotokoll der während des Bootvorgangs im TrEE aufgezeichneten Messungen. Während des Bootvorgangs, vor der Initialisierung der UEFI-Plattform, wird für jede im TrEE erweiterte Messung ein Eintrag im Ereignisprotokoll vorgenommen. In der UEFI-Umgebung wird jedes Mal, wenn HashLogExtendEvent aufgerufen wird, um eine Messung in TrEE zu erweitern, im Allgemeinen ein Ereignis im Ereignisprotokoll aufgezeichnet, das die erweiterte Messung enthält. Wenn der von der Firmware zugewiesene Bereich für das Ereignisprotokoll zu klein war, um alle hinzugefügten Ereignisse aufzunehmen, zeigt der Funktionsaufruf an, dass das Ereignisprotokoll abgeschnitten wurde und fehlende Einträge enthält. Diese Version der Spezifikation erfordert lediglich die Führung eines Ereignisprotokolls von SHA1-Messungen. Zukünftige Versionen dieser Spezifikation können zusätzliche Ereignisprotokolle führen, die andere Hash-Algorithmen unterstützen.

Der von dieser Funktion zurückgegebene Ereignisprotokollbereich wird freigegeben, wenn ExitBootServices ( ) aufgerufen wird. Aufrufer dieser Methode DÜRFEN nicht auf den Bereich zugreifen, nachdem ExitBootServices ( ) aufgerufen wurde. Für diese Version der Spezifikation:

  1. Wenn EventLogFormat nicht gleich TREE_EVENT_LOG_FORMAT_TCG_1_2 ist, MUSS der Funktionsaufruf EFI_INVALID_PARAMETER zurückgeben.

  2. Wenn kein TrEE vorhanden ist, MUSS die Funktion die folgenden Werte setzen und EFI_SUCCESS zurückgeben:

    1. EventLogLocation = NULL

    2. EventLogLastEntry = NULL

    3. EventLogTruncated = FALSE

  3. Der Wert der EventLogLocation muss auf den Start des angegebenen Ereignisprotokollformats im Arbeitsspeicher festgelegt werden

  4. Wenn das angegebene Ereignisprotokoll:

    1. keine Ereignisse enthält, MUSS EventLogLastEntry auf 0 gesetzt werden

    2. genau einen Eintrag enthält, MUSS EventLogLastEntry auf den gleichen Wert wie EventLogLocation gesetzt werden

    3. mehr als ein Ereignis enthält, MUSS EventLogLastEntry auf die Startadresse des letzten Ereignisses des angegebenen Ereignisprotokolls gesetzt werden

  5. Wenn ein vorheriger Aufruf von EFI_TREE_PROTOCOL.HashLogExtendEvent EFI_VOLUME_FULL zurückgegeben hat, MUSS EventLogTruncated auf TRUE gesetzt werden, andernfalls MUSS es auf FALSE gesetzt werden.

Zurückgegebene Statuscodes

EFI_SUCCESS

Operation erfolgreich abgeschlossen.

EFI_INVALID_PARAMETER

Einer oder mehrere Parameter sind falsch (z. B. Abfrage eines Ereignisprotokolls, dessen Format nicht unterstützt wird).

3.5 EFI_TREE_PROTOCOL.HashLogExtendEvent

Der Funktionsaufruf EFI_TREE_PROTOCOL HashLogExtendEvent bietet Aufrufern die Möglichkeit, Ereignisse zu erweitern und optional zu protokollieren, ohne dass Kenntnisse über tatsächliche TPM-Befehle erforderlich sind. Der Erweiterungsvorgang findet auch dann statt, wenn diese Funktion keinen Ereignisprotokolleintrag erstellen kann (z. B. weil das Ereignisprotokoll voll ist).

Prototyp

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

Parameter

Dieser

Gibt den aufrufenden Kontext an.

Flags

Bitmap mit zusätzlichen Informationen (siehe unten).

DataToHash

Physikalische Anfangsadresse des zu

hashenden Datenpuffers.

DataToHashLen

Die Länge in Bytes des Puffers, auf den von DataToHash verwiesen wird.

Event

Zeiger auf Datenpuffer, der Informationen über das Ereignis enthält.

Verwandte Definitionen

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

Größe

Gesamtgröße des Ereignisses einschließlich der Größenkomponente, des Headers und der Ereignis-Daten.

HeaderSize

Größe des Ereignisheaders selbst (sizeof(TrEE_EVENT_HEADER)).

Header Version

Header-Version. Für diese Version dieser Spezifikation soll der Wert 1 sein.

PCRIndex

Index des PCR, der erweitert werden soll (0 - 23).

EventType

Typ des Ereignisses, das verlängert (und optional protokolliert) werden soll.

Flag-Werte

Die Flags-Variable ist eine Bitmap, die zusätzliche Daten wie folgt bereitstellt:

#define TREE_EXTEND_ONLY 0x0000000000000001

Dieses Bit soll gesetzt werden, wenn ein Ereignis verlängert, aber nicht protokolliert werden soll.

#define PE_COFF_IMAGE 0x0000000000000010

Dieses Bit soll gesetzt werden, wenn ein PE/COFF-Image gemessen werden soll.

Beschreibung

Der Funktionsaufruf EFI_TREE_PROTOCOL Hash Log Extend Event berechnet die Messung eines Datenpuffers (der möglicherweise ein PE/COFF-Binärbild enthält) und veranlasst den TrEE-Treiber, die Messung zu erweitern. Darüber hinaus erstellt der Dienst optional einen Ereignisprotokolleintrag und fügt ihn für jedes vom Dienst unterstützte Ereignisprotokollformat an das Ereignisprotokoll an. Der Dienst ermöglicht es einem Aufrufer, TrEE zu nutzen, ohne irgendetwas über bestimmte TrEE-Befehle zu wissen.

Die Verwendung dieser Funktion zum Messen von PE/COFF-Bildern muss erfolgen, bevor Verschiebungen auf das Image angewendet wurden. Hinweis: Seien Sie bei der Verwendung dieser Methode zur Messung von PE/COFF-Images vorsichtig. Im Allgemeinen entfernen Implementierungen, die PE/COFF-Images laden, wichtige Daten während des Ladevorgangs aus dem Image und können die Ausrichtung der Imageabschnitte im Speicher ändern. Das Nettoergebnis ist, dass die Berechnung des Hash eines In-Memory-Bildes nicht mit der tatsächlichen Messung für das Image übereinstimmt, wie es richtig berechnet wurde, wenn es von Speichermedien geladen wird.

Beim Aufruf soll die Funktion die folgenden Aktionen ausführen:

  1. Wenn einer der Parameter This, DataToHash oder Event NULL ist, MUSS die Funktion EFI_INVALID_PARAMETER zurückgeben.

  2. Wenn Event.Size kleiner als Event.Header.HeaderSize + sizeof(UINT32) ist, MUSS die Funktion EFI_INVALID_PARAMETER zurückgeben.

  3. Wenn Event.Header.PCRIndex nicht 0 bis einschließlich 23 ist, MUSS die Funktion EFI_INVALID_PARAMETER zurückgeben.

  4. Wenn die Flags-Bitmap das PE_COFF_IMAGE-Bit GESETZT hat, aber das PE/COFF-Image beschädigt ist oder nicht verstanden wird, MUSS die Funktion EFI UNSUPPORTED zurückgeben.

  5. Die Funktion lässt jeden Wert für den Event.Header.EventType-Parameter zu.

  6. Die Funktion MUSS den Digest (Messwert) der Daten beginnend bei DataToHash mit einer Länge von DataToHashLen berechnen. Wenn das PE_COFF_IMAGE-Bit gesetzt ist, MUSS die Funktion die Messung des PE/COFF-Images gemäß „Messen eines PE/COFF-Images“ in Anhang A unten berechnen.

  7. Die Funktion MUSS den Befehl TPM2_PCR_Extend erfolgreich an TrEE senden, um die durch Event.Header.PCRIndex angegebene PCR mit dem Messauszug zu erweitern. Wenn der Befehl nicht erfolgreich gesendet werden kann, muss die Funktion EFI_DEVICE_ERROR zurückgeben. Wenn die Firmware mehr Algorithmen als SHA1 unterstützt, kann sie Digests mit anderen Algorithmen berechnen und diese auch erweitern.

  8. Wenn ein vorheriger Aufruf dieser Funktion EFI_VOLUME_FULL zurückgegeben hat und das TREE_EXTEND_ONLY-Bit im Flags-Parameter gesetzt ist, MUSS die Funktion EFI_VOLUME_FULL zurückgeben. (Es wird kein Versuch unternommen, den Ereignisprotokolleintrag dem/den Ereignisprotokoll(en) hinzuzufügen.)

  9. Die Funktion MUSS wie folgt einen TCG-Ereignisprotokolleintrag erstellen: (Anmerkung: Die TCG_PCR_EVENT-Struktur ist in [TCG06b] definiert und soll als Byte-ausgerichtet betrachtet werden.)

    1. TCG_PCR_EVENT.PCRIndex = Event.Header.PCRIndex

    2. TCG_PCR_EVENT.EventType = Event.Header.EventType

    3. TCG_PCR_EVENT.Digest = <der oben berechnete SHA1-Messungsauszug>

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

    5. TCG_PCR_EVENT. Ereignis = Event.Event (Hinweis: Dies ist eine Speicherkopie von EventSize Bytes)

  10. Die Funktion KANN ähnliche Ereignisprotokolleinträge für andere unterstützte Ereignisprotokollformate erstellen.

  11. Wenn der oben erstellte TCG_PCR_EVENT-Ereignisprotokolleintrag nicht in den Bereich passt, der dem TCG 1.2-Ereignisprotokoll im TrEE-Ereignisprotokollformat zugewiesen ist, MUSS die Funktion EFI_VOLUME_FULL zurückgeben.

  12. Wenn die Firmware zusätzliche Ereignisprotokollformate unterstützt und eines der für diese Ereignisprotokolle erstellten Ereignisse den für das Ereignisprotokoll zugewiesenen Bereich überschreiten würde, MUSS die Funktion EFI_VOLUME_FULL zurückgeben.

  13. Die Funktion MUSS die erstellten Ereignisse an ihre entsprechenden Ereignisprotokolle anhängen, und der Dienst MUSS seinen internen Zeiger auf den Beginn des letzten Ereignisses für jedes Ereignisprotokoll aktualisieren.

Zurückgegebene Statuscodes.

EFI_SUCCESS

Operation erfolgreich abgeschlossen.

EFI_DEVICE_ERROR

Der Befehl war nicht erfolgreich.

EFI_VOLUME_FULL

Der Erweiterungsvorgang ist aufgetreten, aber das Ereignis konnte nicht in ein oder mehrere Ereignisprotokolle geschrieben werden.

EFI_INVALID_PARAMETER

Einer oder mehrere der Parameter sind falsch.

EFI_UNSUPPORTED

Der PE/COFF-Imagetyp wird nicht unterstützt.

3.6 EFI_TREE_PROTOCOL.SubmitCommand

Dieser Dienst ermöglicht das Senden von Befehlen an den TrEE.

Prototyp

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

Parameter

Dieser

Gibt den aufrufenden Kontext an.

InputParameterBlockSize

Größe des TrEE-Eingangsparameterblocks.

InputParameterBlock

Zeiger auf den Eingangsparameterblock TrEE.

OutputParameterBlockSize

Größe des TrEE-Ausgangsparameterblocks.

OutputParameterBlock

Zeiger auf den TrEE-Ausgangsparameterblock.

Beschreibung

Der Funktionsaufruf EFI_TREE_PROTOCOL Submit Command bietet eine Pass-Through-Fähigkeit vom Aufrufer zum TrEE des Systems.

Der Aufrufer ist dafür verantwortlich, den an den TrEE zu sendenden Befehls-Bytestrom aufzubauen, und ist auch dafür verantwortlich, den resultierenden Bytestrom zu interpretieren, der von dem TrEE zurückgegeben wird. Die TrEE-In- und -Out-Operanden für jeden TrEE-Befehl werden an anderer Stelle definiert.

Beachten Sie, dass die zurückgegebenen Statuscodes das Ergebnis des Funktionsaufrufs widerspiegeln und nicht den Erfolg (oder Misserfolg) des zugrunde liegenden TrEE-Befehls.

Das TPM 2.0 darf TPM2_RC_RETRY nicht zurückgeben, bevor der Aufruf von ExitBootServices() abgeschlossen ist. (Der Grund für diese Anforderung ist, dass der Rückgabecode den Startvorgang blockieren würde, bis der TPM-Befehl abgeschlossen werden könnte.)

Das TPM 2.0 MUSS Zugriff auf seinen dauerhaften Speicher haben, bevor der Aufruf von ExitBootServices abgeschlossen wird. Wenn die TPM 2.0-Implementierung nach dem Aufruf von ExitBootServices MÖGLICHERWEISE keinen Zugriff auf persistenten Speicher hat, wenden Sie sich für zusätzliche Anforderungen bitte an Microsoft.

Zurückgegebene Statuscodes

EFI_SUCCESS

Der Befehlsbytestrom wurde erfolgreich an das Gerät gesendet und eine Antwort wurde erfolgreich empfangen.

EFI_DEVICE_ERROR

Der Befehl wurde nicht erfolgreich an das Gerät gesendet oder eine Antwort wurde nicht erfolgreich vom Gerät empfangen.

EFI_INVALID_PARAMETER

Einer oder mehrere der Parameter sind falsch.

EFI_BUFFER_TOO_SMALL

Der Ausgangsparameterblock ist zu klein.

Referenzen

[MSFT08]

Microsoft Corporation, „Windows Authenticode Portable Ausführbare Signaturformat“, Version 1.0, 21. März 2008.

[RFC2119]

Bradner, S., „Schlüsselwörter für die Verwendung in RFCs zum Angeben von Anforderungsstufen“, IETF RFC 2119, März 1997.

[TCG06a]

Trusted Computing Group, „TCG EFI Protocol“, Version 1.20 Revision 1.00, 9. Juni 2006.

[TCG06b]

Trusted Computing Group, „TCG EFI Platform Specification“, Version 1.20 Revision 1.0, 7. Juni 2006.

[TCG07]

Trusted Computing Group, „TCG Vendor ID Registry“, Version 1.0, Revision 0.1, 31. August 2007.

[UEFI12]

UEFI, „Unified Extensible Firmware Interface Specification“, Version 2.3.1 Errata C,

Juni 2012.

Anhang A: Statische Stamm von Vertrauensmessungen

Wichtig

Anhang A Implementierung von PCR[7]-Messungen ist für InstantGo-Systeme obligatorisch.

Auf hoher Ebene ist die Firmware für die Messung der folgenden Komponenten während des Startvorgangs verantwortlich:

  • Plattform-Firmware, die die UEFI-Startdienste und UEFI-Laufzeitdienste enthält oder misst

  • Sicherheitsrelevante Variablen, die der Plattform-Firmware zugeordnet sind

  • UEFI-Treiber oder Startanwendungen werden separat geladen

  • Variablen, die separat geladenen UEFI-Treibern oder UEFI-Startanwendungen zugeordnet sind

Die oben genannten Messungen sind in den Abschnitten 5.1–5.5 der TCG EFI-Plattform-Spezifikation [TCG06b] definiert und werden hierin nicht weiter erwähnt. Messungen in PCR[1] und PCR[3] sind je nach Plattformkonfiguration optional.

Für Windows wird PCR[7] verwendet, um die UEFI 2.3.1 Secure Boot-Richtlinie widerzuspiegeln. Diese Richtlinie beruht darauf, dass die Firmware alle Boot-Komponenten authentifiziert, die vor der UEFI-Umgebung gestartet wurden, und dass der UEFI-Plattform-Initialisierungscode (oder früherer Firmware-Code) die Secure-Boot-Richtlinieninformationen unveränderlich in PCR[7] aufzeichnet.

Plattform-Firmware, die sich an die Richtlinie hält, muss daher die folgenden Werte in PCR messen[7]:

  1. Die Inhalte der PK-Variable

  2. Die Inhalte der PK-Variable

  3. Die Inhalte der EFI_IMAGE_SECURITY_DATABASE-Variablen

  4. Die Inhalte der Variablen EFI_IMAGE_SECURITY_DATABASE1

  5. Einträge in EFI_IMAGE_SECURITY_DATABASE, die zum Validieren von EFI-Treibern oder EFI-Startanwendungen im Startpfad verwendet werden

  6. Die Inhalte der SecureBoot-Variable

Aus diesem Grund DÜRFEN die UEFI-Variablen PK, KEK, EFI_IMAGE_SECURITY_DATABASE, EFI_IMAGE_SECURITY_DATABASE1 und SecureBoot SOLLEN NICHT in PCR eingerechnet werden[3].

Wenn die Plattform außerdem einen Firmware-Debugger bereitstellt, der vor der UEFI-Umgebung gestartet werden kann, MUSS sie diese Tatsache in PCR[7] aufzeichnen. Wenn die Plattform einen Debugger für die UEFI-Umgebung bereitstellt, MUSS der Start des Debuggers ebenfalls in PCR[7] aufgezeichnet werden.

Hinweis zur Implementierung

Die UEFI-LoadImage-Funktion MUSS Messungen in PCR[2] oder PCR[4] pro in [TCG06b] beschriebenem Ereignis und auch PCR[7] pro Ereignis aufzeichnen, das im Abschnitt „Messen der UEFI-Konfiguration in PCR[7]“ unten beschrieben wird. Um festzustellen, ob eine Bildmessung auf PCR[2] oder PCR[4] zutrifft, MUSS LoadImage das Subsystem-Feld im PE/COFF-Bild untersuchen. Die Werte IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER, IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER und IMAGE_SUBSYSTEM_EFI_ROM entsprechen PCR[2]. Der Wert IMAGE_SUBSYSTEM_EFI_APPLICATION entspricht PCR[4]. Wenn das geladene Image ein anderer Typ ist, MUSS es in PCR[4] aufgezeichnet werden. Images, die LoadImage aufgrund eines (a) SignaturüberprüfungsBilder, die LoadImage nicht laden kann, weil (a) die Signaturüberprüfung fehlgeschlagen ist oder (b) weil das Image nicht der derzeit erzwungenen UEFI 2.3.1 Secure Start-Richtlinie entspricht, müssen nicht in einem PCR gemessen werden.fehlers oder (b) nicht laden, da das Image nicht der aktuell erzwungenen UEFI 2.3.1-Richtlinie für sicheres Starten entspricht, muss nicht in einem PCR gemessen werden.

****Verwandte Definitionen

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

Messen eines PE/COFF-Images

Beim Messen eines PE/COFF-Image soll der EventType wie in [TCG06b] definiert sein (zum Beispiel beim Messen einer EFI-Boot-Anwendung soll der EventType EV_EFI_BOOT_SERVICES_APPLICATION sein) und der Event-Wert soll der Wert der EFI_IMAGE_LOAD_EVENT-Struktur sein, die in [ TCG06b].

Der HashLogExtendEvent-Dienst muss das PE/COFF-Bild gemäß dem im Abschnitt „Berechnung des PE-Image-Hash“ von [MSFT08] angegebenen Verfahren hashen.

Messen der UEFI-Konfiguration in PCR[7]

Für alle EFI-Variablenwert-Ereignisse soll der EventType EV_EFI_VARIABLE_DRIVER_CONFIG sein, wie oben definiert, und der Event-Wert soll der Wert der EFI_VARIABLE_DATA-Struktur sein, die oben in dieser Spezifikation definiert ist (diese Struktur soll als Byte-ausgerichtet betrachtet werden). Der Messauszug soll der SHA-1-Hash der Ereignisdaten sein, der die EFI_VARIABLE_DATA-Struktur ist. (Hinweis: Dies ist ein anderer Digest als der in [TCG06b] angegebene.) Der Wert von EFI_VARIABLE_DATA.UnicodeNameLength ist die Anzahl der CHAR16-Zeichen (nicht die Anzahl der Bytes). Der Inhalt von EFI_VARIABLE_DATA.UnicodeName MUSS KEINEN Nullabschluss enthalten. Wenn das Lesen der EFI-Variable EFI_NOT_FOUND zurückgibt, MUSS das Feld EFI_VARIABLE_DATA.VariableDataLength auf Null gesetzt werden und das Feld EFI_VARIABLE_DATA.VariableData hat eine Größe von Null.

  1. Wenn die Plattform einen Firmware-Debugger-Modus bereitstellt, der vor der UEFI-Umgebung verwendet werden kann, oder wenn die Plattform einen Debugger für die UEFI-Umgebung bereitstellt, SOLL die Plattform ein EV_EFI_ACTION-Ereignis wie in [TCG06b] angegeben in PCR[7] erweitern, bevor sie dies zulässt Verwendung des Debuggers. Die Ereigniszeichenfolge soll „UEFI Debug Mode“ lauten. Darüber hinaus MUSS die Plattform einen TCG-Ereignisprotokolleintrag wie folgt erstellen:

    1. TCG_PCR_EVENT.PCRIndex = 7

    2. TCG_PCR_EVENT.EventType = EV_EFI_ACTION

    3. TCG_PCR_EVENT.Digest = <der SHA-1-Digest des Zeichenfolgenwerts „UEFI Debug Mode“ ohne das abschließende NULL-Zeichen>

    4. TCG_PCR_EVENT.EventSize = strlen(„UEFI Debug Mode“)

    5. TCG_PCR_EVENT. Ereignis = „UEFI-Debug Mode“

    Die Plattform KANN ähnliche Ereignisprotokolleinträge für andere unterstützte Ereignisprotokollformate erstellen.

  2. Vor der Ausführung von Code, der nicht kryptographisch als vom Plattformhersteller bereitgestellt authentifiziert ist, MUSS die Firmware des Plattformherstellers die folgenden Werte in der aufgeführten Reihenfolge unter Verwendung des Ereignistyps EV_EFI_VARIABLE_DRIVER_CONFIG für PCR[7] messen:

    1. SecureBoot-Variablenwert

    2. Der PK-Variablenwert

    3. Der KEK-Variablenwert

    4. Der Variablenwert EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE

    5. Der Variablenwert EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE1

  3. Wenn die Plattform das Ändern einer der folgenden UEFI-Richtlinien-Variablen unterstützt, nachdem sie anfänglich in PCR[7] gemessen wurden und bevor ExitBootServices ( ) abgeschlossen wurde, ohne die Plattform unbedingt neu zu starten, MUSS sie die Variable sofort nach der Änderung erneut messen. Darüber hinaus MUSS der normale Aktualisierungsprozess zum Festlegen einer der unten aufgeführten UEFI-Variablen vor der anfänglichen Messung in PCR[7] oder nach Abschluss des Aufrufs von ExitBootServices() erfolgen.

    1. SecureBoot-Variablenwert

    2. Der PK-Variablenwert

    3. Der KEK-Variablenwert

    4. Der Variablenwert EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE

    5. Der Variablenwert EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE1

  4. Das System SOLL das Ereignis EV_SEPARATOR in PCR[7] messen. (Dies geschieht zur gleichen Zeit, zu der der Separator zu PCR[0] bis PCR[7] gemessen wird.)

  5. Vor dem Starten eines EFI-Treibers oder einer EFI-Boot-Anwendung (und unabhängig davon, ob der Start darauf zurückzuführen ist, dass der EFI-Boot-Manager ein Image aus den UEFI-Variablen DriverOrder oder BootOrder oder ein bereits gestartetes Image auswählt, das die UEFI LoadImage()-Funktion aufruft), wird die UEFI Die Firmware SOLL den Eintrag in der Variablen EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE messen, der verwendet wurde, um das EFI-Image in PCR[7] zu validieren. Die Messung SOLL in Verbindung mit dem Laden von Image erfolgen. Für dieses Ereignis soll der Ereignistyp EV_EFI_VARIABLE_AUTHORITY sein und der Ereigniswert soll der Wert der EFI_VARIABLE_DATA-Struktur sein (die Struktur ist oben in dieser Spezifikation mit einer anderen Definition als der TCG-Spezifikation definiert). Der EFI_VARIABLE_DATA.VariableData-Wert soll der EFI_SIGNATURE_DATA-Wert aus der EFI_SIGNATURE_LIST sein, die die Autorität enthielt, die verwendet wurde, um das Bild zu validieren, und der EFI_VARIABLE_DATA.VariableName soll auf EFI_IMAGE_SECURITY_DATABASE_GUID gesetzt werden. EFI_VARIABLE_DATA.UnicodeName soll auf den Wert von EFI_IMAGE_SECURITY_DATABASE gesetzt werden. Der Wert soll das abschließende NULL-Zeichen nicht enthalten.

  6. Vor dem Starten zusätzlicher EFI-Treiber oder EFI-Startanwendungen SOLL die UEFI-Firmware prüfen, ob der Eintrag in der Variablen EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE, die das EFI-Image validiert, zuvor mit dem Ereignistyp EV_EFI_VARIABLE_AUTHORITY in PCR[7] gemessen wurde. Wenn dies nicht der Fall ist, MUSS es wie im vorherigen Schritt beschrieben gemessen werden. Wenn es zuvor gemessen wurde, MUSS es NICHT erneut gemessen werden.

Hinweis

Ein Messbeispiel für PCR[7]-Messungen ist auf Anfrage bei Microsoft erhältlich.