Re: [PATCH v19,RESEND 24/27] x86/vdso: Add __vdso_sgx_enter_enclave() to wrap SGX enclave transitions

[Andy Lutomirski <luto@kernel.org>]

On Wed, Mar 20, 2019 at 11:30 AM Xing, Cedric <cedric.xing@intel.com> 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.)