What does it implies to disable syscall in Intel SGX

Question

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 open, socket 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.

Answer 1

Right. See local attestation in one of the three papers published by Intel on SGX. The enclave that wants to prove that it is running inside an enclave on an Intel CPU, creates a report inside the enclave(EREPORT). The report does not have any secret in it, but it is MAC'd using the report key, which is accessible and generated inside the enclave . The report is sent to the other enclave through the untrusted channel(Ie, OS provided IPC), and then the report is verified inside the other enclave, which has access to the same report key(shared secret) inside the enclave and can verify the structure integrity using the MAC and report key(shared secret between enclaves). If all the information in the report matches, the two enclaves can trust that they run on the same SGX platform. They can then perform key exchange like DH key exchange or any other way to establish a secure channel and they can communicate with each other securely.