On Tue, Oct 06, 2020 at 10:30:16AM +0200, Jethro Beekman wrote:
> On 2020-10-06 04:57, Sean Christopherson wrote:
> > On Sat, Oct 03, 2020 at 07:50:56AM +0300, Jarkko Sakkinen wrote:
> >> From: Sean Christopherson <sean.j.christopher...@intel.com>
> >> +  /* Validate that the reserved area contains only zeros. */
> >> +  push    %rax
> >> +  push    %rbx
> >> +  mov     $SGX_ENCLAVE_RUN_RESERVED_START, %rbx
> >> +1:
> >> +  mov     (%rcx, %rbx), %rax
> >> +  cmpq    $0, %rax
> >> +  jne     .Linvalid_input
> >> +
> >> +  add     $8, %rbx
> >> +  cmpq    $SGX_ENCLAVE_RUN_RESERVED_END, %rbx
> >> +  jne     1b
> >> +  pop     %rbx
> >> +  pop     %rax
> > 
> > This can more succinctly be (untested):
> > 
> >     movq    SGX_ENCLAVE_RUN_RESERVED_1(%rbp), %rbx  
> >     orq     SGX_ENCLAVE_RUN_RESERVED_2(%rbp), %rbx  
> >     orq     SGX_ENCLAVE_RUN_RESERVED_3(%rbp), %rbx  
> >     jnz     .Linvalid_input
> > 
> > Note, %rbx is getting clobbered anyways, no need to save/restore it.
> > 
> >> diff --git a/arch/x86/include/uapi/asm/sgx.h 
> >> b/arch/x86/include/uapi/asm/sgx.h
> >> index b6ba036a9b82..3dd2df44d569 100644
> >> --- a/arch/x86/include/uapi/asm/sgx.h
> >> +++ b/arch/x86/include/uapi/asm/sgx.h
> >> @@ -74,4 +74,102 @@ struct sgx_enclave_provision {
> >>    __u64 attribute_fd;
> >>  };
> >>  
> >> +struct sgx_enclave_run;
> >> +
> >> +/**
> >> + * typedef sgx_enclave_user_handler_t - Exit handler function accepted by
> >> + *                                        __vdso_sgx_enter_enclave()
> >> + * @run:  Pointer to the caller provided struct sgx_enclave_run
> >> + *
> >> + * The register parameters contain the snapshot of their values at enclave
> >> + * exit
> >> + *
> >> + * Return:
> >> + *  0 or negative to exit vDSO
> >> + *  positive to re-enter enclave (must be EENTER or ERESUME leaf)
> >> + */
> >> +typedef int (*sgx_enclave_user_handler_t)(long rdi, long rsi, long rdx,
> >> +                                    long rsp, long r8, long r9,
> >> +                                    struct sgx_enclave_run *run);
> >> +
> >> +/**
> >> + * struct sgx_enclave_run - the execution context of 
> >> __vdso_sgx_enter_enclave()
> >> + * @tcs:                  TCS used to enter the enclave
> >> + * @user_handler:         User provided callback run on exception
> >> + * @user_data:                    Data passed to the user handler
> >> + * @leaf:                 The ENCLU leaf we were at (EENTER/ERESUME/EEXIT)
> >> + * @exception_vector:             The interrupt vector of the exception
> >> + * @exception_error_code: The exception error code pulled out of the stack
> >> + * @exception_addr:               The address that triggered the exception
> >> + * @reserved                      Reserved for possible future use
> >> + */
> >> +struct sgx_enclave_run {
> >> +  __u64 tcs;
> >> +  __u64 user_handler;
> >> +  __u64 user_data;
> >> +  __u32 leaf;
> > 
> > I am still very strongly opposed to omitting exit_reason.  It is not at all
> > difficult to imagine scenarios where 'leaf' alone is insufficient for the
> > caller or its handler to deduce why the CPU exited the enclave.  E.g. see
> > Jethro's request for intercepting interrupts.
> 
> Not entirely sure what this has to do with my request, I just expect
> to see leaf=ERESUME in this case, I think? E.g. as you would see in
> EAX when calling ENCLU.

The documentation needs to be fixed but the answer is yes.

I.e.

- Leaf will contain ERESUME on interrupt.
- Leaf will contain EEXIT on normal exit.

Maybe I should rename it as exit_leaf and rewrite the description to
improve clarity?

/Jarkko

Reply via email to