Content      ..     119      120      121      122     ..

Intel 64 and IA-32 Architectures. Software Developer’s Manual (Collection, 2023) - page 121

INSTRUCTION SET REFERENCE, W-Z

XRSTORS—Restore Processor Extended States Supervisor

Opcode /

Op/

64/32 bit

CPUID

Description

Instruction

En

Mode

Feature

Support

Flag

NP 0F C7 /3

M

V/V

XSS

Restore state components specified by EDX:EAX from

mem.

XRSTORS mem

NP REX.W + 0F C7 /3

M

V/N.E.

XSS

Restore state components specified by EDX:EAX from

mem.

XRSTORS64 mem

Instruction Operand Encoding

Op/En

Operand 1

Operand 2

Operand 3

Operand 4

M

ModRM:r/m (r)

N/A

N/A

N/A

Description

Performs a full or partial restore of processor state components from the XSAVE area located at the memory

address specified by the source operand. The implicit EDX:EAX register pair specifies a 64-bit instruction mask. The

specific state components restored correspond to the bits set in the requested-feature bitmap (RFBM), which is the

logical-AND of EDX:EAX and the logical-OR of XCR0 with the IA32_XSS MSR. XRSTORS may be executed only if

CPL = 0.

The format of the XSAVE area is detailed in Section 13.4, “XSAVE Area,” of Intel^® 64 and IA-32 Architectures Soft-

ware Developer’s Manual, Volume 1. Like FXRSTOR and FXSAVE, the memory format used for x87 state depends

on a REX.W prefix; see Section 13.5.1, “x87 State” of Intel^® 64 and IA-32 Architectures Software Developer’s

Manual, Volume 1.

Section 13.12, “Operation of XRSTORS,” of Intel^® 64 and IA-32 Architectures Software Developer’s Manual,

Volume 1 provides a detailed description of the operation of the XRSTOR instruction. The following items provide a

high-level outline:

• Execution of XRSTORS is similar to that of the compacted form of XRSTOR; XRSTORS cannot restore from an

XSAVE area in which the extended region is in the standard format (see Section 13.4.3, “Extended Region of an

XSAVE Area” of Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1).

• XRSTORS differs from XRSTOR in that it can restore state components corresponding to bits set in the

IA32_XSS MSR.

• If RFBM[i] = 0, XRSTORS does not update state component i.

• If RFBM[i] = 1 and bit i is clear in the XSTATE_BV field in the XSAVE header, XRSTORS initializes state

component i.

• If RFBM[i] = 1 and XSTATE_BV[i] = 1, XRSTORS loads state component i from the XSAVE area.

• If XRSTORS attempts to load MXCSR with an illegal value, a general-protection exception (#GP) occurs.

• XRSTORS loads the internal value XRSTOR_INFO, which may be used to optimize a subsequent execution of

XSAVEOPT or XSAVES.

• Immediately following an execution of XRSTORS, the processor tracks as in-use (not in initial configuration)

any state component i for which RFBM[i] = 1 and XSTATE_BV[i] = 1; it tracks as modified any state component

i for which RFBM[i] = 0.

Use of a source operand not aligned to 64-byte boundary (for 64-bit and 32-bit modes) results in a general-protec-

tion (#GP) exception. In 64-bit mode, the upper 32 bits of RDX and RAX are ignored.

See Section 13.6, “Processor Tracking of XSAVE-Managed State,” of Intel^® 64 and IA-32 Architectures Software

Developer’s Manual, Volume 1 for discussion of the bitmaps XINUSE and XMODIFIED and of the quantity

XRSTOR_INFO.

6-50

Vol. 2D

XRSTORS—Restore Processor Extended States Supervisor

INSTRUCTION SET REFERENCE, W-Z

XSAVE—Save Processor Extended States

Opcode /

Op/

64/32 bit

CPUID

Description

Instruction

En

Mode

Feature

Support

Flag

NP 0F AE /4

M

V/V

XSAVE

Save state components specified by EDX:EAX to mem.

XSAVE mem

NP REX.W + 0F AE /4

M

V/N.E.

XSAVE

Save state components specified by EDX:EAX to mem.

XSAVE64 mem

Instruction Operand Encoding

Op/En

Operand 1

Operand 2

Operand 3

Operand 4

M

ModRM:r/m (r, w)

N/A

N/A

N/A

Description

Performs a full or partial save of processor state components to the XSAVE area located at the memory address

specified by the destination operand. The implicit EDX:EAX register pair specifies a 64-bit instruction mask. The

specific state components saved correspond to the bits set in the requested-feature bitmap (RFBM), which is the

logical-AND of EDX:EAX and XCR0.

The format of the XSAVE area is detailed in Section 13.4, “XSAVE Area,” of Intel^® 64 and IA-32 Architectures Soft-

ware Developer’s Manual, Volume 1. Like FXRSTOR and FXSAVE, the memory format used for x87 state depends

on a REX.W prefix; see Section 13.5.1, “x87 State” of Intel^® 64 and IA-32 Architectures Software Developer’s

Manual, Volume 1.

Section 13.7, “Operation of XSAVE,” of Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1

provides a detailed description of the operation of the XSAVE instruction. The following items provide a high-level

outline:

• XSAVE saves state component i if and only if RFBM[i] = 1.¹

• XSAVE does not modify bytes 511:464 of the legacy region of the XSAVE area (see Section 13.4.1, “Legacy

Region of an XSAVE Area” of Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1).

• XSAVE reads the XSTATE_BV field of the XSAVE header (see Section 13.4.2, “XSAVE Header” of Intel^® 64 and

IA-32 Architectures Software Developer’s Manual, Volume 1) and writes a modified value back to memory as

follows. If RFBM[i] = 1, XSAVE writes XSTATE_BV[i] with the value of XINUSE[i]. (XINUSE is a bitmap by which

the processor tracks the status of various state components. See Section 13.6, “Processor Tracking of XSAVE-

Managed State” of Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1.) If RFBM[i] = 0,

XSAVE writes XSTATE_BV[i] with the value that it read from memory (it does not modify the bit). XSAVE does

not write to any part of the XSAVE header other than the XSTATE_BV field.

• XSAVE always uses the standard format of the extended region of the XSAVE area (see Section 13.4.3,

“Extended Region of an XSAVE Area” of Intel^® 64 and IA-32 Architectures Software Developer’s Manual,

Volume 1).

Use of a destination operand not aligned to 64-byte boundary (in either 64-bit or 32-bit modes) results in a

general-protection (#GP) exception. In 64-bit mode, the upper 32 bits of RDX and RAX are ignored.

1. An exception is made for MXCSR and MXCSR_MASK, which belong to state component 1 — SSE. XSAVE saves these values to mem-

ory if either RFBM[1] or RFBM[2] is 1.

6-54

Vol. 2D

XSAVE—Save Processor Extended States

INSTRUCTION SET REFERENCE, W-Z

XSAVEC—Save Processor Extended States With Compaction

Opcode /

Op/

64/32 bit

CPUID

Description

Instruction

En

Mode

Feature

Support

Flag

NP 0F C7 /4

M

V/V

XSAVEC

Save state components specified by EDX:EAX to mem with

compaction.

XSAVEC mem

NP REX.W + 0F C7 /4

M

V/N.E.

XSAVEC

Save state components specified by EDX:EAX to mem with

compaction.

XSAVEC64 mem

Instruction Operand Encoding

Op/En

Operand 1

Operand 2

Operand 3

Operand 4

M

ModRM:r/m (w)

N/A

N/A

N/A

Description

Performs a full or partial save of processor state components to the XSAVE area located at the memory address

specified by the destination operand. The implicit EDX:EAX register pair specifies a 64-bit instruction mask. The

specific state components saved correspond to the bits set in the requested-feature bitmap (RFBM), which is the

logical-AND of EDX:EAX and XCR0.

The format of the XSAVE area is detailed in Section 13.4, “XSAVE Area,” of Intel^® 64 and IA-32 Architectures Soft-

ware Developer’s Manual, Volume 1. Like FXRSTOR and FXSAVE, the memory format used for x87 state depends

on a REX.W prefix; see Section 13.5.1, “x87 State” of Intel^® 64 and IA-32 Architectures Software Developer’s

Manual, Volume 1.

Section 13.10, “Operation of XSAVEC,” of Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume

1 provides a detailed description of the operation of the XSAVEC instruction. The following items provide a high-

level outline:

• Execution of XSAVEC is similar to that of XSAVE. XSAVEC differs from XSAVE in that it uses compaction and that

it may use the init optimization.

• XSAVEC saves state component i if and only if RFBM[i] = 1 and XINUSE[i] = 1.¹ (XINUSE is a bitmap by which

the processor tracks the status of various state components. See Section 13.6, “Processor Tracking of XSAVE-

Managed State” of Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1.)

• XSAVEC does not modify bytes 511:464 of the legacy region of the XSAVE area (see Section 13.4.1, “Legacy

Region of an XSAVE Area” of Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1).

• XSAVEC writes the logical AND of RFBM and XINUSE to the XSTATE_BV field of the XSAVE header.^2,3 (See

Section 13.4.2, “XSAVE Header” of Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1.)

XSAVEC sets bit 63 of the XCOMP_BV field and sets bits 62:0 of that field to RFBM[62:0]. XSAVEC does not

write to any parts of the XSAVE header other than the XSTATE_BV and XCOMP_BV fields.

• XSAVEC always uses the compacted format of the extended region of the XSAVE area (see Section 13.4.3,

“Extended Region of an XSAVE Area” of Intel^® 64 and IA-32 Architectures Software Developer’s Manual,

Volume 1).

Use of a destination operand not aligned to 64-byte boundary (in either 64-bit or 32-bit modes) results in a

general-protection (#GP) exception. In 64-bit mode, the upper 32 bits of RDX and RAX are ignored.

1. There is an exception for state component 1 (SSE). MXCSR is part of SSE state, but XINUSE[1] may be 0 even if MXCSR does not

have its initial value of 1F80H. In this case, XSAVEC saves SSE state as long as RFBM[1] = 1.

2. Unlike XSAVE and XSAVEOPT, XSAVEC clears bits in the XSTATE_BV field that correspond to bits that are clear in RFBM.

3. There is an exception for state component 1 (SSE). MXCSR is part of SSE state, but XINUSE[1] may be 0 even if MXCSR does not

have its initial value of 1F80H. In this case, XSAVEC sets XSTATE_BV[1] to 1 as long as RFBM[1] = 1.

XSAVEC—Save Processor Extended States With Compaction

Vol. 2D

6-57

INSTRUCTION SET REFERENCE, W-Z

XSAVEOPT—Save Processor Extended States Optimized

Opcode/

Op/

64/32 bit

CPUID

Description

Instruction

En

Mode

Feature

Support

Flag

NP 0F AE /6

M

V/V

XSAVEOPT

Save state components specified by EDX:EAX

to mem, optimizing if possible.

XSAVEOPT mem

NP REX.W + 0F AE /6

M

V/V

XSAVEOPT

Save state components specified by EDX:EAX

to mem, optimizing if possible.

XSAVEOPT64 mem

Instruction Operand Encoding

Op/En

Operand 1

Operand 2

Operand 3

Operand 4

M

ModRM:r/m (r, w)

N/A

N/A

N/A

Description

Performs a full or partial save of processor state components to the XSAVE area located at the memory address

specified by the destination operand. The implicit EDX:EAX register pair specifies a 64-bit instruction mask. The

specific state components saved correspond to the bits set in the requested-feature bitmap (RFBM), which is the

logical-AND of EDX:EAX and XCR0.

The format of the XSAVE area is detailed in Section 13.4, “XSAVE Area,” of Intel^® 64 and IA-32 Architectures Soft-

ware Developer’s Manual, Volume 1. Like FXRSTOR and FXSAVE, the memory format used for x87 state depends

on a REX.W prefix; see Section 13.5.1, “x87 State” of Intel^® 64 and IA-32 Architectures Software Developer’s

Manual, Volume 1.

Section 13.9, “Operation of XSAVEOPT,” of Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume

1 provides a detailed description of the operation of the XSAVEOPT instruction. The following items provide a high-

level outline:

• Execution of XSAVEOPT is similar to that of XSAVE. XSAVEOPT differs from XSAVE in that it may use the init and

modified optimizations. The performance of XSAVEOPT will be equal to or better than that of XSAVE.

• XSAVEOPT saves state component i only if RFBM[i] = 1 and XINUSE[i] = 1.¹ (XINUSE is a bitmap by which the

processor tracks the status of various state components. See Section 13.6, “Processor Tracking of XSAVE-

Managed State,” of the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1.) Even if both

bits are 1, XSAVEOPT may optimize and not save state component i if (1) state component i has not been

modified since the last execution of XRSTOR or XRSTORS; and (2) this execution of XSAVES corresponds to

that last execution of XRSTOR or XRSTORS as determined by the internal value XRSTOR_INFO (see the

Operation section below).

• XSAVEOPT does not modify bytes 511:464 of the legacy region of the XSAVE area (see Section 13.4.1, “Legacy

Region of an XSAVE Area” of Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1).

• XSAVEOPT reads the XSTATE_BV field of the XSAVE header (see Section 13.4.2, “XSAVE Header,” of the Intel^®

64 and IA-32 Architectures Software Developer’s Manual, Volume 1) and writes a modified value back to

memory as follows. If RFBM[i] = 1, XSAVEOPT writes XSTATE_BV[i] with the value of XINUSE[i]. If RFBM[i] =

0, XSAVEOPT writes XSTATE_BV[i] with the value that it read from memory (it does not modify the bit).

XSAVEOPT does not write to any part of the XSAVE header other than the XSTATE_BV field.

• XSAVEOPT always uses the standard format of the extended region of the XSAVE area (see Section 13.4.3,

“Extended Region of an XSAVE Area” of Intel^® 64 and IA-32 Architectures Software Developer’s Manual,

Volume 1).

Use of a destination operand not aligned to 64-byte boundary (in either 64-bit or 32-bit modes) will result in a

general-protection (#GP) exception. In 64-bit mode, the upper 32 bits of RDX and RAX are ignored.

1. There is an exception made for MXCSR and MXCSR_MASK, which belong to state component 1 — SSE. XSAVEOPT always saves

these to memory if RFBM[1] = 1 or RFBM[2] = 1, regardless of the value of XINUSE.

6-60

Vol. 2D

XSAVEOPT—Save Processor Extended States Optimized

INSTRUCTION SET REFERENCE, W-Z

XSAVES—Save Processor Extended States Supervisor

Opcode /

Op/

64/32 bit

CPUID

Description

Instruction

En

Mode

Feature

Support

Flag

NP 0F C7 /5

M

V/V

XSS

Save state components specified by EDX:EAX to

mem with compaction, optimizing if possible.

XSAVES mem

NP REX.W + 0F C7 /5

M

V/N.E.

XSS

Save state components specified by EDX:EAX to

mem with compaction, optimizing if possible.

XSAVES64 mem

Instruction Operand Encoding

Op/En

Operand 1

Operand 2

Operand 3

Operand 4

M

ModRM:r/m (w)

N/A

N/A

N/A

Description

Performs a full or partial save of processor state components to the XSAVE area located at the memory address

specified by the destination operand. The implicit EDX:EAX register pair specifies a 64-bit instruction mask. The

specific state components saved correspond to the bits set in the requested-feature bitmap (RFBM), the logical-

AND of EDX:EAX and the logical-OR of XCR0 with the IA32_XSS MSR. XSAVES may be executed only if CPL = 0.

The format of the XSAVE area is detailed in Section 13.4, “XSAVE Area,” of the Intel^® 64 and IA-32 Architectures

Software Developer’s Manual, Volume 1. Like FXRSTOR and FXSAVE, the memory format used for x87 state

depends on a REX.W prefix; see Section 13.5.1, “x87 State,” of the Intel^® 64 and IA-32 Architectures Software

Developer’s Manual, Volume 1.

Section 13.11, “Operation of XSAVES,” of the Intel^® 64 and IA-32 Architectures Software Developer’s Manual,

Volume 1 provides a detailed description of the operation of the XSAVES instruction. The following items provide a

high-level outline:

• Execution of XSAVES is similar to that of XSAVEC. XSAVES differs from XSAVEC in that it can save state

components corresponding to bits set in the IA32_XSS MSR and that it may use the modified optimization.

• XSAVES saves state component i only if RFBM[i] = 1 and XINUSE[i] = 1.¹ (XINUSE is a bitmap by which the

processor tracks the status of various state components. See Section 13.6, “Processor Tracking of XSAVE-

Managed State,” of the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1.) Even if

both bits are 1, XSAVES may optimize and not save state component i if (1) state component i has not been

modified since the last execution of XRSTOR or XRSTORS; and (2) this execution of XSAVES correspond to that

last execution of XRSTOR or XRSTORS as determined by XRSTOR_INFO (see the Operation section below).

• XSAVES does not modify bytes 511:464 of the legacy region of the XSAVE area (see Section 13.4.1, “Legacy

Region of an XSAVE Area,” of the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1).

• XSAVES writes the logical AND of RFBM and XINUSE to the XSTATE_BV field of the XSAVE header.² (See Section

13.4.2, “XSAVE Header,” of the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1.)

XSAVES sets bit 63 of the XCOMP_BV field and sets bits 62:0 of that field to RFBM[62:0]. XSAVES does not

write to any parts of the XSAVE header other than the XSTATE_BV and XCOMP_BV fields.

• XSAVES always uses the compacted format of the extended region of the XSAVE area (see Section 13.4.3,

“Extended Region of an XSAVE Area,” of the Intel^® 64 and IA-32 Architectures Software Developer’s Manual,

Volume 1).

Use of a destination operand not aligned to 64-byte boundary (in either 64-bit or 32-bit modes) results in a

general-protection (#GP) exception. In 64-bit mode, the upper 32 bits of RDX and RAX are ignored.

1. There is an exception for state component 1 (SSE). MXCSR is part of SSE state, but XINUSE[1] may be 0 even if MXCSR does not

have its initial value of 1F80H. In this case, the init optimization does not apply and XSAVEC will save SSE state as long as RFBM[1] =

1 and the modified optimization is not being applied.

2. There is an exception for state component 1 (SSE). MXCSR is part of SSE state, but XINUSE[1] may be 0 even if MXCSR does not

have its initial value of 1F80H. In this case, XSAVES sets XSTATE_BV[1] to 1 as long as RFBM[1] = 1.

XSAVES—Save Processor Extended States Supervisor

Vol. 2D

6-63

INSTRUCTION SET REFERENCE, W-Z

XSETBV—Set Extended Control Register

Opcode

Instruction

Op/

64-Bit

Compat/

Description

En

Mode

Leg Mode

NP 0F 01 D1

XSETBV

ZO

Valid

Valid

Write the value in EDX:EAX to the XCR

specified by ECX.

Instruction Operand Encoding

Op/En

Operand 1

Operand 2

Operand 3

Operand 4

ZO

N/A

N/A

N/A

N/A

Description

Writes the contents of registers EDX:EAX into the 64-bit extended control register (XCR) specified in the ECX

register. (On processors that support the Intel 64 architecture, the high-order 32 bits of RCX are ignored.) The

contents of the EDX register are copied to high-order 32 bits of the selected XCR and the contents of the EAX

register are copied to low-order 32 bits of the XCR. (On processors that support the Intel 64 architecture, the high-

order 32 bits of each of RAX and RDX are ignored.) Undefined or reserved bits in an XCR should be set to values

previously read.

This instruction must be executed at privilege level 0 or in real-address mode; otherwise, a general protection

exception #GP(0) is generated. Specifying a reserved or unimplemented XCR in ECX will also cause a general

protection exception. The processor will also generate a general protection exception if software attempts to write

to reserved bits in an XCR.

Currently, only XCR0 is supported. Thus, all other values of ECX are reserved and will cause a #GP(0). Note that

bit 0 of XCR0 (corresponding to x87 state) must be set to 1; the instruction will cause a #GP(0) if an attempt is

made to clear this bit. In addition, the instruction causes a #GP(0) if an attempt is made to set XCR0[2] (AVX state)

while clearing XCR0[1] (SSE state); it is necessary to set both bits to use AVX instructions; Section 13.3, “Enabling

the XSAVE Feature Set and XSAVE-Enabled Features,” of Intel^® 64 and IA-32 Architectures Software Developer’s

Manual, Volume 1.

Operation

XCR[ECX] := EDX:EAX;

Flags Affected

None.

Intel C/C++ Compiler Intrinsic Equivalent

XSETBV void _xsetbv( unsigned int, unsigned __int64);

Protected Mode Exceptions

#GP(0)

If the current privilege level is not 0.

If an invalid XCR is specified in ECX.

If the value in EDX:EAX sets bits that are reserved in the XCR specified by ECX.

If an attempt is made to clear bit 0 of XCR0.

If an attempt is made to set XCR0[2:1] to 10b.

#UD

If CPUID.01H:ECX.XSAVE[bit 26] = 0.

If CR4.OSXSAVE[bit 18] = 0.

If the LOCK prefix is used.

6-66

Vol. 2D

XSETBV—Set Extended Control Register

INSTRUCTION SET REFERENCE, W-Z

XSUSLDTRK—Suspend Tracking Load Addresses

Opcode/

Op/

64/32 bit

CPUID Feature

Description

Instruction

En

Mode

Flag

Support

F2 0F 01 E8

ZO

V/V

TSXLDTRK

Specifies the start of an Intel TSX suspend read

XSUSLDTRK

address tracking region.

Instruction Operand Encoding

Op/En

Tuple

Operand 1

Operand 2

Operand 3

Operand 4

ZO

N/A

N/A

N/A

N/A

N/A

Description

The instruction marks the start of an Intel TSX (RTM) suspend load address tracking region. If the instruction is

used inside a transactional region, subsequent loads are not added to the read set of the transaction. If the instruc-

tion is used inside a suspend load address tracking region it will cause transaction abort.

If the instruction is used outside of a transactional region it behaves like a NOP.

Chapter 16, “Programming with Intel® Transactional Synchronization Extensions‚” in the Intel^® 64 and IA-32

Architectures Software Developer’s Manual, Volume 1 provides additional information on Intel^® TSX Suspend Load

Address Tracking.

Operation

XSUSLDTRK

IF RTM_ACTIVE = 1:

IF SUSLDTRK_ACTIVE = 0:

SUSLDTRK_ACTIVE := 1

ELSE:

RTM_ABORT

ELSE:

NOP

Flags Affected

None.

Intel C/C++ Compiler Intrinsic Equivalent

XSUSLDTRK void _xsusldtrk(void);

SIMD Floating-Point Exceptions

None.

Other Exceptions

#UD

If CPUID.(EAX=7, ECX=0):EDX.TSXLDTRK[bit 16] = 0.

If the LOCK prefix is used.

6-68

Vol. 2D

XSUSLDTRK—Suspend Tracking Load Addresses

INSTRUCTION SET REFERENCE, W-Z

XTEST—Test if in Transactional Execution

Opcode/Instruction

Op/

64/32bit

CPUID

Description

En

Mode

Feature

Support

Flag

NP 0F 01 D6

ZO

V/V

HLE or

Test if executing in a transactional region.

XTEST

RTM

Instruction Operand Encoding

Op/En

Operand 1

Operand2

Operand3

Operand4

ZO

N/A

N/A

N/A

N/A

Description

The XTEST instruction queries the transactional execution status. If the instruction executes inside a transaction-

ally executing RTM region or a transactionally executing HLE region, then the ZF flag is cleared, else it is set.

Operation

XTEST

IF (RTM_ACTIVE = 1 OR HLE_ACTIVE = 1)

THEN

ZF := 0

ELSE

ZF := 1

FI;

Flags Affected

The ZF flag is cleared if the instruction is executed transactionally; otherwise it is set to 1. The CF, OF, SF, PF, and

AF, flags are cleared.

Intel C/C++ Compiler Intrinsic Equivalent

XTEST int _xtest( void );

SIMD Floating-Point Exceptions

None.

Other Exceptions

#UD

CPUID.(EAX=7, ECX=0):EBX.HLE[bit 4] = 0 and CPUID.(EAX=7, ECX=0):EBX.RTM[bit 11] =

0.

If LOCK prefix is used.

XTEST—Test if in Transactional Execution

Vol. 2D

6-69

CHAPTER 7

SAFER MODE EXTENSIONS REFERENCE

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)¹. The system

executive may be based on a Virtual Machine Monitor (VMM), a measured VMM is referred to as MVMM².

• 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[Bit 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.

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.

Vol. 2D

7-1

SAFER MODE EXTENSIONS REFERENCE

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.

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

Vol. 2D

SAFER MODE EXTENSIONS REFERENCE

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.

Vol. 2D

7-3

SAFER MODE EXTENSIONS REFERENCE

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[Bit 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 widths¹ 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.

Vol. 2D

7-5

SAFER MODE EXTENSIONS REFERENCE

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 present¹ 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.

7-6

Vol. 2D

SAFER MODE EXTENSIONS REFERENCE

GETSEC[CAPABILITIES]—Report the SMX Capabilities

Opcode

Instruction

Description

NP 0F 37

GETSEC[CAPABILITIES]

Report the SMX capabilities.

(EAX = 0)

The capabilities index is input in EBX with the result returned in EAX.

Description

The GETSEC[CAPABILITIES] function returns a bit vector of supported GETSEC leaf functions. The CAPABILITIES

leaf of GETSEC is selected with EAX set to 0 at entry. EBX is used as the selector for returning the bit vector field in

EAX. GETSEC[CAPABILITIES] may be executed at all privilege levels, but the CR4.SMXE bit must be set or an unde-

fined opcode exception (#UD) is returned.

With EBX = 0 upon execution of GETSEC[CAPABILITIES], EAX returns the a bit vector representing status on the

presence of a Intel^® TXT-capable chipset and the first 30 available GETSEC leaf functions. The format of the

returned bit vector is provided in Table 7-3.

If bit 0 is set to 1, then an Intel^® TXT-capable chipset has been sampled present by the processor. If bits in the range

of 1-30 are set, then the corresponding GETSEC leaf function is available. If the bit value at a given bit index is 0,

then the GETSEC leaf function corresponding to that index is unsupported and attempted execution results in a

#UD.

Bit 31 of EAX indicates if further leaf indexes are supported. If the Extended Leafs bit 31 is set, then additional leaf

functions are accessed by repeating GETSEC[CAPABILITIES] with EBX incremented by one. When the most signifi-

cant bit of EAX is not set, then additional GETSEC leaf functions are not supported; indexing EBX to a higher value

results in EAX returning zero.

Table 7-3. GETSEC Capability Result Encoding (EBX = 0)

Field

Bit position

Description

Chipset Present

0

Intel® TXT-capable chipset is present.

Undefined

1

Reserved

ENTERACCS

2

GETSEC[ENTERACCS] is available.

EXITAC

3

GETSEC[EXITAC] is available.

SENTER

4

GETSEC[SENTER] is available.

SEXIT

5

GETSEC[SEXIT] is available.

PARAMETERS

6

GETSEC[PARAMETERS] is available.

SMCTRL

7

GETSEC[SMCTRL] is available.

WAKEUP

8

GETSEC[WAKEUP] is available.

Undefined

30:9

Reserved

Extended Leafs

31

Reserved for extended information reporting of GETSEC capabilities.

GETSEC[CAPABILITIES]—Report the SMX Capabilities

Vol. 2D

7-7

SAFER MODE EXTENSIONS REFERENCE

GETSEC[ENTERACCS]—Execute Authenticated Chipset Code

Opcode

Instruction

Description

NP 0F 37

GETSEC[ENTERACCS]

Enter authenticated code execution mode.

(EAX = 2)

EBX holds the authenticated code module physical base address. ECX holds the authenticated

code module size (bytes).

Description

The GETSEC[ENTERACCS] function loads, authenticates, and executes an authenticated code module using an

Intel^® TXT platform chipset's public key. The ENTERACCS leaf of GETSEC is selected with EAX set to 2 at entry.

There are certain restrictions enforced by the processor for the execution of the GETSEC[ENTERACCS] instruction:

• Execution is not allowed unless the processor is in protected mode or IA-32e mode with CPL = 0 and

EFLAGS.VM = 0.

• Processor cache must be available and not disabled, that is, CR0.CD and CR0.NW bits must be 0.

• For processor packages containing more than one logical processor, CR0.CD is checked to ensure consistency

between enabled logical processors.

• For enforcing consistency of operation with numeric exception reporting using Interrupt 16, CR0.NE must be

set.

• An Intel TXT-capable chipset must be present as communicated to the processor by sampling of the power-on

configuration capability field after reset.

• The processor can not already be in authenticated code execution mode as launched by a previous

GETSEC[ENTERACCS] or GETSEC[SENTER] instruction without a subsequent exiting using GETSEC[EXITAC]).

• To avoid potential operability conflicts between modes, the processor is not allowed to execute this instruction

if it currently is in SMM or VMX operation.

• To ensure consistent handling of SIPI messages, the processor executing the GETSEC[ENTERACCS] instruction

must also be designated the BSP (boot-strap processor) as defined by IA32_APIC_BASE.BSP (Bit 8).

Failure to conform to the above conditions results in the processor signaling a general protection exception.

Prior to execution of the ENTERACCS leaf, other logical processors, i.e., RLPs, in the platform must be:

• Idle in a wait-for-SIPI state (as initiated by an INIT assertion or through reset for non-BSP designated

processors), or

• In the SENTER sleep state as initiated by a GETSEC[SENTER] from the initiating logical processor (ILP).

If other logical processor(s) in the same package are not idle in one of these states, execution of ENTERACCS

signals a general protection exception. The same requirement and action applies if the other logical processor(s) of

the same package do not have CR0.CD = 0.

A successful execution of ENTERACCS results in the ILP entering an authenticated code execution mode. Prior to

reaching this point, the processor performs several checks. These include:

• Establish and check the location and size of the specified authenticated code module to be executed by the

processor.

• Inhibit the ILP’s response to the external events: INIT, A20M, NMI, and SMI.

• Broadcast a message to enable protection of memory and I/O from other processor agents.

• Load the designated code module into an authenticated code execution area.

• Isolate the contents of the authenticated code execution area from further state modification by external

agents.

• Authenticate the authenticated code module.

• Initialize the initiating logical processor state based on information contained in the authenticated code module

header.

• Unlock the Intel^® TXT-capable chipset private configuration space and TPM locality 3 space.

7-10

Vol. 2D

GETSEC[ENTERACCS]—Execute Authenticated Chipset Code

SAFER MODE EXTENSIONS REFERENCE

A summary of the register state initialization after successful completion of GETSEC[ENTERACCS] is given for the

processor in Table 7-4. The paging is disabled upon entry into authenticated code execution mode. The authenti-

cated code module is loaded and initially executed using physical addresses. It is up to the system software after

execution of GETSEC[ENTERACCS] to establish a new (or restore its previous) paging environment with an appro-

priate mapping to meet new protection requirements. EBP is initialized to the authenticated code module base

physical address for initial execution in the authenticated environment. As a result, the authenticated code can

reference EBP for relative address based references, given that the authenticated code module must be position

independent.

Table 7-4. Register State Initialization After GETSEC[ENTERACCS]

Register State

Initialization Status

Comment

CR0

PG←0, AM←0, WP←0: Others unchanged

Paging, Alignment Check, Write-protection are

disabled.

CR4

MCE←0, CET←0, PCIDE←0: Others unchanged

Machine Check Exceptions, Control-flow

Enforcement Technology, and Process-context

Identifiers disabled.

EFLAGS

00000002H

IA32_EFER

0H

IA-32e mode disabled.

EIP

AC.base + EntryPoint

AC.base is in EBX as input to GETSEC[ENTERACCS].

[E|R]BX

Pre-ENTERACCS state: Next [E|R]IP prior to

Carry forward 64-bit processor state across

GETSEC[ENTERACCS]

GETSEC[ENTERACCS].

ECX

Pre-ENTERACCS state: [31:16]=GDTR.limit;

Carry forward processor state across

[15:0]=CS.sel

GETSEC[ENTERACCS].

[E|R]DX

Pre-ENTERACCS state:

Carry forward 64-bit processor state across

GDTR base

GETSEC[ENTERACCS].

EBP

AC.base

CS

Sel=[SegSel], base=0, limit=FFFFFh, G=1, D=1,

AR=9BH

DS

Sel=[SegSel] +8, base=0, limit=FFFFFh, G=1, D=1,

AR=93H

GDTR

Base= AC.base (EBX) + [GDTBasePtr],

Limit=[GDTLimit]

DR7

00000400H

IA32_DEBUGCTL

0H

IA32_MISC_ENABLE

See Table 7-5 for example.

The number of initialized fields may change due to

processor implementation.

Performance

0H

counters and

counter control

registers

The segmentation related processor state that has not been initialized by GETSEC[ENTERACCS] requires appro-

priate initialization before use. Since a new GDT context has been established, the previous state of the segment

selector values held in ES, SS, FS, GS, TR, and LDTR might not be valid.

7-12

Vol. 2D

GETSEC[ENTERACCS]—Execute Authenticated Chipset Code

SAFER MODE EXTENSIONS REFERENCE

The MSR IA32_EFER is also unconditionally cleared as part of the processor state initialized by ENTERACCS. Since

paging is disabled upon entering authenticated code execution mode, a new paging environment will have to be

reestablished in order to establish IA-32e mode while operating in authenticated code execution mode.

Debug exception and trap related signaling is also disabled as part of GETSEC[ENTERACCS]. This is achieved by

resetting DR7, TF in EFLAGs, and the MSR IA32_DEBUGCTL. These debug functions are free to be re-enabled once

supporting exception handler(s), descriptor tables, and debug registers have been properly initialized following

entry into authenticated code execution mode. Also, any pending single-step trap condition will have been cleared

upon entry into this mode.

Performance related counters and counter control registers are cleared as part of execution of ENTERACCS. This

implies any active performance counters at any time of ENTERACCS execution will be disabled. To reactive the

processor performance counters, this state must be re-initialized and re-enabled.

The IA32_MISC_ENABLE MSR is initialized upon entry into authenticated execution mode. Certain bits of this MSR

are preserved because preserving these bits may be important to maintain previously established platform settings

(See the footnote for Table 7-5.). The remaining bits are cleared for the purpose of establishing a more consistent

environment for the execution of authenticated code modules. One of the impacts of initializing this MSR is any

previous condition established by the MONITOR instruction will be cleared.

To support the possible return to the processor architectural state prior to execution of GETSEC[ENTERACCS],

certain critical processor state is captured and stored in the general- purpose registers at instruction completion.

[E|R]BX holds effective address ([E|R]IP) of the instruction that would execute next after GETSEC[ENTERACCS],

ECX[15:0] holds the CS selector value, ECX[31:16] holds the GDTR limit field, and [E|R]DX holds the GDTR base

field. The subsequent authenticated code can preserve the contents of these registers so that this state can be

manually restored if needed, prior to exiting authenticated code execution mode with GETSEC[EXITAC]. For the

processor state after exiting authenticated code execution mode, see the description of GETSEC[SEXIT].

Table 7-5. IA32_MISC_ENABLE MSR Initialization¹ by ENTERACCS and SENTER

Field

Bit position

Description

Fast strings enable

0

Clear to 0.

FOPCODE compatibility mode

2

Clear to 0.

enable

Thermal monitor enable

3

Set to 1 if other thermal monitor capability is not enabled.²

Split-lock disable

4

Clear to 0.

Bus lock on cache line splits

8

Clear to 0.

disable

Hardware prefetch disable

9

Clear to 0.

GV1/2 legacy enable

15

Clear to 0.

MONITOR/MWAIT s/m enable

18

Clear to 0.

Adjacent sector prefetch disable

19

Clear to 0.

NOTES:

1. The number of IA32_MISC_ENABLE fields that are initialized may vary due to processor implementations.

2. ENTERACCS (and SENTER) initialize the state of processor thermal throttling such that at least a minimum level is enabled. If thermal

throttling is already enabled when executing one of these GETSEC leaves, then no change in the thermal throttling control settings

will occur. If thermal throttling is disabled, then it will be enabled via setting of the thermal throttle control bit 3 as a result of execut-

ing these GETSEC leaves.

The IDTR will also require reloading with a new IDT context after entering authenticated code execution mode,

before any exceptions or the external interrupts INTR and NMI can be handled. Since external interrupts are re-

enabled at the completion of authenticated code execution mode (as terminated with EXITAC), it is recommended

GETSEC[ENTERACCS]—Execute Authenticated Chipset Code

Vol. 2D

7-13

SAFER MODE EXTENSIONS REFERENCE

GETSEC[EXITAC]—Exit Authenticated Code Execution Mode

Opcode

Instruction

Description

NP 0F 37

GETSEC[EXITAC]

Exit authenticated code execution mode.

(EAX=3)

RBX holds the Near Absolute Indirect jump target and EDX hold the exit parameter flags.

Description

The GETSEC[EXITAC] leaf function exits the ILP out of authenticated code execution mode established by

GETSEC[ENTERACCS] or GETSEC[SENTER]. The EXITAC leaf of GETSEC is selected with EAX set to 3 at entry. EBX

(or RBX, if in 64-bit mode) holds the near jump target offset for where the processor execution resumes upon

exiting authenticated code execution mode. EDX contains additional parameter control information. Currently only

an input value of 0 in EDX is supported. All other EDX settings are considered reserved and result in a general

protection violation.

GETSEC[EXITAC] can only be executed if the processor is in protected mode with CPL = 0 and EFLAGS.VM = 0. The

processor must also be in authenticated code execution mode. To avoid potential operability conflicts between

modes, the processor is not allowed to execute this instruction if it is in SMM or in VMX operation. A violation of

these conditions results in a general protection violation.

Upon completion of the GETSEC[EXITAC] operation, the processor unmasks responses to external event signals

INIT#, NMI#, and SMI#. This unmasking is performed conditionally, based on whether the authenticated code

execution mode was entered via execution of GETSEC[SENTER] or GETSEC[ENTERACCS]. If the processor is in

authenticated code execution mode due to the execution of GETSEC[SENTER], then these external event signals

will remain masked. In this case, A20M is kept disabled in the measured environment until the measured environ-

ment executes GETSEC[SEXIT]. INIT# is unconditionally unmasked by EXITAC. Note that any events that are

pending, but have been blocked while in authenticated code execution mode, will be recognized at the completion

of the GETSEC[EXITAC] instruction if the pin event is unmasked.

The intent of providing the ability to optionally leave the pin events SMI#, and NMI# masked is to support the

completion of a measured environment bring-up that makes use of VMX. In this envisioned security usage

scenario, these events will remain masked until an appropriate virtual machine has been established in order to

field servicing of these events in a safer manner. Details on when and how events are masked and unmasked in

VMX operation are described in Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3C. It

should be cautioned that if no VMX environment is to be activated following GETSEC[EXITAC], that these events

will remain masked until the measured environment is exited with GETSEC[SEXIT]. If this is not desired then the

GETSEC function SMCTRL(0) can be used for unmasking SMI# in this context. NMI# can be correspondingly

unmasked by execution of IRET.

A successful exit of the authenticated code execution mode requires the ILP to perform additional steps as outlined

below:

• Invalidate the contents of the internal authenticated code execution area.

• Invalidate processor TLBs.

• Clear the internal processor AC Mode indicator flag.

• Re-lock the TPM locality 3 space.

• Unlock the Intel^® TXT-capable chipset memory and I/O protections to allow memory and I/O activity by other

processor agents.

• Perform a near absolute indirect jump to the designated instruction location.

The content of the authenticated code execution area is invalidated by hardware in order to protect it from further

use or visibility. This internal processor storage area can no longer be used or relied upon after GETSEC[EXITAC].

Data structures need to be re-established outside of the authenticated code execution area if they are to be refer-

enced after EXITAC. Since addressed memory content formerly mapped to the authenticated code execution area

may no longer be coherent with external system memory after EXITAC, processor TLBs in support of linear to phys-

ical address translation are also invalidated.

7-18

Vol. 2D

GETSEC[EXITAC]—Exit Authenticated Code Execution Mode

SAFER MODE EXTENSIONS REFERENCE

GETSEC[SENTER]—Enter a Measured Environment

Opcode

Instruction

Description

NP 0F 37

GETSEC[SENTER]

Launch a measured environment.

(EAX=4)

EBX holds the SINIT authenticated code module physical base address.

ECX holds the SINIT authenticated code module size (bytes).

EDX controls the level of functionality supported by the measured environment launch.

Description

The GETSEC[SENTER] instruction initiates the launch of a measured environment and places the initiating logical

processor (ILP) into the authenticated code execution mode. The SENTER leaf of GETSEC is selected with EAX set

to 4 at execution. The physical base address of the AC module to be loaded and authenticated is specified in EBX.

The size of the module in bytes is specified in ECX. EDX controls the level of functionality supported by the

measured environment launch. To enable the full functionality of the protected environment launch, EDX must be

initialized to zero.

The authenticated code base address and size parameters (in bytes) are passed to the GETSEC[SENTER] instruc-

tion using EBX and ECX respectively. The ILP evaluates the contents of these registers according to the rules for the

AC module address in GETSEC[ENTERACCS]. AC module execution follows the same rules, as set by

GETSEC[ENTERACCS].

The launching software must ensure that the TPM.ACCESS_0.activeLocality bit is clear before executing the

GETSEC[SENTER] instruction.

There are restrictions enforced by the processor for execution of the GETSEC[SENTER] instruction:

• Execution is not allowed unless the processor is in protected mode or IA-32e mode with CPL = 0 and

EFLAGS.VM = 0.

• Processor cache must be available and not disabled using the CR0.CD and NW bits.

• For enforcing consistency of operation with numeric exception reporting using Interrupt 16, CR0.NE must be

set.

• An Intel TXT-capable chipset must be present as communicated to the processor by sampling of the power-on

configuration capability field after reset.

• The processor can not be in authenticated code execution mode or already in a measured environment (as

launched by a previous GETSEC[ENTERACCS] or GETSEC[SENTER] instruction).

• To avoid potential operability conflicts between modes, the processor is not allowed to execute this instruction

if it currently is in SMM or VMX operation.

• To ensure consistent handling of SIPI messages, the processor executing the GETSEC[SENTER] instruction

must also be designated the BSP (boot-strap processor) as defined by IA32_APIC_BASE.BSP (Bit 8).

• EDX must be initialized to a setting supportable by the processor. Unless enumeration by the GETSEC[PARAM-

ETERS] leaf reports otherwise, only a value of zero is supported.

Failure to abide by the above conditions results in the processor signaling a general protection violation.

This instruction leaf starts the launch of a measured environment by initiating a rendezvous sequence for all logical

processors in the platform. The rendezvous sequence involves the initiating logical processor sending a message

(by executing GETSEC[SENTER]) and other responding logical processors (RLPs) acknowledging the message,

thus synchronizing the RLP(s) with the ILP.

In response to a message signaling the completion of rendezvous, RLPs clear the bootstrap processor indicator flag

(IA32_APIC_BASE.BSP) and enter an SENTER sleep state. In this sleep state, RLPs enter an idle processor condi-

tion while waiting to be activated after a measured environment has been established by the system executive.

RLPs in the SENTER sleep state can only be activated by the GETSEC leaf function WAKEUP in a measured environ-

ment.

GETSEC[SENTER]—Enter a Measured Environment

Vol. 2D

7-21

SAFER MODE EXTENSIONS REFERENCE

Table 7-6. Register State Initialization After GETSEC[SENTER] and GETSEC[WAKEUP]

Register State

ILP after GETSEC[SENTER]

RLP after GETSEC[WAKEUP]

CR0

PG←0, AM←0, WP←0; Others unchanged

PG←0, CD←0, NW←0, AM←0, WP←0; PE←1, NE←1

CR4

00004000H

00004000H

EFLAGS

00000002H

00000002H

IA32_EFER

0H

0

EIP

[EntryPoint from MLE header¹]

[LT.MLE.JOIN + 12]

EBX

Unchanged [SINIT.BASE]

Unchanged

EDX

SENTER control flags

Unchanged

EBP

SINIT.BASE

Unchanged

CS

Sel=[SINIT SegSel], base=0, limit=FFFFFh, G=1,

Sel = [LT.MLE.JOIN + 8], base = 0, limit = FFFFFH, G =

D=1, AR=9BH

1, D = 1, AR = 9BH

DS, ES, SS

Sel=[SINIT SegSel] +8, base=0, limit=FFFFFh, G=1,

Sel = [LT.MLE.JOIN + 8] +8, base = 0, limit = FFFFFH,

D=1, AR=93H

G = 1, D = 1, AR = 93H

GDTR

Base= SINIT.base (EBX) + [SINIT.GDTBasePtr],

Base = [LT.MLE.JOIN + 4], Limit = [LT.MLE.JOIN]

Limit=[SINIT.GDTLimit]

DR7

00000400H

00000400H

IA32_DEBUGCTL

0H

0H

Performance

0H

0H

counters and counter

control registers

IA32_MISC_ENABLE

See Table 7-5

See Table 7-5

IA32_SMM_MONITOR

Bit 2←0

Bit 2←0

_CTL

NOTES:

1. See the Intel® Trusted Execution Technology Measured Launched Environment Programming Guide for MLE header format.

Segmentation related processor state that has not been initialized by GETSEC[SENTER] requires appropriate

initialization before use. Since a new GDT context has been established, the previous state of the segment selector

values held in FS, GS, TR, and LDTR may no longer be valid. The IDTR will also require reloading with a new IDT

context after launching the measured environment before exceptions or the external interrupts INTR and NMI can

be handled. In the meantime, the programmer must take care in not executing an INT n instruction or any other

condition that would result in an exception or trap signaling.

Debug exception and trap related signaling is also disabled as part of execution of GETSEC[SENTER]. This is

achieved by clearing DR7, TF in EFLAGs, and the MSR IA32_DEBUGCTL as defined in Table 7-6. These can be re-

enabled once supporting exception handler(s), descriptor tables, and debug registers have been properly re-initial-

ized following SENTER. Also, any pending single-step trap condition will be cleared at the completion of SENTER for

both the ILP and RLP(s).

Performance related counters and counter control registers are cleared as part of execution of SENTER on both the

ILP and RLP. This implies any active performance counters at the time of SENTER execution will be disabled. To

reactive the processor performance counters, this state must be re-initialized and re-enabled.

Since MCE along with all other state bits (with the exception of SMXE) are cleared in CR4 upon execution of SENTER

processing, any enabled machine check error condition that occurs will result in the processor performing the TXT-

shutdown action. This also applies to an RLP while in the SENTER sleep state. For each logical processor CR4.MCE

7-24

Vol. 2D

GETSEC[SENTER]—Enter a Measured Environment

Content      ..     119      120      121      122     ..