"深度解析Intel SGX：保障计算机安全性的最详实材料"

需积分: 20 93 浏览量更新于2023-12-24 收藏 2.27MB PDF 举报

Intel SGX Explained.pdf is the most comprehensive and detailed material on Intel SGX, written by Victor Costan and Srinivas Devadas from the Computer Science and Artificial Intelligence Laboratory at the Massachusetts Institute of Technology. The paper delves into Intel's Software Guard Extensions (SGX), 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. The authors provide an in-depth analysis of Intel SGX, discussing its design principles, architecture, security guarantees, and potential applications. They explain how SGX allows developers to create secure enclaves within a computer's memory, where sensitive computations can be performed with confidentiality and integrity, even in the presence of malicious privileged software. The paper also covers the threat model for SGX, discussing potential attacks and mitigations, as well as the challenges and limitations of using SGX for secure computation. The authors discuss the trade-offs involved in using SGX, including the performance impact and the need for careful development practices to ensure the security of enclave code. Overall, "Intel SGX Explained.pdf" provides a comprehensive and detailed understanding of Intel SGX, making it an essential resource for researchers, developers, and security professionals looking to leverage SGX for secure computation. With its thorough analysis and insightful discussion, the paper serves as a valuable guide for understanding the technical aspects of SGX and its potential impact on the field of computer security.

the Serial Programming Interface (SPI) used by the PCH

to communicate with the ﬂash memory.

The PCIe bus is an extended, point-to-point version

of the PCI standard, which provides a method for any

peripheral connected to the bus to perform Direct Mem-

ory Access (DMA), transferring data to and from DRAM

without involving an execution core and spending CPU

cycles. The PCI standard includes a conﬁguration mech-

anism that assigns a range of DRAM to each peripheral,

but makes no provisions for restricting a peripheral’s

DRAM accesses to its assigned range.

Network interfaces consist of a physical (PHY) mod-

ule that converts the analog signals on the network me-

dia to and from digital bits, and a Media Access Con-

trol (MAC) module that implements a network-level pro-

tocol. Modern Intel-based motherboards forego a full-

ﬂedged NIC, and instead include an Ethernet [

] PHY

module.

2.9.2 The Intel Management Engine (ME)

Intel’s Management Engine (ME) is an embedded com-

puter that was initially designed for remote system man-

agement and troubleshooting of server-class systems that

are often hosted in data centers. However, all of Intel’s

recent PCHs contain an ME [

], and it currently plays a

crucial role in platform bootstrapping, which is described

in detail in

2.13. Most of the information in this section

is obtained from an Intel-sponsored book [162].

The ME is part of Intel’s Active Management Tech-

nology (AMT), which is marketed as a convenient way

for IT administrators to troubleshoot and ﬁx situations

such as failing hardware, or a corrupted OS installation,

without having to gain physical access to the impacted

computer.

The Intel ME, shown in Figure 21, remains functional

during most hardware failures because it is an entire

embedded computer featuring its own execution core,

bootstrap ROM, and internal RAM. The ME can be used

for troubleshooting effectively thanks to an array of abil-

ities that include overriding the CPU’s boot vector and a

DMA engine that can access the computer’s DRAM. The

ME provides remote access to the computer without any

CPU support because it can use the System Management

bus (SMBus) to access the motherboard’s Ethernet PHY

or an AMT-compatible NIC [100].

The Intel ME is connected to the motherboard’s power

supply using a power rail that stays active even when the

host computer is in the Soft Off mode [

100

], known as

ACPI G2/S5, where most of the computer’s components

Intel PCH

Intel ME

I-Cache

D-Cache

DMA

Engine

Internal

SRAM

DRAM

Access

Execution

Core

HECI

Controller

Internal Bus

SMBus

Controller

SPI

Controller

Interrupt

Controller

Boot

ROM

Watchdog

Timer

Crypto

Accelerator

Ethernet

MAC

PCIe

Controller

USB

Controller

Audio

Controller

Ethernet

PHY

PCIe

lanes

Audio, MIC

Bluetooth

USB

PHY

Integrated

Sensor Hub

SPI

Bus

I2C

UART

Figure 21

: The Intel Management Engine (ME) is an embedded

computer hosted in the PCH. The ME has its own execution core,

ROM and SRAM. The ME can access the host’s DRAM via a memory

controller and a DMA controller. The ME is remotely accessible

over the network, as it has direct access to an Ethernet PHY via the

SMBus.

are powered off [

], including the CPU and DRAM.

For all practical purposes, this means that the ME’s exe-

cution core is active as long as the power supply is still

connected to a power source.

In S5, the ME cannot access the DRAM, but it can

still use its own internal memories. The ME can also still

communicate with a remote party, as it can access the

motherboard’s Ethernet PHY via SMBus. This enables

applications such as AMT’s theft prevention, where a

laptop equipped with a cellular modem can be tracked

and permanently disabled as long as it has power and

signal.

As the ME remains active in deep power-saving modes,

its design must rely on low-power components. The exe-

cution core is an Argonaut RISC Core (ARC) clocked at

200-400MHz, which is typically used in low-power em-

bedded designs. On a very recent PCH [

100

], the internal

SRAM has 640KB, and is shared with the Integrated Sen-

sor Hub (ISH)’s core. The SMBus runs at 1MHz and,

without CPU support, the motherboard’s Ethernet PHY

runs at 10Mpbs.

When the host computer is powered on, the ME’s exe-

cution core starts running code from the ME’s bootstrap

ROM. The bootstrap code loads the ME’s software stack

from the same ﬂash chip that stores the host computer’s

ﬁrmware. The ME accesses the ﬂash memory chip via

an embedded SPI controller.

2.9.3 The Processor Die

An Intel processor’s die, illustrated in Figure 22, is di-

vided into two broad areas: the core area implements the

instruction execution pipeline typically associated with

CPUs, while the uncore provides functions that were

traditionally hosted on separate chips, but are currently

integrated on the CPU die to reduce latency and power

consumption.

Chip Package

Core Core

L3 Cache

Graphics

Unit

Memory

Controller

Home Agent

I/O Controller

I/O to Ring

QPI

Packetizer

QPI Router

DRAM

DDR3

Platform Controller Hub NIC

DMI

PCI-X

CPU

QPI

IOAPIC

CPU

Conﬁg

Power

Unit

Figure 22

: The major components in a modern CPU package.

2.9.3 gives an uncore overview.

2.9.4 describes execution cores.

§ 2.11.3 takes a deeper look at the uncore.

At a conceptual level, the uncore of modern proces-

sors includes an integrated memory controller (iMC) that

interfaces with the DDR bus, an integrated I/O controller

(IIO) that implements PCIe bus lanes and interacts with

the DMI bus, and a growing number of integrated pe-

ripherals, such as a Graphics Processing Unit (GPU).

The uncore structure is described in some processor fam-

ily datasheets [

], and in the overview sections in

Intel’s uncore performance monitoring documentation

[37, 90, 94].

Security extensions to the Intel architecture, such as

Trusted Execution Technology (TXT) [

] and Software

Guard Extensions (SGX) [

139

], rely on the fact that

the processor die includes the memory and I/O controller,

and thus can prevent any device from accessing protected

memory areas via Direct Memory Access (DMA) trans-

fers.

2.11.3 takes a deeper look at the uncore organiza-

tion and at the machinery used to prevent unauthorized

DMA transfers.

2.9.4 The Core

Virtually all modern Intel processors have core areas con-

sisting of multiple copies of the execution core circuitry,

each of which is called a core. At the time of this writing,

desktop-class Intel CPUs have 4 cores, and server-class

CPUs have as many as 18 cores.

Most Intel CPUs feature hyper-threading, which

means that a core (shown in Figure 23) has two copies

of the register ﬁles backing the execution context de-

scribed in

2.6, and can execute two separate streams of

instructions simultaneously. Hyper-threading reduces the

impact of memory stalls on the utilization of the fetch,

decode and execution units.

Execution Units

INT INTINT

FP SSE

MEM

SSE

I-Cache

Instruction Scheduler

Decode

D-Cache

Cache

Logical CPU

LAPIC

Registers

I-TLB

Logical CPU

LAPIC

Registers

D-TLB

Page Miss Handler (PMH)

Fetch

Microcode

TLB

Figure 23

: CPU core with two logical processors. Each logical

processor has its own execution context and LAPIC (

2.12). All the

other core resources are shared.

A hyper-threaded core is exposed to system software

as two logical processors (LPs), also named hardware

threads in the Intel documentation. The logical proces-

sor abstraction allows the code used to distribute work

across processors in a multi-processor system to func-

tion without any change on multi-core hyper-threaded

processors.

The high level of resource sharing introduced by

hyper-threading introduces a security vulnerability. Soft-

ware running on one logical processor can use the high-

resolution performance counter (

RDTSCP

2.4) [

152

]

to get information about the instructions and memory ac-

cess patterns of another piece of software that is executed

on the other logical processor on the same core.

That being said, the biggest downside of hyper-

threading might be the fact that writing about Intel pro-

cessors in a rigorous manner requires the use of the cum-

bersome term Logical Processor instead of the shorter

and more intuitive “CPU core”, which can often be ab-

breviated to “core”.

2.10 Out-of-Order and Speculative Execution

CPU cores can execute instructions orders of magni-

tude faster than DRAM can read data. Computer archi-

tects attempt to bridge this gap by using hyper-threading

(

2.9.3), out-of-order and speculative execution, and

caching, which is described in

2.11. In CPUs that

use out-of-order execution, the order in which the CPU

carries out a program’s instructions (execution order) is

not necessarily the same as the order in which the in-

structions would be executed by a sequential evaluation

system (program order).

An analysis of a system’s information leakage must

take out-of-order execution into consideration. Any CPU

actions observed by an attacker match the execution

order, so the attacker may learn some information by

comparing the observed execution order with a known

program order. At the same time, attacks that try to infer

a victim’s program order based on actions taken by the

CPU must account for out-of-order execution as a source

of noise.

This section summarizes the out-of-order and specu-

lative execution concepts used when reasoning about a

system’s security properties. [

150

] and [

] cover the

concepts in great depth, while Intel’s optimization man-

ual [96] provides details speciﬁc to Intel CPUs.

Figure 24 provides a more detailed view of the CPU

core components involved in out-of-order execution, and

omits some less relevant details from Figure 23.

The Intel architecture deﬁnes a complex instruction

set (CISC). However, virtually all modern CPUs are ar-

chitected following reduced instruction set (RISC) prin-

ciples. This is accomplished by having the instruction

decode stages break down each instruction into micro-

ops, which resemble RISC instructions. The other stages

of the execution pipeline work exclusively with micro-

ops.

2.10.1 Out-of-Order Execution

Different types of instructions require different logic

circuits, called functional units. For example, the arith-

metic logic unit (ALU), which performs arithmetic op-

erations, is completely different from the load and store

unit, which performs memory operations. Different cir-

cuits can be used at the same time, so each CPU core can

execute multiple micro-ops in parallel.

The core’s out-of-order engine receives decoded

micro-ops, identiﬁes the micro-ops that can execute in

parallel, assigns them to functional units, and combines

the outputs of the units so that the results are equiva-

lent to having the micro-ops executed sequentially in the

order in which they come from the decode stages.

For example, consider the sequence of pseudo micro-

Memory

Execution

Out of Order Engine

Instruction

Fetch Unit

Branch

Predictors

L1 I-TLB

Reservation Station

Integer ALU

Shift

Integer ALU

LEA

FMA

FP Multiply

Vector

Logicals

Branch

Divide

Vector Shift

Integer

Vector

Multiply

FMA

FP Multiply

Integer

Vector

ALU

Vector

Logicals

FP Addition

Load &

Store

Address

Store

Data

Integer ALU

LEA

Vector

Shufﬂe

Vector

Logicals

Integer ALU

Shift

Branch

Store

Address

Port 0

Port 1

Ports 2, 3

Port 4

Port 5

Port 6

Port 7

L1 I-Cache

Pre-Decode Fetch Buffer

Instruction Queue

Simple

Decoders

Complex

Decoder

Micro-op Decode Queue

Microcode

ROM

Micro-op

Cache

Renamer

Files

Reorder

Buffer

Load

Buffer

Store

Buffer

Scheduler

L1 D-Cache L2 D-Cache

Integer

Vector

ALU

Memory Control

Instruction Decode

L1 D-TLB

Fill Buffers

Figure 24

: The structures in a CPU core that are relevant to out-

of-order and speculative execution. Instructions are decoded into

micro-ops, which are scheduled on one of the execution unit’s ports.

The branch predictor enables speculative execution when a branch is

encountered.

ops

in Table 5 below. The

uses the result of the

LOAD

, but the

ADD

does not. Therefore, a good scheduler

can have the load store unit execute the

LOAD

and the

ALU execute the ADD, all in the same clock cycle.

The out-of-order engine in recent Intel CPUs works

roughly as follows. Micro-ops received from the decode

queue are written into a reorder buffer (ROB) while they

are in-ﬂight in the execution unit. The register allocation

table (RAT) matches each register with the last reorder

buffer entry that updates it. The renamer uses the RAT

to rewrite the source and destination ﬁelds of micro-ops

when they are written in the ROB, as illustrated in Tables

The set of micro-ops used by Intel CPUs is not publicly docu-

mented. The ﬁctional examples in this section sufﬁce for illustration

purposes.

# Micro-op Meaning

1 LOAD RAX, RSI RAX ← DRAM[RSI]

2 OR RDI, RDI, RAX RDI ← RDI ∨ RAX

3 ADD RSI, RSI, RCX RSI ← RSI + RCX

4 SUB RBX, RSI, RDX RBX ← RSI - RDX

Table 5: Pseudo micro-ops for the out-of-order execution example.

6 and 7. Note that the ROB representation makes it easy

to determine the dependencies between micro-ops.

# Op Source 1 Source 2 Destination

1 LOAD RSI ∅ RAX

2 OR RDI ROB #1 RSI

3 ADD RSI RCX RSI

4 SUB ROB # 3 RDX RBX

Table 6

: Data written by the renamer into the reorder buffer (ROB),

for the micro-ops in Table 5.

ROB # #1 #4 ∅ ∅ #3 #2

Table 7

: Relevant entries of the register allocation table after the

micro-ops in Table 5 are inserted into the ROB.

The scheduler decides which micro-ops in the ROB

get executed, and places them in the reservation station.

The reservation station has one port for each functional

unit that can execute micro-ops independently. Each

reservation station port port holds one micro-op from

the ROB. The reservation station port waits until the

micro-op’s dependencies are satisﬁed and forwards the

micro-op to the functional unit. When the functional unit

completes executing the micro-op, its result is written

back to the ROB, and forwarded to any other reservation

station port that depends on it.

The ROB stores the results of completed micro-ops un-

til they are retired, meaning that the results are committed

to the register ﬁle and the micro-ops are removed from

the ROB. Although micro-ops can be executed out-of-

order, they must be retired in program order, in order to

handle exceptions correctly. When a micro-op causes a

hardware exception (

2.8.2), all the following micro-ops

in the ROB are squashed, and their results are discarded.

In the example above, the

ADD

can complete before

the

LOAD

, because it does not require a memory access.

However, the ADD’s result cannot be committed before

LOAD

completes. Otherwise, if the ADD is committed

and the LOAD causes a page fault, software will observe

an incorrect value for the RSI register.

The ROB is tailored for discovering register dependen-

cies between micro-ops. However, micro-ops that exe-

cute out-of-order can also have memory dependencies.

For this reason, out-of-order engines have a load buffer

and a store buffer that keep track of in-ﬂight memory op-

erations and are used to resolve memory dependencies.

2.10.2 Speculative Execution

Branch instructions, also called branches, change the

instruction pointer (RIP,

2.6), if a condition is met (the

branch is taken). They implement conditional statements

(

) and looping statements, such as

while

and

for

The most well-known branching instructions in the Intel

architecture are in the

jcc

family, such as

(jump if

equal).

Branches pose a challenge to the decode stage, because

the instruction that should be fetched after a branch is

not known until the branching condition is evaluated. In

order to avoid stalling the decode stage, modern CPU

designs include branch predictors that use historical in-

formation to guess whether a branch will be taken or

not.

When the decode stage encounters a branch instruc-

tion, it asks the branch predictor for a guess as to whether

the branch will be taken or not. The decode stage bun-

dles the branch condition and the predictor’s guess into

a branch check micro-op, and then continues decoding

on the path indicated by the predictor. The micro-ops

following the branch check are marked as speculative.

When the branch check micro-op is executed, the

branch unit checks whether the branch predictor’s guess

was correct. If that is the case, the branch check is retired

successfully. The scheduler handles mispredictions by

squashing all the micro-ops following the branch check,

and by signaling the instruction decoder to ﬂush the

micro-op decode queue and start fetching the instruc-

tions that follow the correct branch.

Modern CPUs also attempt to predict memory read pat-

terns, so they can prefetch the memory locations that are

about to be read into the cache. Prefetching minimizes

the latency of successfully predicted read operations, as

their data will already be cached. This is accomplished

by exposing circuits called prefetchers to memory ac-

cesses and cache misses. Each prefetcher can recognize

a particular access pattern, such as sequentially read-

ing an array’s elements. When memory accesses match

the pattern that a prefetcher was built to recognize, the

prefetcher loads the cache line corresponding to the next

memory access in its pattern.

2.11 Cache Memories

At the time of this writing, CPU cores can process data

≈ 200×

faster than DRAM can supply it. This gap is

bridged by an hierarchy of cache memories, which are

orders of magnitude smaller and an order of magnitude

faster than DRAM. While caching is transparent to ap-

plication software, the system software is responsible for

managing and coordinating the caches that store address

translation (§ 2.5) results.

Caches impact the security of a software system in

two ways. First, the Intel architecture relies on system

software to manage address translation caches, which

becomes an issue in a threat model where the system soft-

ware is untrusted. Second, caches in the Intel architecture

are shared by all the software running on the computer.

This opens up the way for cache timing attacks, an entire

class of software attacks that rely on observing the time

differences between accessing a cached memory location

and an uncached memory location.

This section summarizes the caching concepts and im-

plementation details needed to reason about both classes

of security problems mentioned above. [

170

], [

150

] and

[

] provide a good background on low-level cache im-

plementation concepts.

3.8 describes cache timing

attacks.

2.11.1 Caching Principles

At a high level, caches exploit the high locality in the

memory access patterns of most applications to hide the

main memory’s (relatively) high latency. By caching

(storing a copy of) the most recently accessed code and

data, these relatively small memories can be used to

satisfy 90%-99% of an application’s memory accesses.

In an Intel processor, the ﬁrst-level (L1) cache consists

of a separate data cache (D-cache) and an instruction

cache (I-cache). The instruction fetch and decode stage

is directly connected to the L1 I-cache, and uses it to read

the streams of instructions for the core’s logical proces-

sors. Micro-ops that read from or write to memory are

executed by the memory unit (MEM in Figure 23), which

is connected to the L1 D-cache and forwards memory

accesses to it.

Figure 25 illustrates the steps taken by a cache when it

receives a memory access. First, a cache lookup uses the

memory address to determine if the corresponding data

exists in the cache. A cache hit occurs when the address

is found, and the cache can resolve the memory access

quickly. Conversely, if the address is not found, a cache

miss occurs, and a cache ﬁll is required to resolve the

memory access. When doing a ﬁll, the cache forwards

the memory access to the next level of the memory hierar-

chy and caches the response. Under most circumstances,

a cache ﬁll also triggers a cache eviction, in which some

data is removed from the cache to make room for the

data coming from the ﬁll. If the data that is evicted has

been modiﬁed since it was loaded in the cache, it must be

written back to the next level of the memory hierarchy.

Cache

Lookup

Cache

Eviction

Cache

Fill

Look for a cache

line storing A

Found?

Return data

associated with A

Get A from the

next memory level

Choose a cache line

that can store A

Found?

Write the cache line

to the next level

Store the data at A

in the free line

miss

YES

hit

YES

Is the line dirty?

Mark the line

available

YES

Look for a free cache

line that can store A

Figure 25

: The steps taken by a cache memory to resolve an access

to a memory address A. A normal memory access (to cacheable

DRAM) always triggers a cache lookup. If the access misses the

cache, a ﬁll is required, and a write-back might be required.

Table 8 shows the key characteristics of the memory

hierarchy implemented by modern Intel CPUs. Each

core has its own L1 and L2 cache (see Figure 23), while

the L3 cache is in the CPU’s uncore (see Figure 22), and

is shared by all the cores in the package.

The numbers in Table 8 suggest that cache placement

can have a large impact on an application’s execution

time. Because of this, the Intel architecture includes

an assortment of instructions that give performance-

sensitive applications some control over the caching

of their working sets.

PREFETCH

instructs the CPU’s

prefetcher to cache a speciﬁc memory address, in prepa-

剩余117页未读，继续阅读

yeeshowyu

粉丝: 0
资源: 2

"深度解析Intel SGX：保障计算机安全性的最详实材料"

SGX技术的分析和研究.pdf

基于Intel SGX的Kerberos安全增强方案.pdf

Intel SGX SDK Developer Reference for Windows OS.pdf

基于Intel SGX的安全数据去重方法_.pdf

基于SGX的Hadoop KMS安全增强方案.pdf

基于SGX的区块链交易隐私安全保护方法.pdf

sgx.zip_SGX

20210924-SGX-IFS Capital： Advancing Enterprise Financing.pdf

论文研究-基于SGX的安全容器的动态迁移 .pdf

最新资源