42-4 Vol. 3D

INTEL® SGX INTERACTIONS WITH IA32 AND INTEL® 64 ARCHITECTURE

42.5.3 

Interactions with APIC Virtualization

This section applies to Intel SGX in VMX non-root operation when the “virtualize APIC accesses” VM-execution 
control is 1.
A memory access by an enclave instruction that implicitly uses a cached physical address is never checked for 
overlap with the APIC-access page. Such accesses never cause APIC-access VM exits and are never redirected to 
the virtual-APIC page. Implicit memory accesses can only be made to the SECS, the TCS, or the SSA of an enclave 
(see Section 38.5.3.2). 
An explicit Enclave Access (a linear memory access which is either from within an enclave into its ELRANGE, or an 
access by an Intel SGX instruction that is expected to be in the EPC) that overlaps with the APIC-access page 
causes a #PF exception (APIC page is expected to be outside of EPC). 
Non-Enclave accesses made either by an Intel SGX instruction or by a logical processor inside an enclave to an 
address that without SGX would have caused redirection to the virtual-APIC page instead cause an APIC-access 
VM exit. 
Other than implicit accesses made by Intel SGX instructions, guest-physical and physical accesses are not consid-
ered “enclave accesses”; consequently, such accesses result in undefined behavior if these accesses eventually 
reach EPC. This applies to any non-enclave physical accesses.
While a logical processor is executing inside an enclave, an attempt to execute an instruction outside of ELRANGE 
results in a #GP(0), even if the linear address would translate to a physical address that overlaps the APIC-access 
page. 

42.6 

INTEL® SGX INTERACTIONS WITH ARCHITECTURALLY-VISIBLE EVENTS

All architecturally visible vectored events (IA32 exceptions, interrupts, SMI, NMI, INIT, VM exit) can be detected 
while inside an enclave and will cause an asynchronous enclave exit if they are not blocked. Additionally, INT3, and 
the SignalTXTMsg[SENTER] (i.e. GETSEC[SENTER]’s rendezvous event message) events also cause asynchronous 
enclave exits. Note that SignalTXTMsg[SEXIT] (i.e. GETSEC[SEXIT]’s teardown message) does not cause an AEX. 
On an AEX, information about the event causing the AEX is stored in the SSA (see Section 40.4 for details of AEX). 
The information stored in the SSA only describes the first event that triggered the AEX. If parsing/delivery of the 
first event results in detection of further events (e.g. VM exit, double fault, etc.), then the event information in the 
SSA is not updated to reflect these subsequently detected events. 

42.7 INTERACTIONS 

WITH 

THE 

PROCESSOR EXTENDED STATE AND 

MISCELLANEOUS STATE

42.7.1 

Requirements and Architecture Overview

Processor extended states are the ISA features that are enabled by the settings of CR4.OSXSAVE and the XCR0 
register. Processor extended states are normally saved/restored by software via XSAVE/XRSTOR instructions. 
Details of discovery of processor extended states and management of these states are described in CHAPTER 13 of 
Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A. 
Additionally, the following requirements apply to Intel SGX:

•

On an AEX, the Intel SGX architecture must protect the processor extended state and miscellaneous state by 
saving them in the enclave’s state-save area (SSA), and clear the secrets from the processor extended state 
that is used by an enclave. 

•

Intel SGX architecture must verify that the SSA frame size is large enough to contain all the processor extended 
states and miscelaneous state used by the enclave.

•

Intel SGX architecture must ensure that enclaves can only use processor extended state that is enabled by 
system software in XCR0.