xtest

The XTEST instruction queries the transactional execution status. If the instruction executes inside a transactionally executing RTM region or a transactionally executing HLE region, then the ZF flag is cleared, else it is set.

None.

#UDCPUID.07H.00H:EBX.HLE[4] = 0 and CPUID.07H.00H:EBX.RTM[11] = 0. If LOCK prefix is used. XTEST—Test if in Transactional Execution Vol. 2D 6-72 CHAPTER 7 7.1 OVERVIEW This chapter describes the Safer Mode Extensions (SMX) for the Intel 64 and IA-32 architectures. Safer Mode Extensions (SMX) provide a programming interface for system software to establish a measured environment within the platform to support trust decisions by end users. The measured environment includes: • Measured launch of a system executive, referred to as a Measured Launched Environment (MLE)1. The system executive may be based on a Virtual Machine Monitor (VMM), a measured VMM is referred to as MVMM2. • Mechanisms to ensure the above measurement is protected and stored in a secure location in the platform. • Protection mechanisms that allow the VMM to control attempts to modify the VMM. The measurement and protection mechanisms used by a measured environment are supported by the capabilities of an Intel® Trusted Execution Technology (Intel® TXT) platform: • The SMX are the processor’s programming interface in an Intel TXT platform. • The chipset in an Intel TXT platform provides enforcement of the protection mechanisms. • Trusted Platform Module (TPM) 1.2 in the platform provides platform configuration registers (PCRs) to store software measurement values. 7.2 SMX FUNCTIONALITY SMX functionality is provided in an Intel 64 processor through the GETSEC instruction via leaf functions. The GETSEC instruction supports multiple leaf functions. Leaf functions are selected by the value in EAX at the time GETSEC is executed. Each GETSEC leaf function is documented separately in the reference pages with a unique mnemonic (even though these mnemonics share the same opcode, 0F 37). 7.2.1 Detecting and Enabling SMX Software can detect support for SMX operation using the CPUID instruction. If software executes CPUID with 1 in EAX, a value of 1 in bit 6 of ECX indicates support for SMX operation (GETSEC is available), see CPUID instruction for the layout of feature flags of reported by CPUID.01H:ECX. System software enables SMX operation by setting CR4.SMXE[Bit 14] = 1 before attempting to execute GETSEC. Otherwise, execution of GETSEC results in the processor signaling an invalid opcode exception (#UD). If the CPUID SMX feature flag is clear (CPUID.01H:ECX[6] = 0), attempting to set CR4.SMXE[Bit 14] results in a general protection exception. The IA32_FEATURE_CONTROL MSR (at address 03AH) provides feature control bits that configure operation of VMX and SMX. These bits are documented in Table 7-1. Table 7-1. Layout of IA32_FEATURE_CONTROL Bit Position Description 0 Lock bit (0 = unlocked, 1 = locked). When set to '1' further writes to this MSR are blocked. 1 Enable VMX in SMX operation. 2 Enable VMX outside SMX operation. 1. See the Intel® Trusted Execution Technology Measured Launched Environment Programming Guide. 2. An MVMM is sometimes referred to as a measured launched environment (MLE). See the Intel® Trusted Execution Technology Mea- sured Launched Environment Programming Guide. Table 7-1. Layout of IA32_FEATURE_CONTROL 7:3 Reserved 14:8 SENTER Local Function Enables: When set, each bit in the field represents an enable control for a corresponding SENTER function. 15 SENTER Global Enable: Must be set to ‘1’ to enable operation of GETSEC[SENTER]. 16 Reserved 17 SGX Launch Control Enable: Must be set to ‘1’ to enable runtime re-configuration of SGX Launch Control via the IA32_SGXLEPUBKEYHASHn MSR. 18 SGX Global Enable: Must be set to ‘1’ to enable Intel SGX leaf functions. 19 Reserved 20 LMCE On: When set, system software can program the MSRs associated with LMCE to configure delivery of some machine check exceptions to a single logical processor. 63:21 Reserved • Bit 0 is a lock bit. If the lock bit is clear, an attempt to execute VMXON will cause a general-protection exception. Attempting to execute GETSEC[SENTER] when the lock bit is clear will also cause a general- protection exception. If the lock bit is set, WRMSR to the IA32_FEATURE_CONTROL MSR will cause a general- protection exception. Once the lock bit is set, the MSR cannot be modified until a power-on reset. System BIOS can use this bit to provide a setup option for BIOS to disable support for VMX, SMX or both VMX and SMX. • Bit 1 enables VMX in SMX operation (between executing the SENTER and SEXIT leaves of GETSEC). If this bit is clear, an attempt to execute VMXON in SMX will cause a general-protection exception if executed in SMX operation. Attempts to set this bit on logical processors that do not support both VMX operation (Chapter 7, “Safer Mode Extensions Reference”) and SMX operation cause general-protection exceptions. • Bit 2 enables VMX outside SMX operation. If this bit is clear, an attempt to execute VMXON will cause a general- protection exception if executed outside SMX operation. Attempts to set this bit on logical processors that do not support VMX operation cause general-protection exceptions. • Bits 8 through 14 specify enabled functionality of the SENTER leaf function. Each bit in the field represents an enable control for a corresponding SENTER function. Only enabled SENTER leaf functionality can be used when executing SENTER. • Bits 15 specify global enable of all SENTER functionalities. 7.2.2 SMX Instruction Summary System software must first query for available GETSEC leaf functions by executing GETSEC[CAPABILITIES]. The CAPABILITIES leaf function returns a bit map of available GETSEC leaves. An attempt to execute an unsupported leaf index results in an undefined opcode (#UD) exception. 7.2.2.1 GETSEC[CAPABILITIES] The SMX functionality provides an architectural interface for newer processor generations to extend SMX capabili- ties. Specifically, the GETSEC instruction provides a capability leaf function for system software to discover the available GETSEC leaf functions that are supported in a processor. Table 7-2 lists the currently available GETSEC leaf functions. . Table 7-2. GETSEC Leaf Functions Index (EAX) Leaf function Description 0 CAPABILITIES Returns the available leaf functions of the GETSEC instruction. 1 Undefined Reserved 2 ENTERACCS Enter 3 EXITAC Exit 4 SENTER Launch an MLE. 5 SEXIT Exit the MLE. 6 PARAMETERS Return SMX related parameter information. 7 SMCTRL SMX mode control. 8 WAKEUP Wake up sleeping processors in safer mode. 9 - (4G-1) Undefined Reserved 7.2.2.2 GETSEC[ENTERACCS] The GETSEC[ENTERACCS] leaf enables authenticated code execution mode. The ENTERACCS leaf function performs an authenticated code module load using the chipset public key as the signature verification. ENTERACCS requires the existence of an Intel® Trusted Execution Technology capable chipset since it unlocks the chipset private configuration register space after successful authentication of the loaded module. The physical base address and size of the authenticated code module are specified as input register values in EBX and ECX, respec- tively. While in the authenticated code execution mode, certain processor state properties change. For this reason, the time in which the processor operates in authenticated code execution mode should be limited to minimize impact on external system events. Upon entry into, the previous paging context is disabled (since the authenticated code module image is specified with physical addresses and can no longer rely upon external memory-based page-table structures). Prior to executing the GETSEC[ENTERACCS] leaf, system software must ensure the logical processor issuing GETSEC[ENTERACCS] is the boot-strap processor (BSP), as indicated by IA32_APIC_BASE.BSP = 1. System soft- ware must ensure other logical processors are in a suitable idle state and not marked as BSP. The GETSEC[ENTERACCS] leaf may be used by different agents to load different authenticated code modules to perform functions related to different aspects of a measured environment, for example system software and Intel® TXT enabled BIOS may use more than one authenticated code modules. 7.2.2.3 GETSEC[EXITAC] GETSEC[EXITAC] takes the processor out of authenticated code execution mode. When this instruction leaf is executed, the contents of the authenticated code execution area are scrubbed and control is transferred to the non-authenticated context defined by a near pointer passed with the GETSEC[EXITAC] instruction. The authenticated code execution area is no longer accessible after completion of GETSEC[EXITAC]. RBX (or EBX) holds the address of the near absolute indirect target to be taken. 7.2.2.4 GETSEC[SENTER] The GETSEC[SENTER] leaf function is used by the initiating logical processor (ILP) to launch an MLE. GETSEC[SENTER] can be considered a superset of the ENTERACCS leaf, because it enters as part of the measured environment launch. Measured environment startup consists of the following steps: • the ILP rendezvous the responding logical processors (RLPs) in the platform into a controlled state (At the completion of this handshake, all the RLPs except for the ILP initiating the measured environment launch are placed in a newly defined SENTER sleep state). • Load and authenticate the authenticated code module required by the measured environment, and enter authenticated code execution mode. • Verify and lock certain system configuration parameters. • Measure the dynamic root of trust and store into the PCRs in TPM. • Transfer control to the MLE with interrupts disabled. Prior to executing the GETSEC[SENTER] leaf, system software must ensure the platform’s TPM is ready for access and the ILP is the boot-strap processor (BSP), as indicated by IA32_APIC_BASE.BSP. System software must ensure other logical processors (RLPs) are in a suitable idle state and not marked as BSP. System software launching a measurement environment is responsible for providing a proper authenticate code module address when executing GETSEC[SENTER]. The AC module responsible for the launch of a measured envi- ronment and loaded by GETSEC[SENTER] is referred to as SINIT. See Intel® Trusted Execution Technology Measured Launched Environment Programming Guide for additional information on system software requirements prior to executing GETSEC[SENTER]. 7.2.2.5 GETSEC[SEXIT] System software exits the measured environment by executing the instruction GETSEC[SEXIT] on the ILP. This instruction rendezvous the responding logical processors in the platform for exiting from the measured environ- ment. External events (if left masked) are unmasked and Intel® TXT-capable chipset’s private configuration space is re-locked. 7.2.2.6 GETSEC[PARAMETERS] The GETSEC[PARAMETERS] leaf function is used to report attributes, options, and limitations of SMX operation. Software uses this leaf to identify operating limits or additional options. The information reported by GETSEC[PARAMETERS] may require executing the leaf multiple times using EBX as an index. If the GETSEC[PARAMETERS] instruction leaf or if a specific parameter field is not available, then SMX oper- ation should be interpreted to use the default limits of respective GETSEC leaves or parameter fields defined in the GETSEC[PARAMETERS] leaf. 7.2.2.7 GETSEC[SMCTRL] The GETSEC[SMCTRL] leaf function is used for providing additional control over specific conditions associated with the SMX architecture. An input register is supported for selecting the control operation to be performed. See the specific leaf description for details on the type of control provided. 7.2.2.8 GETSEC[WAKEUP] Responding logical processors (RLPs) are placed in the SENTER sleep state after the initiating logical processor executes GETSEC[SENTER]. The ILP can wake up RLPs to join the measured environment by using GETSEC[WAKEUP]. When the RLPs in SENTER sleep state wake up, these logical processors begin execution at the entry point defined in a data structure held in system memory (pointed to by an chipset register LT.MLE.JOIN) in TXT configuration space. 7.2.3 Measured Environment and SMX This section gives a simplified view of a representative life cycle of a measured environment that is launched by a system executive using SMX leaf functions. The Intel® Trusted Execution Technology Measured Launched Environ- ment Programming Guide provides more detailed examples of using SMX and chipset resources (including chipset registers, Trusted Platform Module) to launch an MVMM. The life cycle starts with the system executive (an OS, an OS loader, and so forth) loading the MLE and SINIT AC module into available system memory. The system executive must validate and prepare the platform for the measured launch. When the platform is properly configured, the system executive executes GETSEC[SENTER] on the initiating logical processor (ILP) to rendezvous the responding logical processors into an SENTER sleep state, the ILP then enters into using the SINIT AC module. In a multi-threaded or multi-processing environment, the system executive must ensure that other logical processors are already in an idle loop, or asleep (such as after executing HLT) before executing GETSEC[SENTER]. After the GETSEC[SENTER] rendezvous handshake is performed between all logical processors in the platform, the ILP loads the chipset authenticated code module (SINIT) and performs an authentication check. If the check passes, the processor hashes the SINIT AC module and stores the result into TPM PCR 17. It then switches execu- tion context to the SINIT AC module. The SINIT AC module will perform a number of platform operations, including: verifying the system configuration, protecting the system memory used by the MLE from I/O devices capable of DMA, producing a hash of the MLE, storing the hash value in TPM PCR 18, and various other operations. When SINIT completes execution, it executes the GETSEC[EXITAC] instruction and transfers control the MLE at the designated entry point. Upon receiving control from the SINIT AC module, the MLE must establish its protection and isolation controls before enabling DMA and interrupts and transferring control to other software modules. It must also wake up the RLPs from their SENTER sleep state using the GETSEC[WAKEUP] instruction and bring them into its protection and isolation environment. While executing in a measured environment, the MVMM can access the Trusted Platform Module (TPM) in locality 2. The MVMM has complete access to all TPM commands and may use the TPM to report current measurement values or use the measurement values to protect information such that only when the platform configuration registers (PCRs) contain the same value is the information released from the TPM. This protection mechanism is known as sealing. A measured environment shutdown is ultimately completed by executing GETSEC[SEXIT]. Prior to this step system software is responsible for scrubbing sensitive information left in the processor caches, system memory. 7.3 GETSEC LEAF FUNCTIONS This section provides detailed descriptions of each leaf function of the GETSEC instruction. GETSEC is available only if CPUID.01H:ECX[6] = 1. This indicates the availability of SMX and the GETSEC instruction. Before GETSEC can be executed, SMX must be enabled by setting CR4.SMXE[Bit 14] = 1. A GETSEC leaf can only be used if it is shown to be available as reported by the GETSEC[CAPABILITIES] function. Attempts to access a GETSEC leaf index not supported by the processor, or if CR4.SMXE is 0, results in the signaling of an undefined opcode exception. All GETSEC leaf functions are available in protected mode, including the compatibility sub-mode of IA-32e mode and the 64-bit sub-mode of IA-32e mode. Unless otherwise noted, the behavior of all GETSEC functions and inter- actions related to the measured environment are independent of IA-32e mode. This also applies to the interpreta- tion of register widths1 passed as input parameters to GETSEC functions and to register results returned as output parameters. 1. This chapter uses the 64-bit notation RAX, RIP, RSP, RFLAGS, etc. for processor registers because processors that support SMX also support Intel 64 Architecture. The MVMM can be launched in IA-32e mode or outside IA-32e mode. The 64-bit notation of processor registers also refer to its 32-bit forms if SMX is used in 32-bit environment. In some places, notation such as EAX is used to refer specifically to lower 32 bits of the indicated register. The GETSEC functions ENTERACCS, SENTER, SEXIT, and WAKEUP require a Intel® TXT capable-chipset to be present in the platform. The GETSEC[CAPABILITIES] returned bit vector in position 0 indicates an Intel® TXT- capable chipset has been sampled present1 by the processor. The processor's operating mode also affects the execution of the following GETSEC leaf functions: SMCTRL, ENTER- ACCS, EXITAC, SENTER, SEXIT, and WAKEUP. These functions are only allowed in protected mode at CPL = 0. They are not allowed while in SMM in order to prevent potential intra-mode conflicts. Further execution qualifications exist to prevent potential architectural conflicts (for example: nesting of the measured environment or authenti- cated code execution mode). See the definitions of the GETSEC leaf functions for specific requirements. For the purpose of performance monitor counting, the execution of GETSEC functions is counted as a single instruc- tion with respect to retired instructions. The response by a responding logical processor (RLP) to messages associ- ated with GETSEC[SENTER] or GTSEC[SEXIT] is transparent to the retired instruction count on the ILP. 1. Sampled present means that the processor sent a message to the chipset and the chipset responded that it (a) knows about the message and (b) is capable of executing SENTER. This means that the chipset CAN support Intel® TXT, and is configured and WILLING to support it.