Vol. 3D 42-5

INTEL® SGX INTERACTIONS WITH IA32 AND INTEL® 64 ARCHITECTURE

•

Enclave software should be able to discover only those processor extended state and miscellaneous state for 
which such protection is enabled.

•

The processor extended states that are enabled inside the enclave must be approved by the enclave developer:
— Certain processor extended state (e.g., Memory Protection Extensions, see Chapter 17, “Intel® MPX” of 

Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1) modify the behavior of the 
legacy ISA software. If such features are enabled for enclaves that do not understand those features, then 
such a configuration could lead to a compromise of the enclave's security. 

•

The processor extended states that are enabled inside the enclave must form an integral part of the enclave's 
identity. This requirement has two implications:
— Service providers may decide to assign different trust level to the same enclave depending on the ISA 

features the enclave is using.

To meet these requirements, the Intel SGX architecture defines a sub-field called X-Feature Request Mask (XFRM) 
in the ATTRIBUTES field of the SECS. On enclave creation (ENCLS[ECREATE] leaf function), the required SSA frame 
size is calculated by the processor from the list of enabled extended and miscellaneous states and verified against 
the actual SSA frame size defined by SECS.SSAFRAMESIZE. 
On enclave entry, after verifying that XFRM is only enabling features that are already enabled in XCR0, the value in 
the XCR0 is saved internally by the processor, and is replaced by the XFRM. On enclave exit, the original value of 
XCR0 is restored. Consequently, while inside the enclave, the processor extended states enabled in XFRM are in 
enabled state, and those that are disabled in XFRM are in disabled state. 
The entire ATTRIBUTES field, including the XFRM subfield is integral part of enclave's identity (i.e., its value is 
included in reports generated by ENCLU[EREPORT], and select bits from this field can be included in key-derivation 
for keys obtained via the ENCLU[EGETKEY] leaf function).
Enclave developers can create their enclave to work with certain features and fallback to another code path in case 
those features aren't available (e.g. optimize for AVX and fallback to SSE). For this purpose Intel SGX provides the 
following fields in SIGSTRUCT: ATTRIBUTES, ATTRIBUTESMASK, MISCSELECT, and MISCMASK. EINIT ensures that 
the final SECS.ATTRIBUTES and SECS.MISCSELECT comply with the enclave developer's requirements as follows:
SIGSTRUCT.ATTRIBUTES & SIGSTRUCT.ATTRIBUTEMASK = SECS.ATTRIBUTES & SIGSTRUCT.ATTRIBUTEMASK
SIGSTRUCT.MISCSELECT & SIGSTRUCT.MISCMASK = SECS.MISCSELECT & SIGSTRUCT.MISCMASK.
On an asynchronous enclave exit, the processor extended states enabled by XFRM are saved in the current SSA 
frame, and overwritten by synthetic state (see Section 40.3 for the definition of the synthetic state). When the 
interrupted enclave is resumed via the ENCLU[ERESUME] leaf function, the saved state for processor extended 
states enabled by XFRM is restored.

42.7.2 

Relevant Fields in Various Data Structures

42.7.2.1   SECS.ATTRIBUTES.XFRM

The ATTRIBUTES field of the SECS data structure (see Section 38.7) contains a sub-field called XSAVE-Feature 
Request Mask (XFRM). Software populates this field at the time of enclave creation according to the features that 
are enabled by the operating system and approved by the enclave developer.
Intel SGX architecture guarantees that during enclave execution, the processor extended state configuration of the 
processor is identical to what is required by the XFRM sub-field. All the processor extended states enabled in XFRM 
are saved on AEX from the enclave and restored on ERESUME.
The XFRM sub-field has the same layout as XCR0, and has consistency requirements that are similar to those for 
XCR0. Specifically, the consistency requirements on XFRM values depend on the processor implementation and the 
set of features enabled in CR4.
Legal values for SECS.ATTRIBUTES.XFRM conform to these requirements:

•

XFRM[1:0] must be set to 0x3. 

•

If the processor does not support XSAVE, or if the system software has not enabled XSAVE, then XFRM[63:2] 
must be zero. 

•

If the processor does support XSAVE, XFRM must contain a value that would be legal if loaded into XCR0.