Enclave operations that require an OCall, such as thread synchronization and I/O, are exposed to the untrusted domain. An enclave must be designed in such a way that it prevents leaking side-channel information that would allow an attacker, who is looking at the untrusted functions called from an enclave, to gain insight into enclave secrets, see Section Protection from Side-Channel Attacks for additional information.
An enclave must be prepared to handle the scenario where the OCall function is not performed at all. The return value from an OCall, which is an enclave input, comes from the untrusted domain and must not be relied upon. It might appear that an OCall has been successfully completed when it has not. For instance, an attacker might drop an enclave’s request to write sealed data to disk and tell the enclave the file was written successfully.
An enclave cannot depend on nested ECalls occurring in certain order during an OCall. A developer may limit the ECalls that are allowed during a given OCall, since the state information (corresponding to the OCall in progress) can be stored inside the enclave. However, once an enclave makes an OCall there is no guarantee the untrusted domain will not recursively call into the enclave, and the enclave has no control over the order in which nested ECalls occur or the actual ISV interface functions invoked.