[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <960B34DE67B9E140824F1DCDEC400C0F4E8617BF@ORSMSX116.amr.corp.intel.com>
Date: Thu, 28 Mar 2019 23:19:25 +0000
From: "Xing, Cedric" <cedric.xing@...el.com>
To: Andy Lutomirski <luto@...nel.org>
CC: "Christopherson, Sean J" <sean.j.christopherson@...el.com>,
"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>,
"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
> It's certainly making progress. I like the fact that the callback is
> now unconditional (if non-NULL) rather than being used just in case of
> certain exit types. But, if we go down this route, let's name and
> document it appropriately -- just call the function "callback" and
> document it as a function that is called just before
> __vdso_sgx_enter_enclave returns, to be used if support for legacy
> enclaves that push data onto the untrusted stack is needed. We should
> further document that it's safe to longjmp out of it.
>
> Also, the tests in tools/testing/selftests/x86/unwind_vdso.c should be
> augmented to test this code.
>
> Finally, why does the vDSO code bother checking whether the leaf is
> valid?
I can document it. I'll look into unwind_vdso.c to see what kind of selftests will make sense here. And I'll send out a RFC patch with everything included. Or would you prefer to have my changes integrated into Jarkko's patch v20?
Different ENCLU leaf has different parameters. This vDSO API knows how to load up parameters only for EENTER and ERESUME so it errs on all other positive values. 0 and negative values are interpreted as return codes.
Powered by blists - more mailing lists