contain memory accesses within the enclave?

[Fan]

I'm wondering if it is possible to restrict the enclave code from accessing ordinary memory, namely memory outside of the enclave. This can be a useful feature in general I think. Consider the case where one wants to contain the information going out of the enclave even the enclave code is maliciously written (by an insider, or a careless engineer).

Doing so naively requires OS cooperation, i.e. OS has to set up the page table properly, which is certainly out of the question in the context of SGX since OS is already out of the TCB. So I'm wondering if SGX provides any support so this can be achieved earlier?

Thanks!

Fan

[Min_X_]

First, I think a code inside enclave is restricted to access data inside its enclave only. I am not sure whether you could jump out of an enclave without invoking the OCALL interface, and I think it's not allowed. Also, you can not tamper with the OCALL table to bypass the indirection as they are integrity-protected.

Second, even though enclave memory pages could be executable, they are all ring 3 instructions, which implies the difficulties in taking control of the underlying system. One possibility may be loading an interpreter inside the enclave and parse the bytes inside the enclave into privilege instructions. But I don't see what a processor can do with that. 

Min

[Fan]

Min X. wrote:

First, I think a code inside enclave is restricted to access data inside its enclave only. I am not sure whether you could jump out of an enclave without invoking the OCALL interface, and I think it's not allowed. Also, you can not tamper with the OCALL table to bypass the indirection as they are integrity-protected.

Second, even though enclave memory pages could be executable, they are all ring 3 instructions, which implies the difficulties in taking control of the underlying system. One possibility may be loading an interpreter inside the enclave and parse the bytes inside the enclave into privilege instructions. But I don't see what a processor can do with that. 

Min

Enclave code can read/write the whole memory space per paging policy. Mostly, an enclave is just part of a larger application, so the enclave can at least read/write pages owned by the application.

[Min_X_]

I see your points. I was kind of surprised that SGX does not constraint the memory access inside enclave (In fact, only the code fetches from outside of enclave is prohibited). As far as I can see, it only requires some extra page table checks.

However, even with the paging restrictions, malicious codes could still bypass these restrictions via OCALLs to write enclave data to the outside of enclave. And I think to mitigate this requires extra software defenses.

[Kirchengast__Felix]

I had a look at the "SGX explained" paper: eprint.iacr.org/2016/086.pdf On page 67 the synchronous enclave exit with the EEXIT instruction is explained. The enclave restores the host process RIP, RSP, RBP and other registers before switching back to the host process using EEXIT. Therefore a malicious enclave is able to setup registers and jump to an arbitrary location within the host process.

I suppose that this threat could be mitigated using a pure software solution by using enclave sandboxing. I propose to run the enclave within a small sand-boxed wrapper host process which does nothing else but forwarding IPC calls to the enclave. As a sand-boxing mechanism for the host process, a strict seccomp policy might be applied to prevent exploits and/or malicious code within the enclave from taking over the control of your system.

Is there any plan to include such a software sandboxing mechanism within the official SGX sdk?