On Mon, Mar 16, 2020 at 04:50:26PM -0700, Xing, Cedric wrote: > On 3/16/2020 3:53 PM, Sean Christopherson wrote: > >On Mon, Mar 16, 2020 at 11:38:24PM +0200, Jarkko Sakkinen wrote: > >>>My suggestions explicitly maintained robustness, and in fact increased > >>>it. If you think we've lost capability, please speak with specificity > >>>rather than in vague generalities. Under my suggestions we can: > >>>1. call the vDSO from C > >>>2. pass context to the handler > >>>3. have additional stack manipulation options in the handler > >>> > >>>The cost for this is a net 2 additional instructions. No existing > >>>capability is lost. > >> > >>My vague generality in this case is just that the whole design > >>approach so far has been to minimize the amount of wrapping to > >>EENTER. > > > >Yes and no. If we wanted to minimize the amount of wrapping around the > >vDSO's ENCLU then we wouldn't have the exit handler shenanigans in the > >first place. The whole process has been about balancing the wants of each > >use case against the overall quality of the API and code. > > > The design of this vDSO API was NOT to minimize wrapping, but to allow > maximal flexibility. More specifically, we strove not to restrict how info > was exchanged between the enclave and its host process. After all, calling > convention is compiler specific - i.e. the enclave could be built by a > different compiler (e.g. MSVC) that doesn't share the same list of CSRs as > the host process. Therefore, the API has been implemented to pass through > virtually all registers except those used by EENTER itself. Similarly, all > registers are passed back from enclave to the caller (or the exit handler) > except those used by EEXIT. %rbp is an exception because the vDSO API has to > anchor the stack, using either %rsp or %rbp. We picked %rbp to allow the > enclave to allocate space on the stack. And unless I'm missing something, using %rcx to pass @leaf would still satisfy the above, correct? Ditto for saving/restoring %rbx. I.e. a runtime that's designed to work with enclave's using a different calling convention wouldn't be able to take advantage of being able to call the vDSO from C, but neither would it take on any meaningful burden.
