Using embedded GPU within an Enclave

[SANJAY_S_]

Is it possible for the embedded GPU to access the enclave just like the CPU and for the enclave to contain code meant for the GPU ?

[Simon_J_Intel]

No...

More extensively. No device can access SGX memory.

[SANJAY_S_]

Thanks for the reply !

I was of the impression that the secure perimeter was the entire processor, including the embedded GPU. Can you explain why the embedded GPU isn't part of the perimeter and point me to relevant documentation ? Are there plans to include it in the future ?

[Hoang_N_Intel]

Is this for a specific embedded GPU which I can help look up its specification? Or is this just a theoretical question for future plan?

[Chi__Chi_Ching]

I would like to know if it would be in some future plan. More specifically I am interested if it would be possible to have 3d application fully in enclave. Ideally also ofcourse with a discrete gpu.

[Dr__Greg]

Good morning, I hope the week is starting well for everyone.

Sanjay raises an interesting question, one that is rooted in the basic security model of SGX, the notion that the root of trust is only the processor die.  Simon responded (greetings to Simon from the SGX guys and their dog out in North Dakota), indicating that no device can access SGX memory.  Since its inception in 2010 as Intel HD Graphics, the model for Intel Graphics Technology (GT) has been to manufacture the graphics processing unit on the same die as the CPU with shared access to physical memory.  At this point in time the common understanding is that more die space is allocated to the graphics engine then the CPU proper.

So Sanjay in quote #3 above raises a valid issue, why wouldn't the GPU be able to access enclave memory, given that it resides within the physical trusted computing base of SGX.  This is a particularly interesting question given the existence, since the Sandy Bridge micro-architecture, of "Intel Insider" which supports DRM through the decryption of a protected media stream within the processor itself.  Given the origins of SGX as a DRM technology a suspicious individual would suspect some degree of incestuousness between the two technologies.  Of course given the nature and politics of DRM and content protection the details of all that would be more protected then information about the availability of SGX2.... :-)

So while Simon's statement is correct, no devices can access SGX memory, most devices don't exist within the same physical protection domain as the processor, which does have access to SGX memory.

If there is an actual physical prohibition of access to SGX protected memory by the integrated GPU, it may be secondary to the hardware protection model that was designed for SGX.  Readers who are interested in all this may find our paper/blog post about SGX and micro-architectural vulnerabilities a useful starting point as it discusses the virtual memory model that SGX security is built on:

https://idfusionllc.com/2018/01/25/sgx-after-spectre-and-meltdown-status-analysis-and-remediations

ftp://ftp.idfusion.net/pub/sgx/sgx-spectre-meltdown.pdf

The physical security guarantee for SGX is built on the notion of a Processor Reserved Memory (PRM) aperture which is a range of physical memory defined by the Processor Reserved Memory Range Registers (PRMRR).  The BIOS/firmware defines this memory range when the physical hardware is initialized.  This range of physical memory can only be accessed by the processor and serves as the memory which supports the Enclave Page Cache (EPC) and presumably the Enclave Page Cache Map (EPCM).

The physical security guarantees for SGX memory are implemented by the Memory Encryption Engine (MEE) which supports a rather complex set of confidentiality and integrity guarantees.  Shay Geuron's paper, "A Memory Encryption Engine Suitable for General Purpose Processors", has a complete discussion of the guarantees, their rationale and proofs of correctness.  Details are sketchy but one would anticipate that the memory controller is wired/designed in a manner that allows only the MEE to access PRM.

So while the integrated graphics processor may reside within the same physical trust domain of SGX it presumably does not have access, by design, to the PRM.  This doesn't suggest that it couldn't have access to the PRM but a decision was presumably made to not allow that access.  Given the potential attack surface represented by a GPU such a decision would not be unwarranted from a security perspective, particularly given the fact that Intel represents SGX as a technology where only highly privileged data and/or code are stored in a protected memory region/enclave.

Hopefully the above provides a possible framework for future discussion.

Now back to figuring out why remote attestation has gone awry for a large body of hardware out in the wild....

Have a good day.

Dr. Greg