lkml.org 
[lkml]   [2020]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v39 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call
    From
    Date
    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.christopherson@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.

    --
    Jethro Beekman | Fortanix


    [unhandled content-type:application/pkcs7-signature]
    \
     
     \ /
      Last update: 2020-10-06 10:31    [W:2.193 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site