On 2018-09-27 06:56, Jarkko Sakkinen wrote:
On Wed, Sep 26, 2018 at 02:45:17PM -0700, Dave Hansen wrote:On 09/26/2018 02:15 PM, Andy Lutomirski wrote:Could we perhaps have a little vDSO entry (or syscall, I suppose) that runs an enclave an returns an error code, and rig up the #PF handler to check if the error happened in the vDSO entry and fix it up rather than sending a signal?For me this plan sounds simple and sound.
I support avoiding the need for a signal handler for various SGX-specific operations. Looking forward to v15.
I have some thoughts regarding the design of the vDSO function. Please consider the following as you work on the next patch set.
1) Even though the vDSO function exists, userspace may still call `ENCLU[EENTER]` manually, so the fault handling as described in the current patch should also be maintained.
2) All the information that would normally be provided through the signal handler (x86 fault number, reason) should be provided to userspace.
3) vDSO functions should be provided for all standard non-enclave ENCLU leafs, and should support most ways that an application might want to use. This includes:
* EENTER with a automatic AEX handler (as in Jarkko's sgx_get_token example)* EENTER & ERESUME with a user-specified AEX handler, or possibly just a special return value from the ENCLU function on AEX
4) I think the vDSO functions should have a special calling convention (not conforming to the standard SysV ABI), such that most registers are passed between user space and enclave space untouched. Basically, only RAX, RBX, RCX are available as input and output registers.
-- Jethro Beekman | Fortanix
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
