On Wed, Mar 20, 2019 at 11:30 AM Xing, Cedric <cedric.xing@xxxxxxxxx> wrote: > > > +/** > > + * __vdso_sgx_enter_enclave() - Enter an SGX enclave > > + * > > + * %eax: ENCLU leaf, must be EENTER or ERESUME > > + * %rbx: TCS, must be non-NULL > > + * %rcx: Optional pointer to 'struct sgx_enclave_exception' > > + * > > + * Return: > > + * 0 on a clean entry/exit to/from the enclave > > + * -EINVAL if ENCLU leaf is not allowed or if TCS is NULL > > + * -EFAULT if ENCLU or the enclave faults > > + * > > + * Note that __vdso_sgx_enter_enclave() is not compliant with the x86- > > 64 ABI. > > + * All registers except RSP must be treated as volatile from the > > +caller's > > + * perspective, including but not limited to GPRs, EFLAGS.DF, MXCSR, > > FCW, etc... > > + * Conversely, the enclave being run must preserve the untrusted RSP > > and stack. > > By requiring preservation of RSP at both AEX and EEXIT, this precludes the possibility of using the untrusted stack as temporary storage by enclaves. While that looks reasonable at first glance, I'm afraid it isn't the case in reality. The untrusted stack is inarguably the most convenient way for data exchange between an enclave and its enclosing process, and is in fact being used for that purpose by almost all existing enclaves to date. Given the expectation that this API will be used by all future SGX application, it looks unwise to ban the most convenient and commonly used approach for data exchange. I'm going to go out on a limb and say that this is a good thing. Using the untrusted stack as a way to exchange data is very convenient, but that doesn't mean it's a good idea. Here are some problems it causes: - It prevents using a normal function to wrap enclave entry (as we're seeing with this patch set). - It makes quite a few unfortunate assumptions about the layout of the untrusted stack. It assumes that the untrusted stack is arbitrarily expandable, which is entirely untrue in languages like Go. It assumes that the untrusted stack isn't further constrained by various CFI mechanisms (e.g. CET), and, as of last time I checked, the interaction between CET and SGX was still not specified. It also assumes that the untrusted stack doesn't have ABI-imposed layout restrictions related to unwinding, and, as far as I know, this means that current enclaves with current enclave runtimes can interact quite poorly with debuggers, exception handling, and various crash dumping technologies. - It will make it quite unpleasant to call into an enclave in a coroutine depending on how the host untrusted runtime implements coroutines. So I think it's a *good* thing if the effect is to make enclave SDKs change their memory management so that untrusted buffers are explicitly supplied by the host runtime. Honestly, I would have much preferred if the architecture did not give the enclave access to RSP and RBP at all. (And, for that matter, RIP.)
