Vertrauenswürdige Ausführungsumgebung – ACPI-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 Hintergrund
Diese Spezifikation definiert das ACPI-Geräteobjekt für ein TPM 2.0-Gerät und die Steuerungsmethoden, die dem für Windows 8 erforderlichen ACPI-Geräteobjekt zugeordnet sind. Die Steuerungsmethoden implementieren das Äquivalent der physischen TCG-Präsenz-ACPI-Schnittstelle, das Äquivalent der Platform Reset Attack Mitigation-Schnittstelle und optional eine ACPI-Methode zum Senden eines Befehls an das TPM 2.0-Gerät.
Eine zusätzliche statische ACPI-Tabelle (TPM2) wird verwendet, um den Mechanismus für die Kommunikation zwischen dem TPM 2.0-Gerät und dem Windows 8-Betriebssystem zu definieren.
Hinweis
Microsoft bezeichnet den Begriff „TPM.Next“ der Trusted Computing Group als „TPM 2.0“
2.0 Anforderungen
Diese Spezifikation geht von einer Computerplattform aus, die ACPI-basierte Kommunikation unterstützt, wie in [ACPI09] zwischen einem Betriebssystem und einer Firmware-Umgebung angegeben.
3.0 Nutzungsszenarien (nur beispielhaft)
3.1 Senden eines Präsenzbefehls
Ein typisches Nutzungsszenario sieht wie folgt aus:
In der Betriebssystemumgebung erkennt eine Anwendung, dass das TPM 2.0-Gerät nicht vollständig für die Verwendung mit Windows 8 bereitgestellt ist. (Ein Beispiel dafür, wie dies passieren könnte, ist, wenn ein neues Betriebssystemabbild installiert wird, nachdem ein vorheriges Betriebssystemabbild das TPM 2.0 bereitgestellt hat.)
Die Anwendung startet einen Betriebssystemassistenten, um das TPM 2.0-Gerät für die Verwendung vorzubereiten.
Der Assistent interagiert mit dem Computeradministrator über die Benutzeroberfläche und stellt fest, dass der Administrator das TPM 2.0-Gerät löschen muss, um es bereitzustellen, da der Autorisierungswert für die Sperrung des TPM 2.0-Geräts nicht verfügbar ist.
Um das TPM 2.0-Gerät zu löschen, fordert das Betriebssystem (durch Ausführen einer ACPI-Steuerungsmethode für das TPM 2.0-Geräteobjekt) die Firmware auf, den Vorgang zum Löschen des TPM 2.0-Geräts beim nächsten Start durchzuführen, vorausgesetzt, ein physisch anwesender Benutzer bestätigt, dass er dem Löschen zustimmt TPM 2.0-Gerät.
Das Betriebssystem startet die Plattform neu.
Während des frühen Teils des Startvorgangs erkennt die Firmware die ausstehende Anforderung des Betriebssystems, das TPM 2.0-Gerät zu löschen.
Die Firmware zeigt einem physisch anwesenden Benutzer eine Benutzeroberfläche an, in der er aufgefordert wird, Maßnahmen zu ergreifen, um das Löschen des TPM 2.0-Geräts zu bestätigen.
Ein physisch anwesender Benutzer bestätigt das Löschen des TPM 2.0-Geräts.
Die Firmware löscht das TPM 2.0-Gerät mithilfe der Autorisierung der Plattformhierarchie.
Falls erforderlich, wird die Plattform sofort neu gestartet, um das Löschen des TPM 2.0-Geräts fortzusetzen.
Das Betriebssystem bootet.
Das Betriebssystem fragt (über eine ACPI-Steuerungsmethode auf dem TPM 2.0-Gerät) ab, ob die letzte Betriebssystemanforderung zum Löschen des TPM 2.0-Geräts entweder (a) erfolgreich war, (b) nicht vom physisch anwesenden Benutzer bestätigt wurde oder (c) einige hatte anderer Fehler. Im Folgenden gehen wir davon aus, dass das TPM 2.0-Gerät erfolgreich gelöscht wurde.
Der TPM 2.0-Gerätebereitstellungsassistent im Betriebssystem führt zusätzliche Befehle aus, um das Gerät für die Verwendung durch Windows vorzubereiten.
3.2 Anfordern des Löschens des Speichers beim nächsten Start
Dieses Szenario zeigt, wie die Memory Clear-Funktion des Systems Angriffe vereitelt, die nach einem unerwarteten Neustart der Plattform Systemspeicher für Schlüsselmaterial stehlen.
Innerhalb des Betriebssystems aktiviert ein Administrator auf einem System mit einem TPM 2.0-Gerät die BitLocker-Funktion für das Betriebssystemvolume.
Die BitLocker-Funktion ruft die TPM 2.0-Geräte-ACPI-Steuerungsmethode auf, um das ClearMemory-Bit festzulegen, das in der TCG Platform Reset Attack Mitigation Specification definiert ist.
Die BitLocker-Funktion verschlüsselt das Betriebssystemvolume.
Der Administrator lässt das System mit gesperrtem Bildschirm unbeaufsichtigt.
Eine böswillige Person stiehlt das System, während es läuft.
Der Angreifer steckt einen USB-Stick ein und entfernt schnell die Systembatterie und setzt sie wieder ein.
Das System beginnt zu booten, wenn der Akku wieder eingesetzt wird.
Da das ClearMemory-Bit zuvor gesetzt wurde, löscht die Firmware den gesamten Systemspeicher, bevor Code gestartet wird, der nicht vom Plattformhersteller bereitgestellt wurde.
Die böswillige Person konfiguriert die Firmware während des Bootens so, dass sie vom USB-Gerät bootet, obwohl der Code auf dem USB-Gerät nicht ordnungsgemäß signiert ist.
Der Code auf dem USB-Gerät durchsucht den Systemspeicher nach dem BitLocker Volume Master Key, aber er wird nicht gefunden.
Warnung
Die Schritte 11 bis 16 ähneln den vorherigen Schritten, verwenden jedoch die UEFI-Schnittstelle anstelle von ACPI
Die böswillige Person versucht, das System normal zu booten.
Da BitLocker mit dem TPM-Schlüsselschutz aktiviert wurde, ermöglicht dies BootMgr, den Volume-Hauptschlüssel für das Betriebssystemvolume zu „entsiegeln“, da sich die korrekten Messwerte im TPM 2.0-Gerät befinden, wenn BootMgr ausgeführt wird.
Der Startvorgang fährt mit dem Anmeldebildschirm des Betriebssystems fort.
Die böswillige Person entfernt den Akku erneut, setzt ihn dann wieder ein und bootet den Code von einem USB-Gerät.
Da das ClearMemory-Bit gesetzt wurde, löscht die Systemfirmware den gesamten Systemspeicher während des Bootens.
Obwohl der Code des USB-Geräts den Systemspeicher scannt, befindet sich der Verschlüsselungsschlüssel des Betriebssystemvolumes nicht im Speicher.
3.3 Ausgeben eines Befehls an das TPM 2,0-Gerät
Dieses Beispiel gilt nicht für alle Systemarchitekturen.
Der Windows TPM 2.0-Treiber möchte einen Befehl an das TPM 2.0-Gerät ausgeben.
Der Windows TPM 2.0-Treiber schreibt den auszuführenden Befehl an die physische Adresse, die zuvor während der Initialisierung des Windows TPM 2.0-Treibers aus dem ACPI-definierten Steuerbereich gelesen wurde.
Der Windows TPM 2.0-Treiber führt die ACPI-Steuerungsmethode aus, um einen TPM 2.0-Befehl auszuführen.
Der Windows TPM 2.0-Treiber fragt die Register im Steuerbereich ab, bis sie anzeigen, dass der TPM-Befehl abgeschlossen ist.
Der Windows TPM-Treiber liest die Befehlsantwort von der physischen Adresse, die zuvor während der Initialisierung des Windows TPM-Treibers aus dem ACPI-definierten Steuerbereich gelesen wurde.
4.0 Allgemeine ACPI-Anforderungen für das TPM 2.0-System und -Gerät
4.1 Machtüberlegungen
ACPI D1/D2
Das TPM 2.0-Gerät KANN ACPI D1 und/oder ACPI D2 unterstützen, MUSS sich aber so verhalten, als ob es sich in D1 oder D2 im Energiezustand ACPI D0 befände.
ACPI S3 (Sleep)
Das TPM 2.0 KANN S3 unterstützen, aber der Eintritt in und das Verlassen des S3-Energiesparzustands für das Gerät MUSS vom System-/Plattformhersteller gesteuert werden.
Das Betriebssystem (oder andere Software, die in der Betriebssystemumgebung ausgeführt wird) DARF NICHT in der Lage sein, das TPM 2.0-Gerät in S3 zu platzieren oder zu bewirken, dass das TPM 2.0-Gerät S3 verlässt. Wenn sich das TPM 2.0-Gerät beispielsweise auf einem Bus befindet, DARF das Betriebssystem den Bus NICHT herunterfahren können, wodurch das TPM 2.0-Gerät in S3 eintritt.
Der Windows 8 TPM-Treiber versucht, einen TPM2_Shutdown-Befehl auszugeben, bevor er in S3 (Ruhezustand) wechselt.
Wenn eine Hardwareplattform S3 unterstützt und das TPM seinen Zustand nicht beibehält, während sich das System in S3 befindet, MUSS die Plattform die erforderlichen TPM2_Init- und TPM2_Startup(TPM_SU_STATE)-Befehle während der S3-Wiederaufnahme ausgeben. Es ist möglich, dass das Betriebssystem den TPM2_Shutdown-Befehl vor dem Eintritt in S3 nicht abgeschlossen hat. Dies könnte dazu führen, dass das Rückgabeergebnis von TPM2_Startup(TPM_SU_STATE) einen Fehler zurückgibt. Die Systemfirmware, die von S3 fortgesetzt wird, MUSS angemessen mit einem TPM2_Startup-Fehler umgehen. Zum Beispiel, indem Sie entweder den Zugriff auf das TPM über Hardware deaktivieren, einen TPM2_Startup(TPM_SU_CLEAR)-Befehl ausgeben und das Gerät sicher konfigurieren, indem Sie Maßnahmen ergreifen, wie das Erweitern eines Trennzeichens mit einem Fehlerdigest (0x01) in die PCRs 0 bis 7 und das Sperren von NV-Indizes.
Das System MUSS die während S3 verstrichene Zeit berücksichtigen, indem es die Anzahl der TPM-Wörterbuchangriffsfehler (TPM_PT_LOCKOUT_COUNTER) für die Zeit, die das System in S3 war, gemäß dem Sperrintervall (TPM_PT_LOCKOUT_INTERVAL) verringert. Dies kann eine Plattformimplementierung erfordern, um eine Standby-Spannung bereitzustellen, um die TPM-Uhr und/oder den TPM-Zustand während S3 beizubehalten, oder eine Plattform könnte auch sicher Informationen darüber bereitstellen, wie viel Zeit verstrichen ist, während sich das System in einem Niedrigenergiezustand befand, damit das TPM seine Autorisierung zuverlässig aktualisieren kann Fehleranzahl für seine Wörterbuchangriffslogik.
Energiesparzustände für verbundene Standby-Systeme
Windows 8 führt keine zusätzlichen Aktionen im Zusammenhang mit dem TPM beim Eintreten und Beenden von Energiesparzuständen für Connected Standby-Systeme durch. Die Plattform MUSS alle Aktionen ausführen, die erforderlich sind, damit sich das TPM so verhält, als ob es sich in D0 befände, wenn das System für Connected Standby-Systeme in Niedrigenergiezustände eintritt und diese verlässt. Dies KANN eine Plattformimplementierung erfordern, um eine Standby-Spannung bereitzustellen, um die TPM-Uhr mit Strom zu versorgen und/oder den Zustand beizubehalten. Alternativ kann eine Plattform dem TPM sicher Informationen darüber bereitstellen müssen, wie viel Zeit verstrichen ist, während sich das System in einem Niedrigenergiezustand befand, damit das TPM seine Autorisierungsfehlerzahl für seine Wörterbuchangriffslogik zuverlässig aktualisieren kann.
System Aus
Das System SOLLTE die während des vollständigen Herunterfahrens verstrichene Zeit sicher berücksichtigen, indem es die Anzahl der TPM-Wörterbuchangriffsfehler (TPM_PT_LOCKOUT_COUNTER) für die Zeit verringert, in der sich das System in S5 gemäß dem Sperrintervall (TPM_PT_LOCKOUT_INTERVAL) befand.
4.2 ACPI Tabellen
Ein System mit einem TPM 2.0-Gerät MUSS eine Geräteobjekttabelle mit einer Hardwaregeräte-ID und einer herstellerspezifischen statischen Tabelle des Betriebssystems (TPM2) bereitstellen, wie unten beschrieben.
Sowohl die TPM2-Tabelle als auch das TPM 2.0-Geräteobjekt MÜSSEN persistent sein, sobald die Plattform an einen Kunden geliefert wird. (z. B. DÜRFEN Firmware-Optionen das Ausblenden der TPM2-Tabelle oder des TPM 2.0-Geräteobjekts NICHT zulassen.) Eine Ausnahme besteht, wenn ein System mit einer nicht standardmäßigen Option geliefert wird, um TPM 1.2-Funktionalität anstelle von TPM 2.0-Funktionalität bereitzustellen (d. h. für die Kompatibilität mit älteren Betriebssysteme wie Windows 7.) In dieser Situation KÖNNEN die TPM2-Tabelle und das TPM 2.0-Geräteobjekt über eine BIOS-Konfigurationsoption entfernt und die Aufzählung eines TPM 1.2 durchgeführt werden. Hinweis: Ein Connected Standby System für Windows 8 muss standardmäßig mit einem TPM 2.0 ausgeliefert werden, das für das Betriebssystem sichtbar ist. Wenden Sie sich an Microsoft, um technische Anleitungen zum Wechseln zwischen TPM 2,0 und TPM 1,2 auf einer Hardwareplattform zu erhalten.
4.3 TPM 2.0-Geräteobjekt-ACPI-Tabelle
4.3.1 Bushierarchie
Die Geräteobjekttabelle MUSS sich unter der DSDT-Tabelle im ACPI-Namespace befinden. Das TPM 2.0-Geräteobjekt MUSS sich unter dem Systembus unter „root\_SB“ befinden.
4.3.2 Hardwarekennung
Die tatsächliche Plug-and-Play-Hardwarekennung (z. B. _HID) für das TPM 2.0-Geräteobjekt MUSS „MSFT0101“ lauten, oder das Gerät MUSS eine kompatible ID von „MSFT0101“ haben, und die _HID könnte herstellerspezifisch sein.
4.3.3 Ressourcendeskriptoren
Das ACPI TPM 2.0-Geräteobjekt MUSS alle Ressourcen beanspruchen, die vom TPM 2.0-Gerät verwendet werden.
4.3.4 Kontrollmethoden
4.3.4.1 Abwehr von Plattform-Reset-Angriffen
Das System MUSS alle ACPI- und UEFI-bezogenen Teile von [TCG08] für UEFI implementieren. Das Geräteobjekt MUSS die in [TCG08], Abschnitt 6, definierte Steuermethode-Schnittstelle implementieren. Die Schnittstelle ist auch dann erforderlich, wenn die Plattform den Speicher bei jedem Start bedingungslos löscht. Das Löschen des Speichers DARF NICHT vom TPM 2.0-Gerätestatus abhängig sein (im Gegensatz dazu erfordert [TCG08] kein Löschen des Speichers, wenn das TPM 1.2 nicht im Besitz ist). Außerdem MÜSSEN die Abschnitte 3, 5 von [TCG08] umgesetzt werden. Die _DSM-Abfragefunktion MUSS gemäß der ACPI-Spezifikation implementiert werden (Funktionsindex 0). (Hinweis: Es gibt einen Fehler in der ACPI 4.0-Spezifikation bezüglich des Rückgabewerts für die _DSM-Methode. Der Rückgabewert der _DSM-Methode sollte ein Puffer sein, der 0x03 enthält.) Die Implementierung MUSS automatisch ein ordnungsgemäßes Herunterfahren des Betriebssystems erkennen und ClearMemory löschen bisschen auf solche Veranstaltungen.
Besonderer Hinweis für UEFI-basierte ARM-Systeme mit einem TPM 2.0: Auf UEFI-basierten ARM-Systemen mit einem TPM 2.0 fordert Windows 8 bei jedem Start bedingungslos das Löschen des Speichers über die UEFI-Schnittstelle an. Die Implementierung der ACPI-Schnittstelle ist weiterhin erforderlich, aber die Schnittstelle KANN so implementiert werden, dass sie den Status der ClearMemory- oder DisableAutoDetect-Flags nicht ändert. (Hinweis: Microsoft empfiehlt, dass die ACPI-Schnittstelle gemäß der TCG-Spezifikation implementiert wird, sodass der Aufruf der ACPI-Schnittstelle den Status von ClearMemory oder DisableAutoDetect ändert.)
4.3.4.2 Physische Präsenzschnittstelle
Das System MUSS die in [TCG11] definierte Spezifikation gemäß den zusätzlichen Anmerkungen unten implementieren:
Die Verwendung von TPM in der TCG-Spezifikation ist mit dem TPM 2.0-Gerät gleichzusetzen.
Die in Abschnitt 2 definierten Kontrollmethoden MÜSSEN mit den folgenden Einschränkungen implementiert werden:
Die _DSM-Abfragefunktion MUSS gemäß der ACPI-Spezifikation implementiert werden (Funktionsindex 0). (Hinweis: In der ACPI 4.0-Spezifikation ist ein Fehler bezüglich des Rückgabewerts für die _DSM-Methode. Der Rückgabewert der _DSM-Methode sollte ein Puffer sein, der 0x01FF enthält.)
Die Implementierung MUSS den Wert „2: Reboot“ für „Plattformspezifische Aktion zum Übergang in die Pre-OS-Umgebung abrufen“ zurückgeben. PPI-Operationen MÜSSEN für einen Übergang eines Neustarts und SOLLTEN für einen Übergang zum Herunterfahren auftreten.
Die Implementierung der folgenden Steuerungsmethoden ist optional: „TPM-Vorgangsanforderung an Pre-OS-Umgebung senden“ (kann „2: Allgemeiner Fehler“ zurückgeben) und „Bevorzugte Benutzersprache senden“ (kann „3: Nicht implementiert“ zurückgeben).
Die Anforderungen in Abschnitt 3 MÜSSEN mit folgenden Überarbeitungen umgesetzt werden:
Das BIOS muss keinen dauerhaften Speicher für das NoPPIProvision-Flag bereitstellen, da die von ihm autorisierten Vorgänge für den TPM 2.0-Gerätezustand nicht relevant sind.
Tabelle 2 wird wie folgt überarbeitet:
Tabelle 1: überarbeitete PPI-Tabelle 2
Betriebswert
Vorgangsname
TPM Stat
BIOS TPM Mgmt Flags
Obligatorisch versus Optional
Wenn eine physische Anwesenheitsbestätigung erforderlich ist
Benötigt möglicherweise einen zusätzlichen Boot-Zyklus
0
Keine Operation
M
1–4
Keine Operation
M
5
TPM2_ClearControl(NO) +
TPM2_Clear
X
M
NoPPIClear is FALSE
X
6-11
Keine Operation
M
12-13
Keine Operation
O
14
TPM2_ClearControl(NO) +
TPM2_Clear
X
M
NoPPIClear is FALSE
X
15-16
Keine Operation
M
17
SetNoPPIClear_False
X
O1
18
SetNoPPIClear_True
X
O1
Always
19–20
Keine Operation
O2
21-22
TPM2_ClearControl(NO) +
TPM2_Clear
X
M
NoPPIClear is FALSE
X
23 - 127
Reserviert
>=128
Herstellerspezifisch
X
X
O
X
Wichtig
Für SetNoPPIClear_False: Wenn das BIOS die mit "O1" oder "O2" gekennzeichneten Elemente implementiert, muss es sie als Satz implementieren. Für die No Operation, die auf SetNoPPIClear_True folgt, darf das BIOS die Operationen 19 und 20 nicht implementieren, wenn es die Operation 12 nicht implementiert.
Tabelle 3 wird wie folgt überarbeitet:
Vorgang
Wert
Vorgang
Name
Vom BIOS gesendete TPM-Befehle und andere BIOS-Aktionen zum Ausführen des Vorgangs
0
Keine Operation
Keine Operation
1-4, 6-13, 15-16, 19-20
Keine Operation
Keine Operation. Die Vorgangsnummer MUSS jedoch gespeichert werden und das Ergebnis, wenn es vom Betriebssystem abgefragt wird, MUSS Erfolg zurückgeben.
5, 14, 21, 22
Clear
TPM2_ClearControl(NO) +
TPM2_Clear
<PLATFORM RESET > [*Falls erforderlich, um die TPM-Änderungen von TPM2_CLEAR beizubehalten. Microsoft geht davon aus, dass dies auf den meisten Systemen unnötig ist.]
17
SetNoPPIClear_False
(Körperliche Anwesenheit zum Löschen erforderlich.)
Dieser Vorgang ändert den TPM-Status nicht.
Setzt das BIOS TPM Management Flag NoPPIClear auf FALSE.
18
SetNoPPIClear_True
(Beim Löschen ist keine physische Anwesenheitsbestätigung erforderlich.)
Dieser Vorgang ändert den TPM-Status nicht.
Setzt das BIOS TPM Management Flag NoPPIClear auf TRUE.
23 - 127
Reserviert
Reserviert, nicht implementieren oder verwenden
>=128
Herstellerspezifisch
Zuordnung von TPM-Befehlen zu herstellerspezifischen Vorgängen
Der Geist von Abschnitt 4 MUSS beibehalten werden, um eine Bestätigung von einem physisch anwesenden Benutzer zu erhalten, wenn es erforderlich ist, eine Operation durchzuführen, aber der eigentliche Mechanismus muss nicht aus Tastendrücken bestehen. Die Schlüssel oder andere Mechanismen zur Bestätigung der Zustimmung liegen beim Plattformhersteller.
Op
Wert
Vorgang
Name
Bestätigung
Text
5, 14, 21, und 22
Clear
Es wurde eine Konfigurationsänderung angefordert, um das TPM (Trusted Platform Module) dieses Computers zu löschen.
WARNUNG: Durch das Löschen werden auf dem TPM gespeicherte Informationen gelöscht. Sie verlieren alle erstellten Schlüssel und den Zugriff auf die mit diesen Schlüsseln verschlüsselten Daten.
Drücken Sie <CAK>, um das TPM zu löschen
Drücken Sie <RK>, um diese Änderungsanforderung abzulehnen und fortzufahren
18
SetNoPPIClear_True
Es wurde eine Konfigurationsänderung angefordert, damit das Betriebssystem das TPM (Trusted Platform Module) des Computers löschen kann, ohne in Zukunft eine Benutzerbestätigung zu verlangen.
ANMERKUNG: Diese Aktion löscht das TPM nicht, aber durch die Genehmigung dieser Konfigurationsänderung erfordern zukünftige Aktionen zum Löschen des TPM keine Benutzerbestätigung.
WARNUNG: Durch das Löschen werden auf dem TPM gespeicherte Informationen gelöscht. Sie verlieren alle erstellten Schlüssel und den Zugriff auf die mit diesen Schlüsseln verschlüsselten Daten.
Drücken Sie <CAK>, um zukünftige Anforderungen des Betriebssystems zum Löschen des TPM zu genehmigen
Drücken Sie <RK>, um diese Änderungsanforderung abzulehnen und fortzufahren
Abschnitt 5 ist informativ.
Angeschlossene Standby-Systeme KÖNNEN NoPPIClear auf TRUE hartcodieren und die Operationen 17 und 18 nicht implementieren. Dies bedeutet, dass sie keine Bestätigungsdialoge für physische Anwesenheitsaktionen implementieren müssen, da keine physischen Anwesenheitsoperationen eine Benutzerbestätigung erfordern.
Die Firmware MUSS die Speicher- und Endorsement-Hierarchien aktiviert lassen, wenn sie die Kontrolle an den anfänglichen Programmladecode wie den Windows-Start-Manager übergibt.
4.3.4.3 Optionale ACPI-Startmethode
Hinweis: Einige Plattformen KÖNNEN diese optionale ACPI-Methode implementieren, damit das Betriebssystem die Firmware anfordern kann, einen TPM 2.0-Befehl auszuführen oder abzubrechen. Die Verwendung der ACPI-Startmethode wird durch das StartMethod-Feld der statischen ACPI-Tabelle bestimmt (siehe Abschnitt 4.4). Wenn das StartMethod-Feld der statischen ACPI-Tabelle die Verwendung dieser Methode anzeigt, MUSS die ACPI-Startmethode implementiert werden. Die ACPI Die hierin definierten Funktionen sollen sich im _DSM-Steuermethodenobjekt befinden. [Hinweis: Dies ist keine Steuerungsmethode in der TPM2-ACPI-Tabelle.] Die hier definierte _DSM-Methode MUSS wie folgt implementiert werden:
UUID |
Revision |
Function |
Beschreibung |
6bbf6cab-5463-4714-b7cd-f0203c0368d4 |
0 |
0 |
Wie in [ACPI09], Abschnitt 9.14.1 beschrieben. |
0 |
1 |
Start |
Funktion starten
Eingabeargumente:
Arg0 (Buffer): UUID = 6bbf6cab-5463-4714-b7cd-f0203c0368d4
Arg1 (Integer): Revision ID = 0
Arg2 (Integer): Function Index = 1
Arg3 (Package): Arguments = Empty Package
Rückgabewert:
Typ: Ganze Zahl
Beschreibung des Rückgabewertes:
0: Erfolg
1: Allgemeiner Fehler
Funktionsverhalten:
Diese Funktion weist das System an, die Statusregister im TPM 2.0-Gerätesteuerungsbereich zu überprüfen und die entsprechenden Maßnahmen zu ergreifen, um den TPM 2.0-Befehl auszuführen oder abzubrechen.
Die Funktion ist nicht blockierend. Der Anruf kommt sofort zurück. (Versuchen Sie nicht, die Befehlsausführung innerhalb der ACPI-Methode auszuführen. AML-Aufrufe müssen kurz sein.) Wenn der Rückgabewert 0 zurückgegeben wird, wurde der gesendete Befehl akzeptiert und wird von der Firmware ausgeführt oder abgebrochen, wenn das Feld Abbrechen bereits festgelegt ist. Wenn möglich, sollte das System eine TPM-Antwort anstelle eines allgemeinen Fehlers von diesem Aufruf zurückgeben. Beispielsweise kann ein Befehl jetzt nicht verarbeitet werden, ein Antwortpuffer von TPM2_RC_RETRY könnte geschrieben werden und das START-Feld könnte gelöscht werden. Wenn der Befehl abgebrochen wurde, weil das Abbrechen-Feld festgelegt wurde, kann diese Methode einen TPM2_RC_Cancelled-Rückgabecode in den Antwortpuffer schreiben, das Start-Feld löschen und einen Wert von 0 zurückgeben. Wenn das Feld Abbrechen festgelegt ist, kann die Methode alternativ einen Wert von 0 zurückgeben, und das TPM 2.0-Gerät kann den Befehl später gemäß den Anforderungen zum Abbrechen eines Befehls abschließen oder abbrechen.
Wenn der Rückgabewert 1 zurückgegeben wird, kann die Firmware die Anforderung nicht lesen oder darauf reagieren. Abgesehen vom Rückgabewert entspricht die Anfrage einem NO-OP. Beispiele sind (a) ein fehlerhafter Betriebssystemtreiber fordert die Ausführung zusätzlicher Befehle an, bevor ein vorheriger Befehl abgeschlossen ist, (b) der Steuerbereich befindet sich nicht im physischen Speicher [möglicherweise aufgrund einer Speicherbeschädigung] oder (c) die physischen Adressen des Befehls oder der Antwort tun dies nicht existieren. Ein Rückgabewert von 1 kann dazu führen, dass der Windows TPM 2.0-Treiber die Verwendung des TPM 2.0-Geräts bis zum nächsten vollständigen Systemstart einstellt (dies schließt Ruhezustands-/Wiederaufnahmezyklen aus).
Hinweis: Sobald die Befehlsausführung beginnt, wird diese Methode kein zweites Mal aufgerufen, wenn das Betriebssystem den aktuell ausgeführten Befehl abbricht. (Es ist jedoch möglich, dass die Steuermethode zunächst für einen Befehl aufgerufen wird, während das Abbruchfeld gesetzt ist.)
4.4 TPM2 Statische ACPI-Tabelle
Eine ACPI-Tabelle mit dem Namen „TPM2“, die in der ACPI-Tabelle „RSDT“ aufgeführt ist, beschreibt die TPM 2.0-Hardwareschnittstelle der Plattform. Der Windows TPM 2.0-Treiber verwendet diese Tabelle, um die Art und Weise zu bestimmen, in der er mit dem TPM 2.0-Gerät kommunizieren soll. Die zur Unterstützung dieser Schnittstelle erforderlichen Parameter in der ACPI-Tabelle sind in der folgenden Tabelle dargestellt.
Tabelle 3: TPM2-ACPI-Tabellenlayout
Feld |
Byte-Länge |
Byteoffset |
BESCHREIBUNG |
||||||||||||||
Header |
|||||||||||||||||
Signatur |
4 |
00h |
'TPM2'. Signatur für die Hardwareschnittstellentabelle des TPM 2.0-Geräts |
||||||||||||||
Länge |
4 |
04h |
Die Länge der Tabelle in Byte, einschließlich Header, beginnend bei Offset 0. Dieses Feld wird verwendet, um die Größe der gesamten Tabelle aufzuzeichnen. |
||||||||||||||
Revision |
1 |
08h |
Überarbeitung dieser Tabelle einschließlich der darin referenzierten Daten und Strukturen. Wenn sich eine Struktur, auf die hier verwiesen wird, geändert hat (z. B. Kontrollbereich), MUSS sich diese Revision ändern. Wert 03h. |
||||||||||||||
Checksum |
1 |
09h |
Die gesamte Tabelle, einschließlich des Prüfsummenfelds, MUSS zu Null hinzugefügt werden, um als gültig betrachtet zu werden. |
||||||||||||||
OEM ID |
6 |
0Ah |
OEM-ID gemäß ACPI-Spezifikation. Eine vom OEM bereitgestellte Zeichenfolge, die den OEM identifiziert (dies kann der Chipsatzanbieter sein). |
||||||||||||||
OEM-Tabellen-ID |
8 |
10h |
Die OEM-Tabellen-ID ist die Modell-ID des Herstellers (zugewiesen durch den durch "OEM-ID" identifizierten OEM; kann der Chipsatz-Anbieter sein). |
||||||||||||||
OEM Revision |
4 |
18h |
OEM-Revision für die angegebene OEM-Tabellen-ID. Gemäß ACPI „[eine] vom OEM bereitgestellte Revisionsnummer. Größere Zahlen werden als neuere Revisionen angesehen." |
||||||||||||||
Ersteller-ID |
4 |
1Ch |
Anbieter-ID des Dienstprogramms, das die Tabelle erstellt hat. Für die Tabellen, die Definitionsblöcke enthalten, ist dies die ID des ASL-Compilers. |
||||||||||||||
Ersteller-Revision |
4 |
20h |
Revision des Dienstprogramms, das die Tabelle erstellt hat. Für die Tabellen, die Definitionsblöcke enthalten, ist dies die Revision des ASL-Compilers. |
||||||||||||||
Flags |
4 |
24h |
Reserviert MUSS immer Null sein |
||||||||||||||
Adresse des Kontrollbereichs |
8 |
28h |
Physische Adresse des Kontrollbereichs. Kann sich entweder im TPM 2.0-Gerätespeicher oder im Arbeitsspeicher befinden, der vom System während des Startvorgangs reserviert wird. Der TPM 2.0-Treiber behält die Kenntnis dieser Adresse während eines Startzyklus, einschließlich Ruhezustand und Wiederaufnahmezyklen. Wenn das System den Kontrollbereich nicht verwendet, MUSS dieser Wert aus lauter Nullen bestehen. |
||||||||||||||
Start-Methode |
4 |
30h |
Die Startmethodenauswahl bestimmt, welchen Mechanismus der Windows TPM 2.0-Treiber verwendet, um TPM 2.0-Befehle an das Gerät zu übermitteln und das TPM 2.0-Gerät zu benachrichtigen, dass ein Befehl zur Verarbeitung verfügbar ist. Dieses Feld kann einen der folgenden Werte enthalten:
|
||||||||||||||
Plattformspezifische Parameter |
-Variable |
34h |
Der Inhalt der plattformspezifischen Parameter wird durch den Startmechanismus bestimmt, der von der TPM 2.0-Geräteschnittstelle dieses Systems verwendet wird. Dieses Feld enthält Werte, die verwendet werden können, um die Befehlsverarbeitung einzuleiten. Diese Informationen können herstellerspezifisch sein. Für Startmethodenwerte von 2 oder 6 wird das Feld nicht verwendet und die Bytelänge ist Null. |
4.4.1 Inhalte des Kontrollbereichs
Die Steuerbereichsstruktur enthält Statusfelder sowie andere Steuerbits/-felder und eine oder mehrere Adressen. Der Steuerbereich enthält die physikalische Adresse des Befehlspuffers und die physikalische Adresse des Antwortpuffers.
Nicht alle TPM 2.0-Schnittstellenimplementierungen verwenden den Kontrollbereich, z. B. verwendet ein Startmethodenwert von 6 den Kontrollbereich nicht, und die Informationen in diesem Abschnitt gelten nicht für die Plattform.
Der Steuerbereich MUSS sich im ACPI AddressRangeReserved-Speicher befinden.
Die Struktur des Steuerbereichs ist in der folgenden Tabelle dargestellt, und sofern nicht anders angegeben, erfolgen alle Zugriffe auf den Steuerbereich im Little-Endian-Format.
Tabelle 4: Layout des Kontrollbereichs
|
Feld |
Byte-Länge |
Offset |
Beschreibung |
Statusfelder |
TPM 2.0-Statusfelder |
||
Reserviert |
4 |
00h |
Reserviert. (MUSS Null sein.) |
Fehler |
4 |
04h |
SET von TPM 2.0, um eine Fehlerbedingung anzuzeigen |
Abbrechen |
4 |
08h |
SET durch den TREIBER, um die Befehlsverarbeitung abzubrechen |
Start |
4 |
0Ch |
SET durch den TREIBER, um anzuzeigen, dass ein Befehl zur Verarbeitung verfügbar ist. |
Interrupt-Steuerelement |
8 |
10h |
Reserviert. (MUSS Null sein.) |
Befehlsgröße |
4 |
18h |
Größe des Befehlspuffers |
Befehl |
8 |
1Ch |
Dieses Feld enthält die physikalische Adresse des Befehlspuffers. Beachten Sie, dass der tatsächliche Befehlspuffer (nicht die physische Adresse des Befehlspuffers) im Big-Endian-Format vorliegt, wie von TCG vorgeschrieben. |
Antwortgröße |
4 |
24h |
Größe des Antwortpuffers |
Antwort |
8 |
28h |
Dieses Feld enthält die physikalische Adresse des Antwortpuffers. Beachten Sie, dass der tatsächliche Antwortpuffer (nicht die physische Adresse des Antwortpuffers) im Big-Endian-Format vorliegt, wie von TCG vorgeschrieben. |
Der TPM 2.0-Treiber liest die folgenden Informationen einmalig während der Initialisierung des Betriebssystems:
Die physische Adresse des Steuerbereichs
Die Größe des Befehlspuffers
Der physische Speicherort des Befehlspuffers
Die Größe des Antwortpuffers
Die physische Position des Antwortpuffers
Für Systeme, die den Kontrollbereich verwenden (d. h. der Wert der Startmethode ist nicht gleich 6) und den Ruhezustand und die Wiederaufnahme unterstützen, MÜSSEN die fünf obigen Werte über die Ruhezustands- und Wiederaufnahmezyklen hinweg konstant bleiben.
4.4.1.1 Fehler
Das TPM 2.0-Gerät kann diesen Status SETZEN. Er darf diesen Status nur schreiben, wenn Start SET ist. Unmittelbar nachdem das TPM 2.0-Gerät diesen Status festgelegt hat, löscht es den Startwert. Der Windows TPM 2.0-Treiber liest das Fehlerfeld nur, wenn das Startfeld CLEAR ist.
Ein SET-Wert des Fehlerfelds wird als allgemeiner Fehler des TPM 2,0-Geräts oder seiner Hardwareschnittstelle behandelt. Jeder SET-Wert führt zum Abbruch des aktuellen Befehls. Der Befehl MUSS zurückgesetzt werden, damit das TPM 2.0-Gerät in einem konsistenten Zustand verbleibt.
Bei einem Gerät mit einer ACPI-Startmethode sollte dieses Feld nur für Fehler verwendet werden, für die kein Antwortcode bereitgestellt werden kann. Ein Beispiel ist: Der Antwortpuffer befindet sich nicht im physischen Speicher. Der Windows TPM 2.0-Treiber beendet möglicherweise die Verwendung des TPM 2.0-Geräts, wenn dieses Feld SET ist.
Der Anfangswert für dieses Feld nach ExitBootServices MUSS widerspiegeln, ob das Gerät funktioniert oder nicht.
4.4.1.2 Abbrechen
Der Windows TPM 2.0-Treiber kann dieses Feld SETZEN, um anzufordern, dass die TPM 2.0-Geräteverarbeitung des aktuellen Befehls beendet wird. Der Windows TPM 2.0-Treiber ruft die Start-Methode nicht auf, um die Verarbeitung der Abbruchanforderung zu initiieren.
Wenn Cancel vom Windows TPM 2.0-Treiber festgelegt wird und das TPM 2.0-Gerät einen Befehl verarbeitet, stoppt das TPM 2.0-Gerät die Verarbeitung des aktuellen Befehls zum frühestmöglichen Zeitpunkt. Bei den meisten Befehlen wird erwartet, dass das TPM 2.0-Gerät den Befehl abschließt und eine normale Antwort bereitstellt. Bei Befehlen, die lange ausgeführt werden (z. B. Generierung von RSA-Schlüsseln), kann das TPM 2.0-Gerät mit TPM_RC_CANCELLED beendet werden. Das TPM 2.0-Gerät muss den Befehl innerhalb von 90 Sekunden entweder abschließen oder abbrechen. (Im Allgemeinen sollten die meisten TPM 2.0-Befehle in weniger als 500 ms abgeschlossen sein, mit Ausnahme von Befehlen zur Generierung von RSA-Schlüsseln, die länger dauern können, und der Befehlsabbruch sollte innerhalb von 200 ms erfolgen.)
Der Windows TPM 2.0-Treiber kann diesen Wert LÖSCHEN, wenn das Startfeld LÖSCHEN ist. Der Anfangswert für dieses Feld nach ExitBootServices MUSS CLEAR sein.
4.4.1.3 Start
Der Windows TPM 2.0-Treiber kann diesen Status SETZEN, um anzuzeigen, dass ein neuer Befehl in den Befehlspuffer gestellt wurde. Der Windows TPM 2.0-Treiber kann die Start-Methode aufrufen, um die Verarbeitung des Befehls zu initiieren. Das TPM 2.0-Gerät löscht diesen Status, wenn es die Verarbeitung eines Befehls abschließt.
Der Windows TPM 2.0-Treiber kann diesen Status LÖSCHEN, wenn der Start-Methodenaufruf fehlgeschlagen ist.
Der Anfangswert für dieses Feld nach ExitBootServices MUSS CLEAR sein.
4.4.1.4 Befehl
Dies ist die physische Adresse, an die der Windows TPM 2.0-Treiber den auszuführenden Befehl schreibt. Der Windows TPM 2.0-Treiber schreibt niemals einen Befehl, der größer als „Befehlsgröße“ ist.
Der Windows TPM 2.0-Treiber DARF NICHT in diesen Speicherbereich schreiben, es sei denn, das Startfeld ist CLEAR. Beachten Sie, dass die Adresse im Steuerbereich im Little-Endian-Format angegeben ist, der tatsächliche Befehlspuffer jedoch im Big-Endian-Format ist, wie von TCG vorgeschrieben.
4.4.1.5 Antwort
Dies ist die physische Adresse, von der der Windows TPM 2.0-Treiber Befehlsantworten liest. Der Windows TPM 2.0-Treiber liest niemals eine Antwort, die größer als „Response Size“ ist.
Der Windows TPM 2.0-Treiber liest nur eine Antwort, nachdem das Startfeld von SET auf CLEAR geändert wurde und Error CLEAR ist. Beachten Sie, dass die Adresse im Steuerbereich im Little-Endian-Format angegeben ist, der tatsächliche Antwortpuffer jedoch im Big-Endian-Format ist, wie von TCG vorgeschrieben.
4.5 Definition der Steuerbereichsschnittstelle
Für Hardwareplattformen, die den Kontrollbereich als TPM 2.0-Schnittstelle verwenden, beschreiben dieser Abschnitt und die Informationen in Abschnitt 4.4 die Interaktion des TPM 2.0-Treibers mit der Hardware. Ein Beispiel für ein System, das den Kontrollbereich verwendet, ist ein System mit einem Startmethodewert von 2 in der TPM2-Tabelle.
4.5.1 Zustandskombinationen
Tabelle 5 beschreibt das erwartete Verhalten für Änderungen, die vom Windows TPM 2.0-Treiber vorgenommen werden. Bitte beachten Sie, dass nur einige Kombinationen erlaubt sind. Es werden nur die erlaubten Kombinationen und Änderungen dokumentiert. Alle anderen Kombinationen sind ungültig. Feldänderungen ohne Aktion durch den Windows TPM 2.0-Treiber bedeuten, dass das TPM 2.0-Gerät oder die ACPI-Startmethode die Felder geändert hat.
Mit '0' markierte Zustände zeigen an, dass dieses Feld CLEAR ist. Mit '1' markierte Zustände zeigen an, dass dieses Feld GESETZT ist. Mit '?' geben an, dass der Wert dieses Felds entweder CLEAR oder SET sein kann. Die Statusfelder sind abgekürzt mit: 'ERR' - Fehler, 'CCL' - Abbrechen und 'STR' - Start. Ein Feld kann entweder vom Windows TPM 2.0-Treiber oder von der TPM 2.0-Geräteschnittstelle geschrieben werden, was in der Aktionsspalte detailliert beschrieben wird.
|--- |
Gegenwärtiger Zustand |
---| |
|--- |
Feld geschrieben |
---| |
|--- |
Nächster Staat |
---| |
Von der TPM 2.0-Geräteschnittstelle durchgeführte Aktion |
|
# |
ERR |
CCL |
STR |
ERR |
CCL |
STR |
ERR |
CCL |
STR |
|
1 |
0 |
1 |
0 |
- |
0 |
- |
0 |
0 |
0 |
Der Windows TPM 2.0-Treiber löscht den Cancel-Wert, um den Kontrollbereich für den nächsten Befehl vorzubereiten. Der Windows TPM 2.0-Treiber kann den Cancel-Wert nur löschen, wenn START CLEAR ist. (Das TPM 2.0-Gerät DARF NICHT in das Abbrechen-Feld schreiben.) |
2 |
0 |
0 |
0 |
- |
- |
1 |
0 |
0 |
1 |
Der Windows TPM 2.0-Treiber legt den Startwert fest, um anzugeben, dass ein Befehl im Befehlsbereich vorhanden ist. Der Windows TPM 2.0-Treiber kann die ACPI-Startmethode aufrufen, um die Ausführung des Befehls zu initiieren. Nach Abschluss der ACPI-Startmethode MUSS das TPM 2.0-Gerät Befehle ausführen und das Startfeld innerhalb von 90 Sekunden löschen. Das Überschreiten des Zeitlimits kann dazu führen, dass der Windows TPM 2.0-Treiber davon ausgeht, dass das TPM 2.0-Gerät blockiert ist. |
3 |
0 |
? |
1 |
- |
- |
0 |
0 |
? |
0 |
Das TPM 2.0-Gerät löscht das Startfeld, wenn es die Verarbeitung des Befehls beendet oder den Befehl abbricht. Wenn der Befehl abgebrochen wurde, wird eine Antwort mit dem Rückkehrcode TPM_RC_CANCELLED in den Antwortpuffer gestellt und Start wird gelöscht. Der Windows TPM 2.0-Treiber liest möglicherweise den Antwortpuffer, während das Startfeld CLEAR ist. Der Windows TPM 2.0-Treiber darf den Antwortpuffer NICHT lesen, während das Startfeld SET ist. |
4 |
0 |
0 |
1 |
- |
1 |
- |
0 |
1 |
1 |
Der Windows TPM 2.0-Treiber SETs Cancel, um anzugeben, dass das TPM 2.0-Gerät den aktuellen Befehl abbrechen soll. Im Allgemeinen sollten lange laufende Befehle an der nächsten geeigneten Stelle abgebrochen werden. Kurz laufende Befehle können abgeschlossen werden. Insbesondere muss das TPM 2.0-Gerät das Feld Start innerhalb von 90 Sekunden löschen, nachdem das Feld Abbrechen gesetzt wurde. (Ein gutes Leistungsziel sind 200 ms statt 90 Sekunden.) Hinweis: Es ist möglich, dass das Abbrechen-Feld gesetzt wird, wenn die ACPI-Startmethode aufgerufen wird, weil ein Thread innerhalb des Betriebssystems das Abbrechen-Feld setzen kann, bevor ein anderer Thread die ACPI-Startmethode aufruft . |
5 |
0 |
? |
1 |
1 |
- |
- |
1 |
? |
1 |
Das TPM 2.0-Gerät zeigt einen Fehlerzustand im Gerät an. Der Zustand des TPM 2.0-Geräts ist so, als ob die Befehlsausführung nie begonnen hätte. Der Windows TPM 2.0-Treiber behandelt diesen Wert als allgemeinen Fehler des TPM 2.0-Geräts und bricht die Verarbeitung des Befehls ab. |
6 |
1 |
? |
1 |
- |
- |
0 |
1 |
? |
0 |
Das TPM 2.0-Gerät löscht das Startfeld unmittelbar nach dem Festlegen des Fehlerfelds. Der Windows TPM 2.0-Treiber überprüft das Fehlerfeld nur, wenn das Startfeld KLAR ist oder wenn die Befehlsausführung oder der Abbruch nicht innerhalb des erforderlichen Zeitfensters erfolgt. Der Windows TPM 2.0-Treiber beendet möglicherweise die Verwendung des TPM 2.0-Geräts, wenn das Fehlerfeld SET ist. |
4.5.2 Zustandsdiagramm bei Verwendung der ACPI-Startmethode
Dieses Zustandsdiagramm dient nur zu Informationszwecken. Die normative Beschreibung des Verhaltens ist der Text in den vorangegangenen Abschnitten. Bei fehlenden oder unklaren Zustandsübergängen konsultieren Sie bitte den obigen Text.
Abbildung 1: TPM 2.0-Gerätezustände bei Verwendung der ACPI-Startmethode
Hinweis
(a) Bitte beachten Sie, dass mehrere gleichzeitige Threads gleichzeitig mit dem Kontrollbereich interagieren können. Zum Beispiel: Ein Thread könnte einen Befehl initiieren, indem er das Start-Feld setzt und dann die Start-Methode ausgibt. Ein anderer Thread kann parallel das Cancel-Feld setzen. Daher besteht die Möglichkeit, das Abbrechen-Feld nach dem Setzen des Start-Felds setzen zu lassen, aber bevor die Start-Methode ausgegeben wird. (b) Ein Windows TPM 2.0-Treiber kann auf Fehlerbedingungen anders als dargestellt reagieren. Es könnte beispielsweise in einen Fehlerzustand übergehen, wenn eine Zeitüberschreitung eintritt.
4.5.3 Zustandsdiagramm ohne ACPI-Startmethode
Dieses Zustandsdiagramm dient nur zu Informationszwecken. Die normative Beschreibung des Verhaltens ist der Text in den vorangegangenen Abschnitten. Wenn Zustandsübergänge fehlen oder nicht eindeutig sind, konsultieren Sie bitte den obigen Text.
Abbildung 2: TPM 2.0-Gerätezustände ohne ACPI-Startmethode
4.6 Speicherabgebildete E/A-Schnittstelle
Für Hardwareplattformen, die die Memory Mapped I/O-Schnittstelle verwenden, beschreiben dieser Abschnitt und die Informationen in Abschnitt 4.4 die Interaktion des TPM 2.0-Treibers mit der Hardware. Ein Beispiel für ein System, das die speicherabgebildete E/A-Schnittstelle verwendet, ist ein System mit einem Startmethodewert von 6 in der TPM2-Tabelle.
4.6.1 Anforderungen an die TCG-TPM-Schnittstellenspezifikation
Das System MUSS die TPM 1.2-Hardwareschnittstellenanforderungen in [TCG12] für die folgenden Abschnitte erfüllen:
Abschnitt 9.1: TPM-Lokalitätsebenen
Abschnitt 9.2: Lokale Verwendungen
Abschnitt 9.3: Ortsnutzung nach einem Register
Abschnitt 10: TPM-Registerplatz
Abschnitt 11: Systeminteraktion und -flüsse
Außer: Alle in Abschnitt 11.2.4 Fehlermodus
Außer Abschnitt 11.2.5: Befehlsdauer, Normelement 2
Außer Alle in Abschnitt 11.2.6: Zeitüberschreitungen
Außer dem gesamten Abschnitt 11.2.8: Selbsttest und frühe Plattforminitialisierung
Außer Alle in Abschnitt 11.2.9: Input Buffer Size
Außer Abschnitt 11.2.10: Fehler, normative Punkte 2c und 3.
Abschnitt 13: TPM-Hardwareprotokoll
Für zukünftige Entwurfsspezifikationen von [TCG12] wenden Sie sich bitte an Microsoft.
4.6.2 Unterstützung für das Abbrechen eines Befehls
Windows erfordert, dass das TPM 2.0-Gerät das Abbrechen eines TPM 2.0-Befehls mithilfe der speicherabgebildeten E/A-Schnittstelle zulässt, indem es das unten beschriebene Verhalten zeigt.
Das zuvor unbenutzte Bit 24 des STS-Registers ist als nur beschreibbar definiert und wird als commandCancel bezeichnet.
Ein Schreiben von '1' an commandCancel während der Befehlsausführungsphase KANN den aktuell ausgeführten Befehl abbrechen und eine Antwort MUSS zurückgegeben werden. Die Antwort gibt an, ob der Befehl abgebrochen (keine TPM 2.0-Statusänderung, aber ein Abbruchantwortcode TPM_RC_CANCELLED wird zurückgegeben) oder abgeschlossen wurde (eine reguläre TPM 2.0-Antwort wird zurückgegeben, die das Ergebnis des Befehls angibt). Schreibvorgänge in das commandCancel-Register, wenn sich das TPM nicht im Befehlsausführungszustand befindet, MÜSSEN ignoriert werden.
4.6.3 Zusätzliche Anforderungen
Alle TPM-Befehle MÜSSEN innerhalb von maximal 90 Sekunden abgeschlossen werden.
Wenn der TPM 2.0-Treiber das Abbrechen eines Befehls anfordert, muss er innerhalb von 90 Sekunden abgeschlossen oder abgebrochen werden.
Folgende TIMEOUT-Werte MÜSSEN implementiert werden: TIMEOUT_A = 1 Sekunde, TIMEOUT_B = 2 Sekunden, TIMEOUT_C = 1 Sekunde, TIMEOUT_D = 1 Sekunde.
Die minimale Eingabepuffergröße MUSS 0x500 (oder größer) sein.
5.0 Referenzen
[ACPI09] |
„Erweiterte Konfigurations- und Leistungsschnittstellenspezifikation“, Version 4.0, 16. Juni 2009. |
[TCG08] |
Trusted Computing Group, „TCG Platform Reset Attack Mitigation Specification“, Version 1.0, 15. Mai 2008. |
[TCG11] |
Trusted Computing Group, „TCG Physical Presence Interface Specification“, Version 1.20, 10. Februar 2011. |
[TCG12] |
Trusted Computing Group, „PC Client Work Group PC Client Specific TPM Interface Specification (TIS) Version 1.21, Revision 1.00. |