Trusted Execution Environment ACPI Profile

A typical usage scenario is as follows:

1. Within the OS environment, an application detects the TPM 2.0 device is not fully provisioned for use for Windows 8. (An example of how this could happen is if a new OS image is installed after a previous OS image provisioned the TPM 2.0.)
   
   
2. The application launches an OS wizard to ready the TPM 2.0 device for use.
   
   
3. The wizard interacts with the computer administrator via UI and determines the administrator needs to clear the TPM 2.0 device to provision it because the TPM 2.0 device reset lockout authorization value is not available.
   
   
4. To clear the TPM 2.0 device, the OS requests (by executing an ACPI control method for the TPM 2.0 device object) the firmware perform the operation to clear the TPM 2.0 device upon the next boot provided a physically present user confirms they approve of clearing the TPM 2.0 device.
   
   
5. The OS restarts the platform.
   
   
6. During the early portion of the boot process, the firmware recognizes the pending request from the OS to clear the TPM 2.0 device.
   
   
7. The firmware presents a UI to a physically present user asking them to take some action to confirm clearing of the TPM 2.0 device.
   
   
8. A physically present user confirms clearing of the TPM 2.0 device.
   
   
9. The firmware clears the TPM 2.0 device using the platform hierarchy authorization.
   
   
10. If necessary, to persist the clearing of the TPM 2.0 device, the platform is rebooted immediately.
    
    
11. The OS boots.
    
    
12. The OS queries (via an ACPI control method on the TPM 2.0 device) if the last OS request to clear the TPM 2.0 device was either (a) successful, (b) was not confirmed by the physically present user or (c) had some other error. In the following, we assume the TPM 2.0 device was cleared successfully.
    
    
13. The TPM 2.0 device provisioning wizard within the OS performs additional commands to ready the device for use by Windows.
    
    

This scenario illustrates how the memory clear feature of the system helps thwart attacks that harvest system memory for key material after the platform is unexpectedly restarted.

1. From within the OS, an administrator on a system with a TPM 2.0 device turns on the BitLocker feature for the OS volume.
   
   
2. The BitLocker feature calls the TPM 2.0 device ACPI control method to set the ClearMemory bit defined in the TCG Platform Reset Attack Mitigation Specification.
   
   
3. The BitLocker feature encrypts the OS volume.
   
   
4. The administrator leaves the system unattended with the screen locked.
   
   
5. A malicious person steals the system while it is running.
   
   
6. The malicious person inserts a USB stick and quickly removes the system battery and re-inserts it.
   
   
7. The system starts booting when the battery is re-inserted.
   
   
8. Because the ClearMemory bit was set previously the firmware clears the entire system memory before launching any code not provided by the platform manufacturer.
   
   
9. The malicious person configures the firmware during boot to boot to the USB device even though the code on the USB device is not properly signed.
   
   
10. The code on the USB device scans the system memory for the BitLocker Volume Master Key but it is not found.
    
    

    Warning
    Steps 11 through 16 are similar to the earlier steps, but use the UEFI interface instead of ACPI

11. The malicious person attempts to boot the system normally.
    
    
12. Because BitLocker was enabled with the TPM key protector, this permits BootMgr to “unseal” the volume master key for the OS volume because the correct measurements are in the TPM 2.0 device when BootMgr runs.
    
    
13. Boot proceeds to the OS logon screen.
    
    
14. The malicious person again removes then re-inserts the battery and boots code from a USB device.
    
    
15. Because the ClearMemory bit was set, the system firmware erases the entire system memory during boot.
    
    
16. Even though code from the USB device scans the system memory, the OS volume encryption key is not in memory.
    
    

This example is not applicable for all system architectures.

1. The Windows TPM 2.0 driver wants to issue a command to the TPM 2.0 device.
   
   
2. The Windows TPM 2.0 driver writes the command to execute to the physical address read from the ACPI-defined Control Area earlier during the Windows TPM 2.0 driver initialization.
   
   
3. The Windows TPM 2.0 driver executes the ACPI control method to execute a TPM 2.0 command.
   
   
4. The Windows TPM 2.0 driver polls the registers in the control area until they indicate the TPM command has completed.
   
   
5. The Windows TPM driver reads the command response from the physical address read from the ACPI-defined Control Area earlier during Windows TPM driver initialization.
   
   

ACPI D1/D2

The TPM 2.0 device MAY support ACPI D1 and/or ACPI D2 but MUST behave as if it was in power state ACPI D0 while in D1 or D2.

ACPI S3 (Sleep)

The TPM 2.0 MAY support S3 but entry into and exit from the S3 low power state for the device MUST be controlled by the system/platform manufacturer.

The OS (or other software running in the OS environment) MUST NOT be able to place the TPM 2.0 device in S3 or cause the TPM 2.0 device to exit from S3. For example, if the TPM 2.0 device is on a bus, the OS MUST NOT be able to power down the bus causing the TPM 2.0 device to enter S3.

The Windows 8 TPM driver will attempt to issue a TPM2_Shutdown command prior to entering S3 (sleep).

If a hardware platform does support S3 and the TPM does not retain its state while the system is in S3, the platform MUST issue the necessary TPM2_Init and TPM2_Startup(TPM_SU_STATE) commands during S3 resume. It is possible the OS may not have completed the TPM2_Shutdown command prior to entry into S3. This could cause the return result of TPM2_Startup(TPM_SU_STATE) to return an error. The system firmware that resumes from S3 MUST deal with a TPM2_Startup error appropriately. For example, by either disabling access to the TPM via hardware, issuing a TPM2_Startup(TPM_SU_CLEAR) command and configuring the device securely by taking actions like extending a separator with an error digest (0x01) into PCRs 0 through 7 and locking NV indices.

The system MUST account for time elapsed during S3 by decrementing TPM dictionary attack failure count (TPM_PT_LOCKOUT_COUNTER) for the time the system was in S3 per the lockout interval (TPM_PT_LOCKOUT_INTERVAL). This may require a platform implementation to provide standby voltage to retain TPM clock and/or state during S3 or a platform could also securely provide information regarding how much time elapsed while the system was in a low power state so the TPM can reliably updates its authorization failure count for its dictionary attack logic.

Low Power States for Connected Standby Systems

Windows 8 does not perform any additional actions associated with the TPM upon entry and exit from low power states for Connected Standby systems. The platform MUST performing any actions needed for the TPM to behave as though it was in D0 whenever the system enters and exits from low power states for Connected Standby systems. This MAY require a platform implementation to provide standby voltage to power the TPM clock and/or retain state. Alternatively, a platform MAY need to securely provide information regarding how much time elapsed while the system was in a low power state to the TPM, so the TPM can reliably updates its authorization failure count for its dictionary attack logic.

System Off

The system SHOULD securely account for time elapsed during full shutdown by decrementing TPM dictionary attack failure count (TPM_PT_LOCKOUT_COUNTER) for the time the system was in S5 per the lockout interval (TPM_PT_LOCKOUT_INTERVAL).

A system with a TPM 2.0 device MUST provide a device object table with a hardware device ID and an OS vendor specific static table (TPM2) as described below.

Both the TPM2 table and the TPM 2.0 device object MUST be persistent once the platform is shipped to a customer. (E.g. Firmware options MUST NOT permit hiding of the TPM2 table or the TPM 2.0 device object.) An exception is if a system is shipped with a non-default option to provide TPM 1.2 functionality instead of TPM 2.0 functionality (i.e. for compatibility with older operating systems like Windows 7.) In this situation the TPM2 table and the TPM 2.0 device object MAY be removed via a BIOS configuration option and enumeration of a TPM 1.2 performed. Note: A Connected Standby System for Windows 8 is required to ship, by default, with a TPM 2.0 visible to the operating system. Please contact Microsoft for technical guidance about switching between a TPM 2.0 and TPM 1.2 on a hardware platform.

4.3.1 Bus Hierarchy

The Device Object table MUST be under the DSDT table in the ACPI namespace.The TPM 2.0 Device Object MUST be located under the system bus at “root\_SB”.

4.3.2 Hardware Identifier

The actual plug and play hardware identifier (e.g. _HID) for the TPM 2.0 device object MUST be “MSFT0101”or the device MUST have a compatible ID of “MSFT0101” and the _HID could be vendor specific.

4.3.3 Resource Descriptors

The ACPI TPM 2.0 Device Object MUST claim all resources used by the TPM 2.0 device.

4.3.4 Control Methods

4.3.4.1 Platform Reset Attack Mitigation

The system MUST implement all ACPI and UEFI related parts of [TCG08] for UEFI. The device object MUST implement the control method interface defined in [TCG08], section 6. The interface is required even if the platform unconditionally clears memory on every boot. The clearing of memory MUST NOT be conditional on the TPM 2.0 device state (in contrast [TCG08] does not requiring clearing of memory if the TPM 1.2 is not owned). Also, sections 3, 5 of [TCG08] MUST be implemented. The _DSM query function MUST be implemented (function index 0) per the ACPI specification. (Note: There is a mistake in the ACPI 4.0 specification about the return value for the _DSM method. The return value of the _DSM method should be a buffer containing 0x03.) The implementation MUST auto-detect an orderly OS shutdown and clear the ClearMemory bit on such events.

Special note for UEFI based ARM systems with a TPM 2.0: On UEFI based ARM systems with a TPM 2.0, Windows 8 will unconditionally request memory be cleared using the UEFI interface on every boot. Implementing the ACPI interface is still required, but the interface MAY be implemented to not change the state of the ClearMemory or DisableAutoDetect flags. (Note: Microsoft recommends the ACPI interface be implemented per the TCG specification so calling the ACPI interface does change the state of ClearMemory or DisableAutoDetect.)

4.3.4.2 Physical Presence Interface

The system MUST implement the specification defined in [TCG11] per the additional notes below:

1. The use of TPM in the TCG specification should be equated with the TPM 2.0 device.
   
   
2. The control methods defined in section 2 MUST be implemented with the following restrictions:
   
   
   1. The _DSM query function MUST be implemented (function index 0) per the ACPI specification. (Note: There is a mistake in the ACPI 4.0 specification about the return value for the _DSM method. The return value of the _DSM method should be a buffer containing 0x01FF.)
      
      
   2. The implementation MUST return a value of “2: Reboot” for “Get Platform-Specific Action to Transition to Pre-OS Environment.” PPI operations MUST occur for a transition of a restart and SHOULD occur for a shutdown transition.
      
      
   3. Implementation of the following control methods is optional: “Submit TPM Operation Request to Pre-OS Environment” (may return “2: General Failure”) and “Submit preferred user language” (may return “3: Not implemented”).
      
      
3. The requirements in section 3 MUST be implemented with the following revisions:
   
   
   1. The BIOS does not need to provide persistent storage for the NoPPIProvision flag because the operations it authorizes are not relevant for the TPM 2.0 device state.
      
      
   2. Table 2 is revised as follows:
      
      Table 1: revised PPI table 2
      
      

       

      OperationValue	Operation Name	TPM Stat	BIOS TPM Mgmt Flags	Mandatory versus Optional	When Physical Presence Confirmation is Required	May need additional boot cycle
      0	No Operation			M
      1-4	No Operation			M
      5	TPM2_ClearControl(NO) + TPM2_Clear	X		M	NoPPIClear is FALSE	X
      6-11	No Operation			M
      12-13	No Operation			O
      14	TPM2_ClearControl(NO) + TPM2_Clear	X		M	NoPPIClear is FALSE	X
      15-16	No Operation			M
      17	SetNoPPIClear_False		X	O1
      18	SetNoPPIClear_True		X	O1	Always
      19-20	No Operation			O2
      21-22	TPM2_ClearControl(NO) + TPM2_Clear	X		M	NoPPIClear is FALSE	X
      23 – 127	Reserved
      >=128	Vendor Specific	X	X	O		X

      Important
      For SetNoPPIClear_False: if the BIOS implements the items marked “O1” or “O2” it must implement them as a set. For the No Operation that follows SetNoPPIClear_True, the BIOS must not implement operations 19 and 20 if it does not implement operation 12.

   3. Table 3 is revised as follows:
      
      

       

      Operation Value	Operation Name	TPM commands sent by BIOS and other BIOS actions to perform the operation
      0	No Operation	No operation
      1-4, 6-13, 15-16, 19-20	No Operation	No operation. However, the operation number MUST be remembered and the result if queried from the OS it MUST return success.
      5, 14, 21, 22	Clear	TPM2_ClearControl(NO) + TPM2_Clear <PLATFORM RESET>* [*If necessary to persist the TPM changes from TPM2_CLEAR. Microsoft anticipates on most systems this is unnecessary.]
      17	SetNoPPIClear_False (Require physical presence for clear.)	This operation does not change TPM state. Clears the BIOS TPM Management Flag NoPPIClear to FALSE.
      18	SetNoPPIClear_True (Do not require physical presence confirmation for clear.)	This operation does not change TPM state. Sets the BIOS TPM Management Flag NoPPIClear to TRUE.
      23 – 127	Reserved	Reserved, do not implement or use
      >=128	Vendor Specific	TPM commands mapping to vendor specific operation

4. The spirit of section 4 MUST be maintained to obtain confirmation from a physically present user when it is required to perform an operation but the actual mechanism does not need to be key presses. The keys or other mechanism to affirm consent are up to the platform manufacturer.
   
   

    

   Op Value	Operation Name	Confirmation Text
   5, 14, 21, and 22	Clear	A configuration change was requested to clear this computer’s TPM (Trusted Platform Module) WARNING: Clearing erases information stored on the TPM. You will lose all created keys and access to data encrypted by these keys. Press <CAK> to clear the TPM Press <RK> to reject this change request and continue
   18	SetNoPPIClear_True	A configuration change was requested to allow the Operating System to clear the computer’s TPM (Trusted Platform Module) without asking for user confirmation in the future. NOTE: This action does not clear the TPM, but by approving this configuration change, future actions to clear the TPM will not require user confirmation. WARNING: Clearing erases information stored on the TPM. You will lose all created keys and access to data encrypted by these keys. Press <CAK> to approve future Operating System requests to clear the TPM Press <RK> to reject this change request and continue

5. Section 5 is informative.
   
   
6. Connected Standby systems MAY hardcode NoPPIClear to TRUE and not implement operations 17 and 18. This means they do not need to implement any confirmation dialogs for physical presence actions because no physical presence operations will require user confirmation.
   
   
7. The firmware MUST leave the storage and endorsement hierarchies enabled when it passes control to initial program loader code like the Windows Boot Manager.
   
   

4.3.4.3 Optional ACPI Start Method

Note: Some platforms MAY implement this optional ACPI method to permit the OS to request the firmware to execute or cancel a TPM 2.0 command. The use of the ACPI Start method is determined by the StartMethod field of the static ACPI table (see Section 4.4.)If the StartMethod field of the static ACPI table indicates the use of this method, the ACPI Start method MUST be implemented.The ACPI functions defined herein shall reside in the _DSM control method object. [Note: This is not a control method in the TPM2 ACPI table.] The _DSM method defined herein MUST be implemented as follows:

Function Start

Input Arguments:

Arg0 (Buffer): UUID = 6bbf6cab-5463-4714-b7cd-f0203c0368d4
Arg1 (Integer): Revision ID = 0
Arg2 (Integer): Function Index = 1
Arg3 (Package): Arguments = Empty Package

Return Value:

Type: Integer

Description of the Return Value:

0: Success

1: General Failure

Functional Behavior:

This function tells the system to review the status registers in the TPM 2.0 device control area and take the appropriate action to execute or cancel TPM 2.0 command.

The function is non-blocking. The call will return immediately. (Do not attempt to perform command execution from within the ACPI method. AML calls need to be short.)When Return Value 0 is returned, the submitted command was accepted and will be executed by the firmware or cancelled if the Cancel field is already set. Whenever possible the system should return a TPM response instead of a General Failure from this call. For example, a command cannot be processed now, a Response buffer of TPM2_RC_RETRY could be written and the START field could be CLEARed. If the command was cancelled because the Cancel field was set, this method may write a TPM2_RC_Cancelled return code in the Response buffer, clear the Start field and return a value of 0. Alternatively, if the Cancel field is set the method may return a value of 0 and the TPM 2.0 device may later complete or cancel the command per the requirements for cancelling a command.

When Return Value 1 is returned, the firmware is unable to read or act upon the request. Other than the return value, the request is equivalent to a NO-OP. Examples are (a) a bad OS driver requests execution of additional commands before a prior command completed, (b) the control area is not in physical memory [perhaps due to memory corruption], or (c) the command or response physical addresses do not exist. A return value of 1 may cause the Windows TPM 2.0 driver may stop using the TPM 2.0 device until the next full system boot (this excludes hibernation/resume cycles).

Note: Once command execution starts, this method is not called a second time if the OS chooses the cancel the currently executing command. (However it is possible the control method may be called initially for a command while the cancel field is set.)

An ACPI table named “TPM2” listed in the “RSDT” ACPI table describes the platform’s TPM 2.0 hardware interface. The Windows TPM 2.0 driver uses this table to determine the manner in which it is to communicate with the TPM 2.0 device. The parameters in the ACPI table required to support this interface are illustrated in the table below.

Table 3: TPM2 ACPI table layout

4.4.1 Control Area Contents

For hardware platforms that use the Control Area as the TPM 2.0 interface, this section and the information in section 4.4 describes the TPM 2.0 driver interaction with the hardware. An example of a system that uses the Control Area is a system with a Start Method value of 2 in the TPM2 table.

4.5.1 State Combinations

4.5.2 State diagram when using ACPI Start method

This state diagram is for informative purposes only. The normative description of behavior is the text in previous sections. If there are missing or ambiguous state transitions please consult the text above.

Figure 1: TPM 2.0 device states when using ACPI Start method

Note

(a) Please note that multiple concurrent threads can interact with the Control Area concurrently. For example: one thread could initiate a command by setting the Start field and then issuing the Start method. Another thread can set the Cancel field in parallel. Hence, the possibility to have the Cancel field set after setting the Start field, but before issuing the Start method. (b) A Windows TPM 2.0 driver may react to error conditions differently than depicted. It might, for instance, transition into an error state when a timeout hits.

4.5.3 State diagram without an ACPI Start method

This state diagram is for informative purposes only. The normative description of behavior is the text in previous sections. If there are state transitions are missing or ambiguous please consult the text above.

Figure 2: TPM 2.0 device states without ACPI Start method

4.6 Memory Mapped I/O Interface