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’.
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.
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.