Intel® Software Guard Extensions (Intel® SGX)
Discussion board focused on hardware-based isolation and memory encryption to provide extended code protection in solutions.

What does it implies to disable syscall in Intel SGX

Fan
Beginner
2,437 Views

I'm looking into programming with Intel Software Guard Extensions (SGX) facility recently. The idea of SGX is to create an enclave in which security-sensitive code is loaded and executed. Most importantly memory access (and many other restrictions) to that enclave is enforced by hardware.

In its manual, I found that syscall instruction is illegal inside an enclave (see Table 3-1), along with many other instructions could possibly change privilege level. I wonder what does this imply. Since kernel service like opensocket end up in raising system calls, does it mean that banning syscall instruction actually prohibits code inside the enclave from any kernel service, like file and sockets? It sounds quite unconvincing to me because in that way what an enclave can do would be severely limited. So I think either I misunderstood or there are some work around.

Any help is appreciated. Thanks in advance.

0 Kudos
1 Solution
Surenthar_S_Intel
2,437 Views

Syscall instruction is prohibited inside the enclave. The OS is not a part of the trusted computing base(TCB) in SGX. Lets assume that syscall was enabled inside the enclave and you write instructions in assembly to execute the syscall instruction(lets say with parameters for the open system call sys_open). When you do a syscall you jump to the predefined location setup by the kernel during boot to start executing kernel code. What this means is you are jumping from code written by you(Enclave, which is trusted) to code which is not written by you(OS, which is untrusted). If you were able to do this, it would defeat the security guarantees provided by SGX. Since the kernel/OS/any other software not written by you is untrusted, you could have a malicious kernel whose open system call reads data inside your enclave and steal your secrets.

Workaround:

SGX includes instructions to let you temporarily exit the enclave in order to call untrusted code so that you can perform I/O, make general system calls, etc. and then return to the enclave. This imposes a performance penalty, and you are executing untrusted code during this time (which is not protected by SGX), so this should only be done when necessary and the amount of time spent outside the enclave should be minimized.

View solution in original post

0 Kudos
2 Replies
SHIH_K_Intel
Employee
2,437 Views

This is just my personal opinion.

I interpret the rationale to wish an enclave not having restrictions is kind of like prioritizing complete independence over co-existence with the imperfections of the existing software eco-system. There is cost associated with complete independence, in terms of development cost relative to scope, time-to-market, and addressable market opportunity.  

I believe the enclave that SGX had in mind is geared towards co-existence with the existing horizontal software eco-system, and make it possible for folks who do not wish to carry the burden of building-from-ground-up on every component of a new, large infrastructure. 

To use an analogy, consider an off-grid solar system vs. in-grid. The former provides independence, but wouldn't make that much sense to install in an urban area in turns of economics.

0 Kudos
Surenthar_S_Intel
2,438 Views

Syscall instruction is prohibited inside the enclave. The OS is not a part of the trusted computing base(TCB) in SGX. Lets assume that syscall was enabled inside the enclave and you write instructions in assembly to execute the syscall instruction(lets say with parameters for the open system call sys_open). When you do a syscall you jump to the predefined location setup by the kernel during boot to start executing kernel code. What this means is you are jumping from code written by you(Enclave, which is trusted) to code which is not written by you(OS, which is untrusted). If you were able to do this, it would defeat the security guarantees provided by SGX. Since the kernel/OS/any other software not written by you is untrusted, you could have a malicious kernel whose open system call reads data inside your enclave and steal your secrets.

Workaround:

SGX includes instructions to let you temporarily exit the enclave in order to call untrusted code so that you can perform I/O, make general system calls, etc. and then return to the enclave. This imposes a performance penalty, and you are executing untrusted code during this time (which is not protected by SGX), so this should only be done when necessary and the amount of time spent outside the enclave should be minimized.

0 Kudos
Reply