Re: [PATCH v14 09/19] x86/mm: x86/sgx: Signal SEGV_SGXERR for #PFs w/ PF_SGX

[Jethro Beekman]

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