All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Andy Lutomirski <luto@amacapital.net>,
	Dave Hansen <dave.hansen@intel.com>
Cc: Andrew Lutomirski <luto@kernel.org>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	X86 ML <x86@kernel.org>,
	Platform Driver <platform-driver-x86@vger.kernel.org>,
	nhorman@redhat.com, npmccallum@redhat.com, "Ayoun,
	Serge" <serge.ayoun@intel.com>,
	shay.katz-zamir@intel.com, linux-sgx@vger.kernel.org,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v14 09/19] x86/mm: x86/sgx: Signal SEGV_SGXERR for #PFs w/ PF_SGX
Date: Mon, 01 Oct 2018 07:29:03 -0700	[thread overview]
Message-ID: <1538404143.30715.27.camel@intel.com> (raw)
In-Reply-To: <CALCETrXByb2UVuZ6AXUeOd8y90NAikbZuvdN3wf_TjHZ+CxNhA@mail.gmail.com>

On Wed, 2018-09-26 at 14:15 -0700, Andy Lutomirski wrote:
> On Wed, Sep 26, 2018 at 1:55 PM Dave Hansen <dave.hansen@intel.com> wrote:
> > 
> > 
> > On 09/26/2018 01:44 PM, Sean Christopherson wrote:
> > > 
> > > On Wed, Sep 26, 2018 at 01:16:59PM -0700, Dave Hansen wrote:
> > > > 
> > > > We also need to clarify how this can happen.  Is it through something
> > > > than an app does, or is it solely when the hardware does something under
> > > > the covers, like suspend/resume.
> > > Are you looking for something in the changelog, the comment, or just
> > > a response?  If it's the latter...
> > Comments, please.
> > 
> > > 
> > > On bare metal with a bug-free kernel, the only scenario I'm aware of
> > > where we'll encounter these faults is when hardware pulls the rug out
> > > from under us.  In a virtualized environment all bets are off because
> > > the architecture allows VMMs to silently "destroy" the EPC at will,
> > > e.g. KVM, and I believe Hyper-V, will take advantage of this behavior
> > > to support live migration.  Post migration, the destination system
> > > will generate PF_SGX because the EPC{M} can't be migrated between
> > > system, i.e. the destination EPCM sees all EPC pages as invalid.
> > OK, cool.
> > 
> > That's good background fodder for the changelog.
> > 
> > But, for the comment, I'm happy with something like this:
> > 
> >         /*
> >          * The fault resulted from violation of SGX-specific access-
> >          * controls.  This is expected to be the result of some lower
> >          * layer action (CPU suspend/resume, VM migration) and is
> >          * not related to anything the OS did.  Treat it as an access
> >          * error to ensure it is passed up to the app via a signal where
> >          * it can be handled.
> >          */
> > 
> > I really don't think we need to delve too deeply into the relationship
> > between EPCM and PTEs or anything.  Let's just say, "it's not the
> > kernel's fault, it's not the app's fault, so throw up our hands".
> There is a non-nitpicky consideration here.  Logically, user code is
> going to do this (totally made-up pseudocode):
> 
> enclave_t enclave = load_and_init_enclave(...);
> int ret = sgx_run(enclave, some pointers to non-enclave-memory buffers, ...);
> 
> and, with the code in this patch, a correct implementation of
> sgx_run() requires installing a signal handler.  This is nasty, since
> signal handlers, expecially for something like SIGSEGV or SIGBUS, are
> not fantastic to say the least in libraries.
>
> 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?


If we want to avoid having to install a signal handler then I'm pretty
sure we'd need to fixup all #GPs and "bad access" #PFs that occur on
EENTER or in the enclave, not just PF_SGX faults.  SGX1 hardware takes
a #GP instead of a #PF on EPCM faults, and SGX2 hardware allows enclaves
to allocate/free/adjust EPC pages at runtime, e.g. an enclave runtime
might want to intercept #PFs from within the enclave so that the enclave
can dynamically grow its stack.

> On Windows, this is much less of a concern, because Windows has real
> scoped fault handling. But Linux doesn't, at least not yet.
> 
> 
> --
> Andy Lutomirski
> AMA Capital Management, LLC

WARNING: multiple messages have this Message-ID (diff)
From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Andy Lutomirski <luto@amacapital.net>,
	Dave Hansen <dave.hansen@intel.com>
Cc: Andrew Lutomirski <luto@kernel.org>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	X86 ML <x86@kernel.org>,
	Platform Driver <platform-driver-x86@vger.kernel.org>,
	<nhorman@redhat.com>, <npmccallum@redhat.com>,
	"Ayoun, Serge" <serge.ayoun@intel.com>,
	<shay.katz-zamir@intel.com>, <linux-sgx@vger.kernel.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "Borislav Petkov" <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v14 09/19] x86/mm: x86/sgx: Signal SEGV_SGXERR for #PFs w/ PF_SGX
Date: Mon, 1 Oct 2018 07:29:03 -0700	[thread overview]
Message-ID: <1538404143.30715.27.camel@intel.com> (raw)
In-Reply-To: <CALCETrXByb2UVuZ6AXUeOd8y90NAikbZuvdN3wf_TjHZ+CxNhA@mail.gmail.com>

On Wed, 2018-09-26 at 14:15 -0700, Andy Lutomirski wrote:
> On Wed, Sep 26, 2018 at 1:55 PM Dave Hansen <dave.hansen@intel.com> wrote:
> > 
> > 
> > On 09/26/2018 01:44 PM, Sean Christopherson wrote:
> > > 
> > > On Wed, Sep 26, 2018 at 01:16:59PM -0700, Dave Hansen wrote:
> > > > 
> > > > We also need to clarify how this can happen.  Is it through something
> > > > than an app does, or is it solely when the hardware does something under
> > > > the covers, like suspend/resume.
> > > Are you looking for something in the changelog, the comment, or just
> > > a response?  If it's the latter...
> > Comments, please.
> > 
> > > 
> > > On bare metal with a bug-free kernel, the only scenario I'm aware of
> > > where we'll encounter these faults is when hardware pulls the rug out
> > > from under us.  In a virtualized environment all bets are off because
> > > the architecture allows VMMs to silently "destroy" the EPC at will,
> > > e.g. KVM, and I believe Hyper-V, will take advantage of this behavior
> > > to support live migration.  Post migration, the destination system
> > > will generate PF_SGX because the EPC{M} can't be migrated between
> > > system, i.e. the destination EPCM sees all EPC pages as invalid.
> > OK, cool.
> > 
> > That's good background fodder for the changelog.
> > 
> > But, for the comment, I'm happy with something like this:
> > 
> >         /*
> >          * The fault resulted from violation of SGX-specific access-
> >          * controls.  This is expected to be the result of some lower
> >          * layer action (CPU suspend/resume, VM migration) and is
> >          * not related to anything the OS did.  Treat it as an access
> >          * error to ensure it is passed up to the app via a signal where
> >          * it can be handled.
> >          */
> > 
> > I really don't think we need to delve too deeply into the relationship
> > between EPCM and PTEs or anything.  Let's just say, "it's not the
> > kernel's fault, it's not the app's fault, so throw up our hands".
> There is a non-nitpicky consideration here.  Logically, user code is
> going to do this (totally made-up pseudocode):
> 
> enclave_t enclave = load_and_init_enclave(...);
> int ret = sgx_run(enclave, some pointers to non-enclave-memory buffers, ...);
> 
> and, with the code in this patch, a correct implementation of
> sgx_run() requires installing a signal handler.  This is nasty, since
> signal handlers, expecially for something like SIGSEGV or SIGBUS, are
> not fantastic to say the least in libraries.
>
> 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?


If we want to avoid having to install a signal handler then I'm pretty
sure we'd need to fixup all #GPs and "bad access" #PFs that occur on
EENTER or in the enclave, not just PF_SGX faults.  SGX1 hardware takes
a #GP instead of a #PF on EPCM faults, and SGX2 hardware allows enclaves
to allocate/free/adjust EPC pages at runtime, e.g. an enclave runtime
might want to intercept #PFs from within the enclave so that the enclave
can dynamically grow its stack.

> On Windows, this is much less of a concern, because Windows has real
> scoped fault handling. But Linux doesn't, at least not yet.
> 
> 
> --
> Andy Lutomirski
> AMA Capital Management, LLC

  parent reply	other threads:[~2018-10-01 14:29 UTC|newest]

Thread overview: 184+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-25 13:06 [PATCH v14 00/19] Intel SGX1 support Jarkko Sakkinen
2018-09-25 13:06 ` Jarkko Sakkinen
2018-09-25 13:06 ` Jarkko Sakkinen
2018-09-25 13:06 ` Jarkko Sakkinen
2018-09-25 13:06 ` [PATCH v14 01/19] x86/sgx: Update MAINTAINERS Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06 ` [PATCH v14 02/19] x86/sgx: Architectural structures Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06 ` [PATCH v14 03/19] x86/cpufeature: Add SGX and SGX_LC CPU features Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06 ` [PATCH v14 04/19] x86/cpufeatures: Add SGX feature bits Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 16:48   ` Borislav Petkov
2018-09-25 16:48     ` Borislav Petkov
2018-09-25 16:48     ` Borislav Petkov
2018-09-26 11:11     ` Jarkko Sakkinen
2018-09-26 11:11       ` Jarkko Sakkinen
2018-09-26 11:11       ` Jarkko Sakkinen
2018-09-26 11:36       ` Borislav Petkov
2018-09-26 11:36         ` Borislav Petkov
2018-09-27 13:16         ` Jarkko Sakkinen
2018-09-27 13:16           ` Jarkko Sakkinen
2018-09-27 13:51           ` Borislav Petkov
2018-09-27 13:51             ` Borislav Petkov
2018-09-27 14:52             ` Jarkko Sakkinen
2018-09-27 14:52               ` Jarkko Sakkinen
2018-09-25 13:06 ` [PATCH v14 05/19] x86/msr: Add SGX definitions to msr-index.h Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06 ` [PATCH v14 06/19] x86/mm: x86/sgx: Add new 'PF_SGX' page fault error code bit Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06 ` [PATCH v14 07/19] x86/fault: x86/mm/pkeys: relocate stale comment regarding OSPKE Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06 ` [PATCH v14 08/19] signal: x86/sgx: Add SIGSEGV siginfo code for SGX EPCM fault Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-26 19:14   ` Sean Christopherson
2018-09-26 19:14     ` Sean Christopherson
2018-09-26 19:14     ` Sean Christopherson
2018-09-27 18:41   ` Eric W. Biederman
2018-09-27 18:41     ` Eric W. Biederman
2018-09-27 18:41     ` Eric W. Biederman
2018-09-25 13:06 ` [PATCH v14 09/19] x86/mm: x86/sgx: Signal SEGV_SGXERR for #PFs w/ PF_SGX Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 22:53   ` Andy Lutomirski
2018-09-25 22:53     ` Andy Lutomirski
2018-09-26 17:35     ` Sean Christopherson
2018-09-26 17:35       ` Sean Christopherson
2018-09-26 18:12       ` Andy Lutomirski
2018-09-26 18:12         ` Andy Lutomirski
2018-09-26 20:16         ` Dave Hansen
2018-09-26 20:16           ` Dave Hansen
2018-09-26 20:44           ` Sean Christopherson
2018-09-26 20:44             ` Sean Christopherson
2018-09-26 20:49             ` Dave Hansen
2018-09-26 20:49               ` Dave Hansen
2018-09-26 21:15               ` Andy Lutomirski
2018-09-26 21:15                 ` Andy Lutomirski
2018-09-26 21:45                 ` Dave Hansen
2018-09-26 21:45                   ` Dave Hansen
2018-09-26 22:37                   ` Andy Lutomirski
2018-09-26 22:37                     ` Andy Lutomirski
2018-09-27 14:21                     ` Jarkko Sakkinen
2018-09-27 14:21                       ` Jarkko Sakkinen
2018-09-27 14:41                       ` Andy Lutomirski
2018-09-27 14:41                         ` Andy Lutomirski
2018-09-27 13:56                   ` Jarkko Sakkinen
2018-09-27 13:56                     ` Jarkko Sakkinen
2018-10-01 21:42                     ` Jethro Beekman
2018-10-01 22:03                       ` Dave Hansen
2018-10-31 21:30                         ` Sean Christopherson
2018-10-31 21:30                           ` Sean Christopherson
2018-10-31 21:35                           ` Dave Hansen
2018-10-31 21:35                             ` Dave Hansen
2018-10-31 21:53                             ` Jethro Beekman
2018-10-31 21:58                               ` Dave Hansen
2018-10-31 22:52                                 ` Andy Lutomirski
2018-10-31 22:52                                   ` Andy Lutomirski
2018-11-01 17:51                                   ` Dave Hansen
2018-11-01 17:52                                     ` Andy Lutomirski
2018-11-01 17:52                                       ` Andy Lutomirski
2018-11-01 17:42                           ` Jarkko Sakkinen
2018-11-01 17:42                             ` Jarkko Sakkinen
2018-11-01 17:42                             ` Jarkko Sakkinen
2018-11-01 17:44                             ` Jarkko Sakkinen
2018-11-01 17:44                               ` Jarkko Sakkinen
2018-11-01 17:44                               ` Jarkko Sakkinen
2018-10-02  0:31                       ` Jarkko Sakkinen
2018-10-02  0:31                         ` Jarkko Sakkinen
2018-10-01 14:29                 ` Sean Christopherson [this message]
2018-10-01 14:29                   ` Sean Christopherson
2018-10-01 14:41                   ` Dave Hansen
2018-10-01 14:41                     ` Dave Hansen
2018-10-02  0:07                   ` Jarkko Sakkinen
2018-10-02  0:07                     ` Jarkko Sakkinen
2018-09-27 13:42           ` Jarkko Sakkinen
2018-09-27 13:42             ` Jarkko Sakkinen
2018-09-27 14:58             ` Dave Hansen
2018-09-27 14:58               ` Dave Hansen
2018-09-27 15:39               ` Jarkko Sakkinen
2018-09-27 15:39                 ` Jarkko Sakkinen
2018-09-27 15:53                 ` Dave Hansen
2018-09-27 15:53                   ` Dave Hansen
2018-09-27 13:14     ` Jarkko Sakkinen
2018-09-27 13:14       ` Jarkko Sakkinen
2018-09-27 19:43   ` Eric W. Biederman
2018-09-27 19:43     ` Eric W. Biederman
2018-09-27 19:43     ` Eric W. Biederman
2018-09-28 12:17     ` Jarkko Sakkinen
2018-09-28 12:17       ` Jarkko Sakkinen
2018-09-25 13:06 ` [PATCH v14 10/19] x86/sgx: Detect Intel SGX Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 20:02   ` Randy Dunlap
2018-09-25 20:02     ` Randy Dunlap
2018-09-25 20:02     ` Randy Dunlap
2018-09-27 13:13     ` Jarkko Sakkinen
2018-09-27 13:13       ` Jarkko Sakkinen
2018-09-27 13:13       ` Jarkko Sakkinen
2018-09-25 13:06 ` [PATCH v14 11/19] x86/sgx: Add wrappers for ENCLS leaf functions Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 20:01   ` Randy Dunlap
2018-09-25 20:01     ` Randy Dunlap
2018-09-25 20:01     ` Randy Dunlap
2018-09-27 13:12     ` Jarkko Sakkinen
2018-09-27 13:12       ` Jarkko Sakkinen
2018-09-27 13:12       ` Jarkko Sakkinen
2018-09-25 13:06 ` [PATCH v14 12/19] x86/sgx: Add data structures for tracking the EPC pages Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 20:00   ` Randy Dunlap
2018-09-25 20:00     ` Randy Dunlap
2018-09-25 20:00     ` Randy Dunlap
2018-09-27 13:11     ` Jarkko Sakkinen
2018-09-27 13:11       ` Jarkko Sakkinen
2018-09-27 13:11       ` Jarkko Sakkinen
2018-09-25 13:06 ` [PATCH v14 13/19] x86/sgx: Enclave Page Cache (EPC) memory manager Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06 ` [PATCH v14 14/19] x86/sgx: Add sgx_einit() for initializing enclaves Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06 ` [PATCH v14 15/19] platform/x86: Intel SGX driver Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-10-04 18:01   ` Sean Christopherson
2018-10-04 18:01     ` Sean Christopherson
2018-10-04 18:01     ` Sean Christopherson
2018-10-05 11:32     ` Jarkko Sakkinen
2018-10-05 11:32       ` Jarkko Sakkinen
2018-10-05 11:32       ` Jarkko Sakkinen
2018-09-25 13:06 ` [PATCH v14 16/19] platform/x86: Add swapping functionality to the " Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06 ` [PATCH v14 17/19] x86/sgx: Add a simple swapper for the EPC memory manager Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06 ` [PATCH v14 18/19] platform/x86: ptrace() support for the SGX driver Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06 ` [PATCH v14 19/19] x86/sgx: Driver documentation Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:06   ` Jarkko Sakkinen
2018-09-25 13:27   ` Jonathan Corbet
2018-09-25 13:27     ` Jonathan Corbet
2018-09-25 13:27     ` Jonathan Corbet
2018-10-15 20:54   ` Pavel Machek
2018-10-15 20:54     ` Pavel Machek
2018-10-17 23:45     ` Jarkko Sakkinen
2018-10-17 23:45       ` Jarkko Sakkinen
2018-10-18  9:57       ` Pavel Machek
2018-10-18  9:57         ` Pavel Machek
2018-10-19 23:59         ` Jarkko Sakkinen
2018-10-19 23:59           ` Jarkko Sakkinen
2018-10-17 23:56     ` Dave Hansen
2018-10-17 23:56       ` Dave Hansen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1538404143.30715.27.camel@intel.com \
    --to=sean.j.christopherson@intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sgx@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=nhorman@redhat.com \
    --cc=npmccallum@redhat.com \
    --cc=peterz@infradead.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=serge.ayoun@intel.com \
    --cc=shay.katz-zamir@intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.