[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ce304dba-0b02-02e2-4de8-212cd3bd1876@fortanix.com>
Date: Mon, 19 Nov 2018 05:17:26 +0000
From: Jethro Beekman <jethro@...tanix.com>
To: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
Andy Lutomirski <luto@...nel.org>
CC: Dave Hansen <dave.hansen@...ux.intel.com>,
"Christopherson, Sean J" <sean.j.christopherson@...el.com>,
Florian Weimer <fweimer@...hat.com>,
Linux API <linux-api@...r.kernel.org>,
Jann Horn <jannh@...gle.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
X86 ML <x86@...nel.org>,
linux-arch <linux-arch@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Rich Felker <dalias@...c.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>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>
Subject: Re: RFC: userspace exception fixups
On 2018-11-18 18:32, Jarkko Sakkinen wrote:
> On Sun, Nov 18, 2018 at 09:15:48AM +0200, Jarkko Sakkinen wrote:
>> On Thu, Nov 01, 2018 at 10:53:40AM -0700, Andy Lutomirski wrote:
>>> Hi all-
>>>
>>> The people working on SGX enablement are grappling with a somewhat
>>> annoying issue: the x86 EENTER instruction is used from user code and
>>> can, as part of its normal-ish operation, raise an exception. It is
>>> also highly likely to be used from a library, and signal handling in
>>> libraries is unpleasant at best.
>>>
>>> There's been some discussion of adding a vDSO entry point to wrap
>>> EENTER and do something sensible with the exceptions, but I'm
>>> wondering if a more general mechanism would be helpful.
>>
>> I haven't really followed all of this discussion because I've been busy
>> working on the patch set but for me all of these approaches look awfully
>> complicated.
>>
>> I'll throw my own suggestion and apologize if this has been already
>> suggested and discarded: return-to-AEP.
>>
>> My idea is to do just a small extension to SGX AEX handling. At the
>> moment hardware will RAX, RBX and RCX with ERESUME parameters. We can
>> fill extend this by filling other three spare registers with exception
>> information.
>>
>> AEP handler can then do whatever it wants to do with this information
>> or just do ERESUME.
>
> A correction here. In practice this will add a requirement to have a bit
> more complicated AEP code (check the regs for exceptions) than before
> and not just bytes for ENCLU.
>
> e.g. AEP handler should be along the lines
>
> 1. #PF (or #UD or) happens. Kernel fills the registers when it cannot
> handle the exception and returns back to user space i.e. to the
> AEP handler.
> 2. Check the registers containing exception information. If they have
> been filled, take whatever actions user space wants to take.
> 3. Otherwise, just ERESUME.
>
> From my point of view this is making the AEP parameter useful. Its
> standard use is just weird (always point to a place just containing
> ENCLU bytes, why the heck it even exists).
I like this solution. Keeps things simple. One question: when an
exception occurs, how does the kernel know whether to set special
registers or send a signal?
--
Jethro Beekman | Fortanix
Download attachment "smime.p7s" of type "application/pkcs7-signature" (3990 bytes)
Powered by blists - more mailing lists