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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <960B34DE67B9E140824F1DCDEC400C0F4E85DA80@ORSMSX116.amr.corp.intel.com>
Date:   Fri, 22 Mar 2019 20:31:17 +0000
From:   "Xing, Cedric" <cedric.xing@...el.com>
To:     Andy Lutomirski <luto@...nel.org>
CC:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-sgx@...r.kernel.org" <linux-sgx@...r.kernel.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "Christopherson, Sean J" <sean.j.christopherson@...el.com>,
        "nhorman@...hat.com" <nhorman@...hat.com>,
        "npmccallum@...hat.com" <npmccallum@...hat.com>,
        "Ayoun, Serge" <serge.ayoun@...el.com>,
        "Katz-zamir, Shay" <shay.katz-zamir@...el.com>,
        "Huang, Haitao" <haitao.huang@...el.com>,
        "andriy.shevchenko@...ux.intel.com" 
        <andriy.shevchenko@...ux.intel.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "Svahn, Kai" <kai.svahn@...el.com>, "bp@...en8.de" <bp@...en8.de>,
        "josh@...htriplett.org" <josh@...htriplett.org>,
        "Huang, Kai" <kai.huang@...el.com>,
        "rientjes@...gle.com" <rientjes@...gle.com>,
        "Dave Hansen" <dave.hansen@...ux.intel.com>,
        Haitao Huang <haitao.huang@...ux.intel.com>,
        Jethro Beekman <jethro@...tanix.com>,
        "Dr . Greg Wettstein" <greg@...ellic.com>
Subject: RE: [PATCH v19,RESEND 24/27] x86/vdso: Add
 __vdso_sgx_enter_enclave() to wrap SGX enclave transitions

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