Notes on Intel’s SGX

Intel® Software Guard Extensions Programming Reference
329298-002US OCTOBER 2014 (See “SGX” on this page.)

The subject matter seems to suffer from the fact that ‘you can’t say everything first’.

Sec 1.3 Typo: "The software inside the enclave"/"the software inside the enclave"

EPC (Enclave Page Cache) is described on Page 40. Real DRAM is allocated by the BIOS at boot I suppose. Perhaps registers PRMRR are not rewritable after boot. (??) Quote: “Details are implementation specific.” which means not yet committed. A bit of DRAM is either in EPC or not as decreed by BIOS. There is thus a simple test of a physical address that determines whether it points into the EPC.
It is factory anointed but the factory is not Intel’s fab, but the white-box vendor’s factory. At least that is Intel’s plan. What if ‘malicious privileged code’ countermands the BIOS? Section 3.5.1 is now at the root of all my questions.

I guess that an SECS is encrypted by the same key as its enclave.

Terminology: “internal micro-architecture structure”

Semantics: “Intel SGX provides a set of instructions for adding and removing content to and from the EPC.”
is ‘content’ bits or page frames? (BIT or REF BIT?)

Semantics: “... the contents of the EPC are protected by an encryption engine.”
Where is that engine? Does it encrypt and authenticate? (Section 3.5.1 bears on this.) (Authentication takes extra bits! Search for “integrity” and “replay”.) They say how a program learns which of these are provided, but they don’t say how they provide them. They often cop-out with “implementation dependent”. This is not Hollywood’s paranoid manual yet, but it is a beginning. If you do no more than double DRAM access time then you can encrypt or decrypt a cache line for a DRAM access with a pretty good Feistel mechanism. The key would have to depend somehow and the address. I don't know how to thwart replay attacks efficiently.

Terminology: “SECS identifier”
I suppose that an ‘identifier’ is very much like a physical address.

It seems clear that the EPCM is indexed by physical page address within the EPC—a core table.

I leave section 1.7.2 for now as it relies on jargon which is presumably found in the processor manual.

I translate what Intel says in section 2.1 into my terminology. I hope this is accurate.
The memory of an enclave exists in a contiguous range of virtual addresses of some non-enclave program. Any valid pages in that range must be mapped to physical addresses in the EPC. Allocation of page frame in EPC to an enclave is done by privileged code whereupon that page frame in EPC becomes valid. The privileged code ensures that the memory map refers to EPC pages but SGX mechanisms ensure this upon loading the TLB.

Section 1.5.1: The ‘core table’ for EPC holds the virtual address of the page in some enclave. This means no page aliasing is allowed and a real page cannot appear in two spaces.

Section 2.2: Enclave code uses virtual addresses to access its memory. (This seems awkward!) Magic SGX instructions, (which are non enclave instructions), use virtual addresses to refer to parts of enclave space.

Section 3.4: “Each processor is provisioned with a unique key as the root of the key hierarchy.”
I presume this is a ‘private key’ in the public key jargon. I am curious to know its size.

Section 6.11.2 relates the protected memory to the other ‘super privileged modes’.

Here is what I assume as I read. I will try to remember to modify this as I confirm or refute.
There is on-chip public key crypto to support talking to peers that are remote agents. The only thing I can think of now is that Intel serves as a CA (not X.509) and signs public keys that match private keys held exclusively on some particular x86 chip.

Earlier Comments on other sources

This is a white paper from Intel about a proposed(?) hardware feature of their x86 line. It is vague on what relies on what but the graphics of this slide set capture that vital perspective better. I have not studied it closely but I am rather skeptical. Section 2 of this paper describes the plan credibly.

For other SGX information click on button with text “INTEL® SGX” in this where Intel publishes many details about processor features as yet undelivered. I suppose that this is in support of organizations like gcc that do not agree to NDA terms and whose products are important to Intel.

Late blooming surprises, some of which would have been useful earlier.

There are memory structures, such as SECS, that ‘cannot be accessed by software’. I would say that they are moving part of the kernel to microcode.

There is one EPC (Enclave Page Cache) in a system.

Critical points:
“replay” occurs just three times in the document with no hint of how they provide integrity except thru replay protection and no hint of how they provide replay detection. There may be a notion that replay attacks can only impact integrity without impacting security. This is unclear. The reasons that classic crypto adopted BCC over simply encrypting each block deprecates SGX encryption, as well as most (all?) disk encryption schemes. I recall that Schneier explains this. Roughly traffic analysis gets much more info by watching the address stream, muffled by caching logic.
Software bugs
Just because Intel moves kernel like logic to hardware does not mean there are no bugs in the hardware algorithms. Hardware designers have a better reputation for getting things right, but mainly because their algorithms are simpler. That reason is getting frayed.
This mechanism seems designed mainly allow code running on many distributed systems to rely on a local Intel supplied security kernel and the secure system of some software vendor, as stakeholder. It is not immediately clear if it supports the local stakeholder, namely the owner of the machine.
Strong Integrity
Alan Karp likes to say that integrity means the right things happen while security means that only the right things happen. SGX introduces another category. The right thing happen as long as the enclave gets time.
Secure Path
I have not heard a story yet on a trusted path between the user and the enclave.

Other useful insights: Rutkowska; See this on attestation. too. xx
Note command “PCOMMIT” on ppage 1198 of this manual.