Intel SGX

Intel’s Software Guard Extensions (SGX) is a set of extensions to the Intel architecture that aims to provide integrity and confidentiality guarantees to security-sensitive computation performed on a computer where all the privileged software (kernel, hypervisor, etc) is potentially malicious.

SGX Physical Memory Organization

The enclaves’ code and data is stored in Processor Reserved Memory (PRM), which is a subset of DRAM that cannot be directly accessed by other software, including system software and SMM code. The CPU’s integrated memory controllers also reject DMA transfers targeting the PRM, thus protecting it from access by other peripherals.

PRM range registers (PRMRR)

The Enclave Page Cache (EPC)

The contents of enclaves and the associated data struc- tures are stored in the Enclave Page Cache (EPC), which is a subset of the PRM.

The EPC is managed by the same system software that manages the rest of the computer’s physical memory.

Non-enclave software cannot directly access the EPC, as it is contained in the PRM. This restriction plays a key role in SGX’s enclave isolation guarantees, but creates an obstacle when the system software needs to load the initial code and data into a newly created enclave. The SGX design solves this problem by having the instructions that allocate an EPC page to an enclave also initialize the page. Most EPC pages are initialized by copying data from a non-PRM memory page.

The Enclave Page Cache Map (EPCM)

SGX processors check the correctness of the system software’s allocation decisions, and refuse to perform any action that would compromise SGX’s security guarantees. For example, if the system software attempts to allocate the same EPC page to two enclaves, the SGX instruction used to perform the allocation will fail.

SGX records some information about the system software’s allocation decisions for each EPC page in the Enclave Page Cache Map (EPCM).

The EPCM’s contents is only used by SGX’s security checks.

The fields in an EPCM entry that track the ownership of pages.

Field | bit | Dscription

• VALID | 1 | 0 for un-allocated EPC pages
• PT | 8 | page type
• ENCLAVESECS | identifies the enclave owning the page

A page’s EPCM entry also identifies the enclave that owns the EPC page. This information is used by the mechanisms that enforce SGX’s isolation guarantees to prevent an enclave from accessing another enclave’s private information.

The SGX Enclave Control Structure (SECS)

SGX stores per-enclave metadata in a SGX Enclave Control Structure (SECS) associated with each enclave. These pages are not intended to be mapped into any enclave’s address space, and are exclusively used by the CPU’s SGX implementation.

The EPCM entry field identifying the enclave that owns an EPC page points to the enclave’s SECS. The system software uses the virtual address of an enclave’s SECS to identify the enclave when invoking SGX instructions.

All SGX instructions take virtual addresses as their inputs. Given that SGX instructions use SECS addresses to identify enclaves, the system software must create entries in its page tables pointing to the SECS of the enclaves it manages.

The Memory Layout of an SGX Enclave

The Enclave Linear Address Range (ELRANGE)

Each enclave designates an area in its virtual address space, called the enclave linear address range (ELRANGE), which is used to map the code and the sensitive data stored in the enclave’s EPC pages.

When an enclave represents a dynamic library, it is natural to set ELRANGE to the memory range reserved for the library by the loader. The ability to access non-enclave memory from enclave code makes it easy to reuse existing library code that expects to work with pointers to memory buffers managed by code in the host process.

ELRANGE is specified using a base (the BASEADDR field) and a size (the SIZE) in the enclave’s SECS.

SGX Enclave Attributes

• DEBUG flag
  it enables the use of SGX’s debugging features for this enclave. These debugging features include the ability to read and modify most of the enclave’s memory. Therefore, DEBUG should only be set in a development environment, as it causes the enclave to lose all the SGX security guarantees.
• XFRM flag
• MODE64BIT flag

Address Translation for SGX Enclaves

Operating system and hypervisor are still in full control of the page tables and EPTs, and each enclave’s code uses the same address translation process and page tables as its host application.

At the same time, having the page tables managed by untrusted system software opens SGX up to the address translation attacks described. As future sections will reveal, a good amount of the complexity in SGX’s design can be attributed to the need to prevent these attacks.

SGX’s active memory mapping attacks defense mechanisms revolve around ensuring that each EPC page can only be mapped at a specific virtual address. When an EPC page is allocated, its intended virtual address is recorded in the EPCM entry for the page, in the ADDRESS field.

SGX also protects against some passive memory mapping attacks and fault injection attacks by ensuring that the access permissions of each EPC page always match the enclave author’s intentions. The access permissions for each EPC page are specified when the page is allocated, and recorded in the readable (R), writable (W), and executable (X) fields in the page’s EPCM entry. When an address translation resolves into an EPC page, the corresponding EPCM entry’s fields override the access permission attributes specified in the page tables.

Last, a SGX-enabled CPU will ensure that the virtual memory inside ELRANGE is mapped to EPC pages. This prevents the system software from carrying out an address translation attack where it maps the enclave’s entire virtual address space to DRAM pages outside the PRM, which do not trigger any of the checks above, and can be directly accessed by the system soft- ware.

The Thread Control Structure (TCS)

The SGX implementation uses a Thread Control Struc- ture (TCS) for each logical processor that executes an enclave’s code.

Each TCS is stored in a dedicated EPC page whose EPCM entry type is PT TCS.

The contents of an EPC page that holds a TCS cannot be directly accessed, even by the code of the enclave that owns the TCS. This restriction is similar to the restriction on accessing EPC pages holding SECS instances.

The architectural fields in the TCS lay out the context switches performed by a logical processor when it transitions between executing non-enclave and enclave code.

The State Save Area (SSA)

In the SGX design, the area used to store an enclave thread’s execution context while a hardware exception is handled is called a State Save Area (SSA).

Each TCS references a contiguous sequence of SSAs. The offset of the SSA array (OSSA) field specifies the location of the first SSA in the enclave’s virtual address space. The number of SSAs (NSSA) field indicates the number of available SSAs.

SSAs are stored in regular EPC pages, whose EPCM page type is PT REG.

A possible layout of an enclave’s virtual address space

Each enclave has a SECS, and one TCS per supported concurrent thread. Each TCS points to a sequence of SSAs, and specifies initial values for RIP and for the base addresses of FS and GS.