lkml.org 
[lkml]   [2018]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v14 09/19] x86/mm: x86/sgx: Signal SEGV_SGXERR for #PFs w/ PF_SGX
Date
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

[unhandled content-type:application/pkcs7-signature]
\
 
 \ /
  Last update: 2018-10-01 23:45    [W:0.401 / U:1.836 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site