TCG DRIVERS LIMITED - Free company information from Companies House including registered office address, filing history, accounts, annual return, officers, charges, business activity. TBSLogGenerator.exe dumps PCR values and TCG log in a human-readable format for the boot session when TBSLogGenerator.exe gets run. Repeat the steps that triggers BitLocker recovery. For both boot sessions across BitLocker recovery, use TBSLogGenerator.exe to dump PCR values and TCG logs.


Big G Express signs up for TCG software, driver wins $25k at TCA conference. Randy Vernon, president of Big G Express (left), signs a contract with TCG on the exhibit floor at the TCA conference. TCG Advisory Services, LLC ('TCG Advisors') is a registered investment advisor regulated by the U.S. Securities and Exchange Commission (SEC) subject to the Rules and Regulations of the Investment Advisor Act of 1940, and is a part of TCG Group Holdings, LLP. For a Synchro Summon, you can substitute this card for any 1 'Synchron' Tuner. If this card is Normal Summoned: You can Special Summon 1 'Lefty Driver' from your hand, Deck, or GY. You can only use this effect of 'Righty Driver' once per turn.

Applies to

  • Windows 10
  • Windows Server 2016

This topic provides recommendations for Trusted Platform Module (TPM) technology for Windows 10.

For a basic feature description of TPM, see the Trusted Platform Module Technology Overview.

Union Driver Tcg

TPM design and implementation

Traditionally, TPMs have been discrete chips soldered to a computer’s motherboard. Such implementations allow the computer’s original equipment manufacturer (OEM) to evaluate and certify the TPM separate from the rest of the system. Although discrete TPM implementations are still common, they can be problematic for integrated devices that are small or have low power consumption. Some newer TPM implementations integrate TPM functionality into the same chipset as other platform components while still providing logical separation similar to discrete TPM chips.

TPMs are passive: they receive commands and return responses. To realize the full benefit of a TPM, the OEM must carefully integrate system hardware and firmware with the TPM to send it commands and react to its responses. TPMs were originally designed to provide security and privacy benefits to a platform’s owner and users, but newer versions can provide security and privacy benefits to the system hardware itself. Before it can be used for advanced scenarios, however, a TPM must be provisioned. Windows 10 automatically provisions a TPM, but if the user is planning to reinstall the operating system, he or she may need to clear the TPM before reinstalling so that Windows can take full advantage of the TPM.

The Trusted Computing Group (TCG) is the nonprofit organization that publishes and maintains the TPM specification. The TCG exists to develop, define, and promote vendor-neutral, global industry standards that support a hardware-based root of trust for interoperable trusted computing platforms. The TCG also publishes the TPM specification as the international standard ISO/IEC 11889, using the Publicly Available Specification Submission Process that the Joint Technical Committee 1 defines between the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC).

OEMs implement the TPM as a component in a trusted computing platform, such as a PC, tablet, or phone. Trusted computing platforms use the TPM to support privacy and security scenarios that software alone cannot achieve. For example, software alone cannot reliably report whether malware is present during the system startup process. The close integration between TPM and platform increases the transparency of the startup process and supports evaluating device health by enabling reliable measuring and reporting of the software that starts the device. Implementation of a TPM as part of a trusted computing platform provides a hardware root of trust—that is, it behaves in a trusted way. For example, if a key stored in a TPM has properties that disallow exporting the key, that key truly cannot leave the TPM.

The TCG designed the TPM as a low-cost, mass-market security solution that addresses the requirements of different customer segments. There are variations in the security properties of different TPM implementations just as there are variations in customer and regulatory requirements for different sectors. In public-sector procurement, for example, some governments have clearly defined security requirements for TPMs whereas others do not.

TPM 1.2 vs. 2.0 comparison

From an industry standard, Microsoft has been an industry leader in moving and standardizing on TPM 2.0, which has many key realized benefits across algorithms, crypto, hierarchy, root keys, authorization and NV RAM.

Why TPM 2.0?

TPM 2.0 products and systems have important security advantages over TPM 1.2, including:

  • The TPM 1.2 spec only allows for the use of RSA and the SHA-1 hashing algorithm.

  • For security reasons, some entities are moving away from SHA-1. Notably, NIST has required many federal agencies to move to SHA-256 as of 2014, and technology leaders, including Microsoft and Google have announced they will remove support for SHA-1 based signing or certificates in 2017.

  • TPM 2.0 enables greater crypto agility by being more flexible with respect to cryptographic algorithms.

    • TPM 2.0 supports newer algorithms, which can improve drive signing and key generation performance. For the full list of supported algorithms, see the TCG Algorithm Registry. Some TPMs do not support all algorithms.

    • For the list of algorithms that Windows supports in the platform cryptographic storage provider, see CNG Cryptographic Algorithm Providers.

    • TPM 2.0 achieved ISO standardization (ISO/IEC 11889:2015).

    • Use of TPM 2.0 may help eliminate the need for OEMs to make exception to standard configurations for certain countries and regions.

  • TPM 2.0 offers a more consistent experience across different implementations.

    • TPM 1.2 implementations vary in policy settings. This may result in support issues as lockout policies vary.

    • TPM 2.0 lockout policy is configured by Windows, ensuring a consistent dictionary attack protection guarantee.

  • While TPM 1.2 parts are discrete silicon components which are typically soldered on the motherboard, TPM 2.0 is available as a discrete (dTPM) silicon component in a single semiconductor package, an integrated component incorporated in one or more semiconductor packages - alongside other logic units in the same package(s) - and as a firmware (fTPM) based component running in a trusted execution environment (TEE) on a general purpose SoC.


TPM 2.0 is not supported in Legacy and CSM Modes of the BIOS. Devices with TPM 2.0 must have their BIOS mode configured as Native UEFI only. The Legacy and Compatibility Support Module (CSM) options must be disabled. For added security Enable the Secure Boot feature.

Installed Operating System on hardware in legacy mode will stop the OS from booting when the BIOS mode is changed to UEFI. Use the tool MBR2GPT before changing the BIOS mode which will prepare the OS and the disk to support UEFI.

Discrete, Integrated or Firmware TPM?

There are three implementation options for TPMs:

  • Discrete TPM chip as a separate component in its own semiconductor package

  • Integrated TPM solution, using dedicated hardware integrated into one or more semiconductor packages alongside, but logically separate from, other components

  • Firmware TPM solution, running the TPM in firmware in a Trusted Execution mode of a general purpose computation unit

Windows uses any compatible TPM in the same way. Microsoft does not take a position on which way a TPM should be implemented and there is a wide ecosystem of available TPM solutions which should suit all needs.

Is there any importance for TPM for consumers?

For end consumers, TPM is behind the scenes but is still very relevant. TPM is used for Windows Hello, Windows Hello for Business and in the future, will be a component of many other key security features in Windows. TPM secures the PIN, helps encrypt passwords, and builds on our overall Windows 10 experience story for security as a critical pillar. Using Windows on a system with a TPM enables a deeper and broader level of security coverage.

TPM 2.0 Compliance for Windows 10

Windows 10 for desktop editions (Home, Pro, Enterprise, and Education)

  • Since July 28, 2016, all new device models, lines or series (or if you are updating the hardware configuration of a existing model, line or series with a major update, such as CPU, graphic cards) must implement and enable by default TPM 2.0 (details in section 3.7 of the Minimum hardware requirements page). The requirement to enable TPM 2.0 only applies to the manufacturing of new devices. For TPM recommendations for specific Windows features, see TPM and Windows Features.
TCG Driver

IoT Core

  • TPM is optional on IoT Core.

Windows Server 2016

  • TPM is optional for Windows Server SKUs unless the SKU meets the additional qualification (AQ) criteria for the Host Guardian Services scenario in which case TPM 2.0 is required.

TPM and Windows Features

The following table defines which Windows features require TPM support.

Windows FeaturesTPM RequiredSupports TPM 1.2Supports TPM 2.0Details
Measured BootYesYesYesMeasured Boot requires TPM 1.2 or 2.0 and UEFI Secure Boot
BitLockerNoYesYesTPM 1.2 or 2.0 are supported but TPM 2.0 is recommended. Automatic Device Encryption requires Modern Standby including TPM 2.0 support
Device EncryptionYesN/AYesDevice Encryption requires Modern Standby/Connected Standby certification, which requires TPM 2.0.
Windows Defender Application Control (Device Guard)NoYesYes
Windows Defender System GuardYesNoYes
Credential GuardNoYesYesWindows 10, version 1507 (End of Life as of May 2017) only supported TPM 2.0 for Credential Guard. Beginning with Windows 10, version 1511, TPM 1.2 and 2.0 are supported.
Device Health AttestationYesYesYes
Windows Hello/Windows Hello for BusinessNoYesYesAzure AD join supports both versions of TPM, but requires TPM with keyed-hash message authentication code (HMAC) and Endorsement Key (EK) certificate for key attestation support.
UEFI Secure BootNoYesYes
TPM Platform Crypto Provider Key Storage ProviderYesYesYes
Virtual Smart CardYesYesYes
Certificate storageNoYesYesTPM is only required when the certificate is stored in the TPM.
AutopilotNoN/AYesIf you intend to deploy a scenario which requires TPM (such as white glove and self-deploying mode), then TPM 2.0 and UEFI firmware are required.
SecureBIOYesNoYesTPM 2.0 and UEFI firmware is required.
DRTMYesNoYesTPM 2.0 and UEFI firmware is required.

OEM Status on TPM 2.0 system availability and certified parts

Government customers and enterprise customers in regulated industries may have acquisition standards that require use of common certified TPM parts. As a result, OEMs, who provide the devices, may be required to use only certified TPM components on their commercial class systems. For more information, contact your OEM or hardware vendor.

Related topics

  • Trusted Platform Module (list of topics)

Licensing: Microsoft agrees to grant to you a no charge, royalty-free license to its Necessary Claims on reasonable and non-discriminatory terms solely to make, use, sell, offer for sale, import, or distribute any implementation of this specification. 'Necessary Claims' are those claims of Microsoft-owned or Microsoft-controlled patents that are technically necessary to implement the required portions (which also include the required elements of optional portions) of this specification, where the functionality causing the infringement is described in detail and not merely referenced in this Specification.

1.0 Introduction

This document specifies an EFI protocol for interacting with a Trusted Execution Environment (TrEE), implementing TPM 2.0 functionality per a subset of a Trusted Computing Group (TCG) Trusted Platform Module 2.0 Library specification. This document also specifies platform firmware measurement requirements. The EFI protocol defined herein leverages to a large degree [TCG06a] and [TCG06b].

2.0 Data Structures and Acronyms

2.1 Data Structures

As in [TCG06a], all data values SHALL be represented in Little-Endian format. Strings SHALL be represented as an array of ASCII bytes with the left-most character placed in the lowest memory location.

2.2 Acronyms and Conventions

Tcg Mac Driver

Tcg drivers

(For acronyms not defined herein, see [TCG06a])

TrEETrusted Execution Environment

Use of the terms 'MUST' and 'SHALL' in this document are to be interpreted in accordance with [RFC2119].

3.0 EFI TrEE Protocol

This section provides a detailed description of the EFI_TREE_PROTOCOL and the EFI_TREE_SERVICE_BINDING_PROTOCOL. The EFI TrEE Protocol is used to communicate with a TrEE.

3.1 TrEE EFI Service Binding Protocol

This section defines the TrEE EFI service binding protocol.

Summary - The EFI TrEE Service Binding Protocol is used to locate TrEE devices that are supported by an EFI TrEE Protocol driver and to create and destroy EFI TrEE protocol child driver instances that can use the underlying TrEE device.

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

DescriptionAn application (or driver) that requires TrEE services can use one of the protocol handler services, such as BS->LocateHandleBuffer(), to search for devices that publish an EFI TrEE Service Binding Protocol. Each device with a published the EFI TrEE Service Binding Protocol supports the EFI TrEE Protocol and may be available for use.

After a successful call to the EFI_TREE_SERVICE_BINDING_PROTOCOL.CreateChild() function, the child EFI TrEE Protocol driver instance is ready for use.

Before an EFI application or driver terminates execution, every successful call to the EFI_TREE_SERVICE_BINDING_PROTOCOL.CreateChild() function must be matched with a call to the EFI_TREE_SERVICE_BINDING_PROTOCOL.DestroyChild() function.

3.2 TrEE EFI Protocol

Summary - The EFI TrEE protocol is used to communicate with a TrEE - to send commands to a TrEE, use it for trusted execution operations and to provide access to the firmware log of measurements extended in the TrEE. The protocol maintains an Event Log of measurements recorded in the TrEE with a format identical to the TCG 1.2 TCG Event Log (see [TCG06b]); referred to as the TrEE Event Log Format TCG 1.2 Event Log in this specification. Implementers may create additional Event Logs with other formats, but this version of the protocol does not define a way to retrieve them.

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

Protocol Interface Structure -



This service provides information about the TrEE and firmware capabilities


Get a pointer to a firmware event log


This service will cause the EFI TrEE driver to extend an event and (optionally) write the event to the TrEE log.


This service submits a command directly to the TrEE.

Description - The EFI_TREE_PROTOCOL abstracts TrEE activity. This protocol instance provides a Boot Service and is instantiated as a Boot Service Driver.

Boot Service Drivers are terminated when ExitBootServices ( ) is called and all memory resources consumed by the Boot Services Drivers are released for use in the operating system environment.

Tcg Edrive

This Boot Service must create an EVT_SIGNAL_EXIT_BOOT_SERVICES event. This event will be notified by the system when ExitBootServices ( ) is invoked.

EVT_SIGNAL_EXIT_BOOT_SERVICES is a synchronous event used to ensure that certain activities occur following a call to a specific interface function; in this case, that is the cleanup that needs to be done in response to the ExitBootServices ( ) function. ExitBootServices ( ) cannot clean up on behalf of drivers that have been loaded into the system. The drivers have to do that for themselves by creating an event whose type is EVT_SIGNAL_EXIT_BOOT_SERVICES and whose notification function is a function within the driver itself. Then, when ExitBootServices ( ) has finished its cleanup, it signals the event type EVT_SIGNAL_EXIT_BOOT_SERVICES.

For implementation details about how a Boot Service instantiated as an EFI Driver creates this required EVT_SIGNAL_EXIT_BOOT_SERVICES event, see Section 6.1 of [UEFI12].

3.3 EFI_TREE_PROTOCOL.GetCapability

The EFI_TREE_PROTOCOL GetCapability function call provides protocol capability information and state information about the TrEE.




Indicates the calling context.


The caller allocates memory for a TREE_BOOT_SERVICE_CAPABILITY structure and sets the size field to the size of the structure allocated. The callee fills in the fields with the EFI protocol capability information and the current TrEE state information up to the number of fields which fit within the size of the structure passed in.

Related Definitions


Allocated size of the structure passed in


Version of the TREE_BOOT_SERVICE_CAPABILITY structure itself. For this version of the protocol, the Major version shall be set to 1 and the Minor version shall be set to 0.


Version of the TrEE protocol. For this version of the protocol, the Major version shall be set to 1 and the Minor version shall be set to 0.


Supported hash algorithms


Bitmap of supported event log formats (see above)


False = TrEE not present


Max size (in bytes) of a command that can be sent to the TrEE


Max size (in bytes) of a response that can be provided by the TrEE


4-byte Vendor ID (see [TCG07], 'TPM Capabilities Vendor ID' section)


The EFI_TREE_PROTOCOL Get Capability function call provides EFI protocol version and capability information as well as state information about the TrEE. The caller must set the Size field of the TREE_BOOT_SERVICE_CAPABILITY structure allocated. It is expected future versions of this function call may add additional fields to the structure. The Size value passed in will enable the function to only populate fields the caller allocated memory for. For example:

ProtocolCapability.Size = sizeof(TREE_BOOT_SERVICE_CAPABILITY);

For this version of the specification:

  1. If the This or the ProtocolCapability parameters are NULL, the functional call will return EFI_INVALID_PARAMETER.

  2. If the input ProtocolCapability.Size < sizeof(TREE_BOOT_SERVICE_CAPABILITY) the function will set ProtocolCapability.Size equal to sizeof(TREE_BOOT_SERVICE_CAPABILITY) as defined in this specification and will return the error code EFI_BUFFER_TOO_SMALL, the values of the remaining fields will be undefined.

  3. The following return values MUST be set:

    ProtocolCapability.StructureVersion.Major = 1

    ProtocolCapability.StructureVersion.Minor = 0

    ProtocolCapability.ProtocolVersion.Major = 1

    ProtocolCapability.ProtocolVersion.Minor = 0

  4. If the platform does not have a TrEE then the following values MUST be returned:

    ProtocolCapability.SupportedEventLogs = 0

    ProtocolCapability.HashAlgorithmBitmap = 0

    ProtocolCapability.TrEEPresentFlag = FALSE

    ProtocolCapability.MaxCommandSize = 0

    ProtocolCapability.MaxResponseSize = 0

    ProtocolCapability.ManufacturerID = 0

  5. The minimum MaxCommandSize and MaxResponseSize MUST be 0x500 (or greater) for Windows.

Status Codes Returned


Operation completed successfully.


The command was unsuccessful. The ProtocolCapability variable will not be populated.


One or more of the parameters are incorrect. The ProtocolCapability variable will not be populated.


The ProtocolCapability variable is too small to hold the full response. It will be partially populated (required Size field will be set).


The EFI_TREE_PROTOCOL Get Event Log function call allows a caller to retrieve the address of a given event log and its last entry.




The type of the event log for which the information is requested.


A pointer to the memory address of the event log.


If the Event Log contains more than one entry, this is a pointer to the address of the start of the last entry in the event log in memory. For information about what values are returned in this parameter in the special cases of an empty Event Log or an Event Log with only one entry, see the Description section below.


If the Event Log is missing at least one entry because an event would have exceeded the area allocated for events, this value is set to TRUE. Otherwise, the value will be FALSE and the Event Log will be complete.


TCG Driver

The firmware manages an Event Log of the measurements recorded in the TrEE during the boot process. During the boot process, before UEFI platform initialization, an entry is made in the Event Log for each measurement extended in the TrEE. In the UEFI environment, each time a call is made to HashLogExtendEvent to extend a measurement in the TrEE, an event is generally recorded in the Event Log containing the extended measurement. If the area allocated by firmware for the Event Log was too small to hold all events added, the function call indicates the Event Log was truncated and has missing entries. This version of the specification only requires an Event Log of SHA1 measurements to be maintained. Future versions of this specification may maintain additional Event Logs supporting different hash algorithms.

The Event Log area returned by this function is released when ExitBootServices ( ) is called. Callers of this method MUST not access the area after ExitBootServices ( ) has been called.For this version of the specification:

  1. If EventLogFormat does not equal TREE_EVENT_LOG_FORMAT_TCG_1_2, the function call MUST return EFI_INVALID_PARAMETER.

  2. If no TrEE is present the function MUST set the following values and return EFI_SUCCESS:

    1. EventLogLocation = NULL

    2. EventLogLastEntry = NULL

    3. EventLogTruncated = FALSE

  3. The EventLogLocation value MUST be set to the start of the specified event log format in memory

  4. If the specified event log:

    1. does not contain any events then EventLogLastEntry MUST be set to 0

    2. contains exactly one entry then EventLogLastEntry MUST be set to the same value as EventLogLocation

    3. contains more than one event then EventLogLastEntry MUST be set to the start address of the last event of the specified Event Log

  5. If a prior call to EFI_TREE_PROTOCOL.HashLogExtendEvent returned EFI_VOLUME_FULL then EventLogTruncated MUST be set to TRUE, otherwise it MUST be set to FALSE.

Status Codes Returned


Operation completed successfully.


One or more of the parameters are incorrect (e.g. asking for an event log whose format is not supported).

3.5 EFI_TREE_PROTOCOL.HashLogExtendEvent

The EFI_TREE_PROTOCOL HashLogExtendEvent function call provides callers with an opportunity to extend and optionally log events without requiring knowledge of actual TPM commands.The extend operation will occur even if this function cannot create an event log entry (e.g. due to the event log being full).




Indicates the calling context.


Bitmap providing additional information (see below).


Physical address of the start of the data buffer to be



The length in bytes of the buffer referenced by DataToHash.


Pointer to data buffer containing information about the event.

Related Definitions


Total size of the event including the Size component, the header and the Event data.


Size of the event header itself (sizeof(TrEE_EVENT_HEADER)).


Header version. For this version of this specification, the value shall be 1.


Index of the PCR that shall be extended (0 - 23).


Type of the event that shall be extended (and optionally logged).

Flag Values

The Flags variable is a bitmap providing additional data as follows:

This bit is shall be set when an event shall be extended but not logged.

This bit shall be set when the intent is to measure a PE/COFF image.


The EFI_TREE_PROTOCOL Hash Log Extend Event function call calculates the measurement of a data buffer (possibly containing a PE/COFF binary image) and causes the TrEE driver to extend the measurement. In addition, the service optionally creates an event log entry and appends it to the Event Log for each event log format supported by the service. The service allows a caller to make use of the TrEE without knowing anything about specific TrEE commands.

The use of this function to measure PE/COFF images must be done before relocations have been applied to the image. Note: Use caution using this method to measure PE/COFF images. Generally implementations that load PE/COFF images strip important data during the load process from the image and may change the image section alignment in memory. The net result is calculating the hash of an in-memory image does not match the actual measurement for the image as properly calculated when it is loaded from storage media.

Upon invocation, the function shall perform the following actions:

  1. If any of the parameters This, DataToHash, or Event are NULL, the function MUST return EFI_INVALID_PARAMETER.

  2. If the Event.Size is less than Event.Header.HeaderSize + sizeof(UINT32), the function MUST return EFI_INVALID_PARAMETER.

  3. If the Event.Header.PCRIndex is not 0 through 23, inclusive, the function MUST return EFI_INVALID_PARAMETER.

  4. If the Flags bitmap has the PE_COFF_IMAGE bit SET but the PE/COFF image is corrupt or not understood the function MUST return EFI_UNSUPPORTED.

  5. The function allows any value for the Event.Header.EventType parameter.

  6. The function MUST calculate the digest (measurement) of the data starting at DataToHash with a length of DataToHashLen. When the PE_COFF_IMAGE bit is set, the function MUST calculate the measurement of the PE/COFF image in accordance with 'Measuring a PE/COFF image' in Appendix A below.

  7. The function MUST successfully send the TPM2_PCR_Extend command to the TrEE to extend the PCR indicated by Event.Header.PCRIndex with the measurement digest. If the command cannot be sent successfully, the function must return EFI_DEVICE_ERROR. If the firmware supports more algorithms than SHA1 it may calculate digests using other algorithms and extend them too.

  8. If a previous call to this function returned EFI_VOLUME_FULL and the TREE_EXTEND_ONLY bit is set in the Flags parameter, the function MUST return EFI_VOLUME_FULL. (No attempt is made to add the event log entry to the event log(s).)

  9. The function MUST build a TCG Event Log entry as follows: (Note: The TCG_PCR_EVENT structure is defined in [TCG06b] and shall be considered byte-aligned.)

    1. TCG_PCR_EVENT.PCRIndex = Event.Header.PCRIndex

    2. TCG_PCR_EVENT.EventType = Event.Header.EventType

    3. TCG_PCR_EVENT.Digest = <the SHA1 measurement digest calculated above>

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

    5. TCG_PCR_EVENT.Event = Event.Event (Note: this is a memory copy of EventSize bytes)

  10. The function MAY build similar event log entries for other supported Event Log formats.

  11. If the TCG_PCR_EVENT Event Log entry created above does not fit in the area allocated for the TrEE Event Log Format TCG 1.2 Event Log, the function MUST return EFI_VOLUME_FULL.

  12. If the firmware supports additional Event Log formats and any of the events created for those event logs would exceed the area allocated for the Event Log, the function MUST return EFI_VOLUME_FULL.

  13. The function MUST append the events created to their corresponding event logs and the service MUST update its internal pointer to the start of the last event for each Event Log.

Status Codes Returned.


Operation completed successfully.


The command was unsuccessful.


The extend operation occurred, but the event could not be written to one or more event logs.


One or more of the parameters are incorrect.


The PE/COFF image type is not supported.

3.6 EFI_TREE_PROTOCOL.SubmitCommand

This service enables the sending of commands to the TrEE.




Indicates the calling context.


Size of the TrEE input parameter block.


Pointer to the TrEE input parameter block.


Size of the TrEE output parameter block.


Pointer to the TrEE output parameter block.


The EFI_TREE_PROTOCOL Submit Command function call provides a pass-through capability from the caller to the system's TrEE.

The caller is responsible for building the command byte-stream to be sent to the TrEE and is also responsible for interpreting the resulting byte-stream returned by the TrEE. The TrEE in and out operands for each TrEE command are defined elsewhere.

Note that the returned status codes reflect the outcome of the function invocation and not the success (or failure) of the underlying TrEE command.

The TPM 2.0 MUST not return TPM2_RC_RETRY prior to the completion of the call to ExitBootServices(). (The reason for this requirement is the return code would block the boot process until the TPM command could be compeleted.)

The TPM 2.0 MUST have access to its persistent storage prior to the call to ExitBootServices completing. If TPM 2.0 implementation MAY not have access to persistent storage after the call to ExitBootServices, please contact Microsoft for additional requirements.

Status Codes Returned


The command byte stream was successfully sent to the device and a response was successfully received.


The command was not successfully sent to the device or a response was not successfully received from the device.


One or more of the parameters are incorrect.


The output parameter block is too small.



Microsoft Corporation, 'Windows Authenticode Portable Executable Signature Format,' Version 1.0, March 21, 2008.


Bradner, S., 'Keywords for Use in RFCs to Indicate Requirement Levels,' IETF RFC 2119, March 1997.


Trusted Computing Group, 'TCG EFI Protocol,' Version 1.20 Revision 1.00, June 9, 2006.


Trusted Computing Group, 'TCG EFI Platform Specification,' Version 1.20 Revision 1.0, June 7, 2006.


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


UEFI, 'Unified Extensible Firmware Interface Specification,' Version 2.3.1 Errata C,

June 2012.

Appendix A: Static Root of Trust Measurements


Appendix A implementation of PCR[7] measurements is mandatory for InstantGo systems.

At a high level, firmware is responsible for measuring the following components during boot:

  • Platform firmware that contains or measures the UEFI Boot Services and UEFI Runtime Services

  • Security relevant variables associated with platform firmware

  • UEFI drivers or boot applications loaded separately

  • Variables associated with separately loaded UEFI Drivers or UEFI Boot applications

The above measurements are defined by the TCG EFI Platform specification [TCG06b] Sections 5.1 - 5.5 and are not referred to further herein. Measurements into PCR[1] and PCR[3] are optional depending on platform configuration.

For Windows, PCR[7] is used to reflect the UEFI 2.3.1 Secure Boot policy. This policy relies on the firmware authenticating all boot components launched prior to the UEFI environment and the UEFI platform initialization code (or earlier firmware code) invariantly recording the Secure Boot policy information into PCR[7].

Platform firmware adhering to the policy must therefore measure the following values into PCR[7]:

  1. The contents of the PK variable

  2. The contents of the KEK variable

  3. The contents of the EFI_IMAGE_SECURITY_DATABASE variable

  4. The contents of the EFI_IMAGE_SECURITY_DATABASE1 variable

  5. Entries in the EFI_IMAGE_SECURITY_DATABASE that are used to validate EFI Drivers or EFI Boot Applications in the boot path

  6. The contents of the SecureBoot variable

Because of the above, UEFI variables PK, KEK, EFI_IMAGE_SECURITY_DATABASE, EFI_IMAGE_SECURITY_DATABASE1 and SecureBoot SHALL NOT be measured into PCR[3].

In addition, if the platform provides a firmware debugger which may be launched prior to the UEFI environment, it MUST record this fact in PCR[7]. Likewise, if the platform provides a debugger for the UEFI environment, launch of the debugger MUST be recorded in PCR[7].

Implementation Note

The UEFI LoadImage function MUST record measurements in PCR[2] or PCR[4] per events described in [TCG06b] and also PCR[7] per events described in the section 'Measuring UEFI Configuration into PCR[7]' below. To determine whether an image measurement applies to PCR[2] or PCR[4], LoadImage MUST examine the Subsystem field in the PE/COFF image. The values IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER, IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER and IMAGE_SUBSYSTEM_EFI_ROM correspond to PCR[2]. The value IMAGE_SUBSYSTEM_EFI_APPLICATION corresponds to PCR[4]. If the loaded image is some other type, it MUST be recorded in PCR[4]. Images that LoadImage fails to load due to (a) signature verification failure or (b) because the image does not comply with currently enforced UEFI 2.3.1 Secure Boot policy do not need to be measured in a PCR.

****Related Definitions

Measuring a PE/COFF Image

When measuring a PE/COFF image, the EventType shall be as defined in [TCG06b] (for example, when measuring an EFI Boot Application, the EventType shall be EV_EFI_BOOT_SERVICES_APPLICATION) and the Event value shall be the value of the EFI_IMAGE_LOAD_EVENT structure defined in [TCG06b].

The HashLogExtendEvent service MUST hash the PE/COFF image in accordance with the procedure specified in 'Calculating the PE Image Hash' section of [MSFT08].

Measuring UEFI Configuration into PCR[7]

For all EFI variable value events, the EventType shall be EV_EFI_VARIABLE_DRIVER_CONFIG defined above and the Event value shall be the value of the EFI_VARIABLE_DATA structure defined above in this specification (this structure shall be considered byte-aligned). The measurement digest shall be the SHA-1 hash of the event data which is the EFI_VARIABLE_DATA structure. (Note: This is a different digest than the one specified by [TCG06b].) The EFI_VARIABLE_DATA.UnicodeNameLength value is the number of CHAR16 characters (not the number of bytes). The EFI_VARIABLE_DATA.UnicodeName contents MUST NOT include a null terminator. If reading the EFI variable returns EFI_NOT_FOUND, the EFI_VARIABLE_DATA.VariableDataLength field MUST be set to zero and EFI_VARIABLE_DATA.VariableData field will have a size of zero.

  1. If the platform provides a firmware debugger mode which may be used prior to the UEFI environment or if the platform provides a debugger for the UEFI environment, then the platform SHALL extend an EV_EFI_ACTION event as specified in [TCG06b] into PCR[7] before allowing use of the debugger. The event string shall be 'UEFI Debug Mode'. Further, the platform MUST create a TCG Event Log entry as follows:

    1. TCG_PCR_EVENT.PCRIndex = 7


    3. TCG_PCR_EVENT.Digest = <the SHA-1 digest of the string value 'UEFI Debug Mode' without the terminating NULL character>

    4. TCG_PCR_EVENT.EventSize = strlen('UEFI Debug Mode')

    5. TCG_PCR_EVENT.Event = 'UEFI Debug Mode'

    The platform MAY build similar event log entries for other supported Event Log formats.

  2. Before executing any code not cryptographically authenticated as being provided by the Platform Manufacturer, the Platform Manufacturer firmware MUST measure the following values in the order listed using the EV_EFI_VARIABLE_DRIVER_CONFIG event type to PCR[7]:

    1. SecureBoot variable value

    2. The PK variable value

    3. The KEK variable value



  3. If the platform supports changing any of the following UEFI policy variables after they are initially measured in PCR[7] and before ExitBootServices ( ) has completed without unconditionally restarting the platform, it MUST measure the variable again immediately upon change. Additionally the normal update process for setting any of the UEFI variables below MUST occur before the initial measurement in PCR[7] or after the call to ExitBootServices() has completed.

    1. SecureBoot variable value

    2. The PK variable value

    3. The KEK variable value



  4. The system SHALL measure the EV_SEPARATOR event in PCR[7]. (This occurs at the same time the separator is measured to PCR[0] through PCR[7].)

  5. Before launching an EFI Driver or an EFI Boot Application (and regardless of whether the launch is due to the EFI Boot Manager picking an image from the DriverOrder or BootOrder UEFI variables or an already launched image calling the UEFI LoadImage() function), the UEFI firmware SHALL measure the entry in the EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE variable that was used to validate the EFI image into PCR[7]. The measurement SHALL occur in conjunction with image load. For this event, the EventType shall be EV_EFI_VARIABLE_AUTHORITY and the Event value shall be the value of the EFI_VARIABLE_DATA structure (the structure is defined above in this specification with a different definition than the TCG specification). The EFI_VARIABLE_DATA.VariableData value shall be the EFI_SIGNATURE_DATA value from the EFI_SIGNATURE_LIST that contained the authority that was used to validate the image and the EFI_VARIABLE_DATA.VariableName shall be set to EFI_IMAGE_SECURITY_DATABASE_GUID. The EFI_VARIABLE_DATA.UnicodeName shall be set to the value of EFI_IMAGE_SECURITY_DATABASE. The value shall not include the terminating NULL character.

  6. Before launching any additional EFI Drivers or EFI Boot Applications, the UEFI firmware SHALL check if the entry in the EFI_IMAGE_SECURITY_DATABASE_GUID/EFI_IMAGE_SECURITY_DATABASE variable which validates the EFI image has previously been measured with the EV_EFI_VARIABLE_AUTHORITY event type in PCR[7]. If it has not been, it MUST be measured as described in the previous step. If it has been measured previously, it MUST NOT be measured again.


A measurement example for PCR[7] measurements is available upon request from Microsoft.