linux-kernel - Re: [PATCH v14 09/19] x86/mm: x86/sgx: Signal SEGV_SGXERR for #PFs w/ PF

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: <ae76dfe7-3587-0d21-37b7-535279edc235@fortanix.com>
Date:   Mon, 1 Oct 2018 21:42:48 +0000
From:   Jethro Beekman <jethro@...tanix.com>
To:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        Dave Hansen <dave.hansen@...el.com>
CC:     Andy Lutomirski <luto@...capital.net>,
        "Christopherson, Sean J" <sean.j.christopherson@...el.com>,
        Andrew Lutomirski <luto@...nel.org>, X86 ML <x86@...nel.org>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        "nhorman@...hat.com" <nhorman@...hat.com>,
        "npmccallum@...hat.com" <npmccallum@...hat.com>,
        "Ayoun, Serge" <serge.ayoun@...el.com>,
        "shay.katz-zamir@...el.com" <shay.katz-zamir@...el.com>,
        "linux-sgx@...r.kernel.org" <linux-sgx@...r.kernel.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v14 09/19] x86/mm: x86/sgx: Signal SEGV_SGXERR for #PFs w/
 PF_SGX

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

Download attachment "smime.p7s" of type "application/pkcs7-signature" (3990 bytes)