Hi Andy,
> > > - It will make it quite unpleasant to call into an enclave in a
> > > coroutine depending on how the host untrusted runtime implements
> > > coroutines.
> >
> > I'm not sure what you are referring to by "coroutine". But this vDSO
> API will be (expected to be) the only routine that actually calls into
> an enclave. Isn't that correct?
>
> I mean use in languages and runtimes that allow a function and its
> callees to pause and then resume later. Something like (pseudocode,
> obviously):
>
> void invoke_the_enclave()
> {
> do_eenter_through_vdso();
> }
>
> void some_ocall_handler(void *ptr)
> {
> yield;
> }
Thank you very much for your detailed explanation. This looks more about
whether or not the untrusted stack will remain valid after EEXIT, than whether
the ocall will be paused or not. As in your example code above, a problem may
occur if "yield" destroys the stack of its caller. But is that a common
behavior of "yield" (or any scheduler at all)?
Your point is well received though - Not every enclave can/shall assume
existence or size of an untrusted stack. Therefore I've made sure my proposal
will work no matter the enclave touches the untrusted stack or not.
>
> If the enclave has ptr pointing to the untrusted stack, then this gets
> quite awkward for the runtime to handle efficiently. IMO a much nicer
> approach would be:
>
> void invoke_the_enclave()
> {
> char buffer[1024];
> while (true)
> {
> eenter (through vdso);
> if (exit was an ocall request) {
> some_ocall_handler(buffer);
> }
> }
> }
>
> And now there is nothing funny happening behind the runtime's back when
> some_ocall_handler tries to yield.
Agreed.
In fact, Mr. Christopherson's API could be implemented using mine as a
subroutine (please see below). So your "nicer approach" will continue to work
as long as it works with current patch. However, please keep in mind that your
"nicer" approach doesn't have to be the "only" approach.
The code snippet below shows an equivalent implementation of Mr.
Christopherson's API using mine as a subroutine, except that RBP cannot be used
as a parameter to the enclave because it will be overwritten before EENTER. To
distinguish his API and mine, they are renamed to
__vdso_sgx_enter_enclave_Christopherson and __vdso_sgx_enter_enclave_Xing,
respectively.
__vdso_sgx_enter_enclave_Christopherson:
push $0 /* No "exit callback" provided */
push %rcx /* Optional pointer to 'struct sgx_enclave_exception' */
push %rbx /* TCS */
call __vdso_sgx_enter_enclave_Xing
add $24, %rsp
ret
Thanks!
-Cedric
