Showing results for 
Search instead for 
Did you mean: 

EMODPE, EACCEPTCOPY and exception handling


I'm have two questions related EMODPE and EACCEPTCOPY SGXv2 instructions. (I'm using the NUC 7CJYH and working on porting large databases inside the enclave efficiently.)

  1. Is there a way to restrict the permission of a page from inside the exception handler. For example, let's say a page inside my enclave has Read and Write permissions, but I want to restrict the permission to Read-only inside the exception handler. How do I achieve this? It seems the EMODPE instruction can only extend the page permission and the only way to restrict the permission is to make an ocall which will call the SGX driver to restrict the permission.

    The problem is, ocalls are not allowed inside the exception handler, and there seems to be no way to restrict the permission of a page from exception handler. (Since the enclave doesn't trust the OS, I'm not sure if making an ocall to restrict permission is even a good idea? Why can't an enclave reduce it's own privileges? Just look at any secure system and they all have capability to reduce their own permissions.)
  2. I was under the impression that EACCEPTCOPY can efficiently copy 1 page from outside (or inside) the enclave to inside the enclave. But that doesn't seem to be the case. EACCEPTCOPY can only copy a page from inside the enclave to another page also inside the enclave? Why this restriction?

    Note that if I pass a pointer from outside the enclave, I can just memcopy from outside pointer so restricting EACCEPTCOPY to EPC pages only doesn't seem to make much sense. Inability to copy pages from outside the enclave to inside is a performance bottleneck if one wants to do database processing inside the enclave.

Is there a formal process to request making changes to the instruction set so that SGX/SGXv2 can actually work for real-world applications? Unfortunately, the 128Kb physical memory limit and poorly designed instruction sets (which I thought would be fixed in SGXv2) make it impossible to build a secure and performant server applications running inside SGX.


0 Kudos
2 Replies

Because this permission is at the process level, you really cannot change the permission to read-only for the thread that has the exception. It is because that there may be other threads running so the architecture will not allow to change.


Hoang Nguyen, you have misunderstood my question. I'm not asking to change the permission of a given thread. I want to turn a R/W page into a read only page without making an ocall or OS involvement.

If the SGX threat model is that it doesn't trust the OS, it seems like a massive oversight that an enclave cannot restrict it's own page permissions and has to ask the OS to restrict its permissions. That's like building a super secure house, but to close a door inside your house, you have to go outside and ask criminals on the street to come in and close a door for you. This threat model doesn't make sense to me. (And yes I know the enclave needs to EACCEPT, etc. but that whole machinery is full of its own problems).