All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: linux-sgx@vger.kernel.org
Subject: Re: [PATCH v2 2/5] x86/sgx: Reject concurrent ioctls on single enclave
Date: Thu, 29 Aug 2019 09:00:01 -0700	[thread overview]
Message-ID: <20190829160001.GD26580@linux.intel.com> (raw)
In-Reply-To: <20190829131543.ejdsviysr2u33rnj@linux.intel.com>

On Thu, Aug 29, 2019 at 04:15:43PM +0300, Jarkko Sakkinen wrote:
> On Tue, Aug 27, 2019 at 12:27:14PM -0700, Sean Christopherson wrote:
> > Except for ENCLAVE_SET_ATTRIBUTE, all SGX ioctls() must be executed
> > serially to successfully initialize an enclave, e.g. the kernel already
> > strictly requires ECREATE->EADD->EINIT, and concurrent EADDs will result
> > in an unstable MRENCLAVE.  Explicitly enforce serialization by returning
> > EINVAL if userspace attempts an ioctl while a different ioctl for the
> > same enclave is in progress.
> > 
> > The primary beneficiary of explicit serialization is sgx_encl_grow() as
> > it no longer has to deal with dropping and reacquiring encl->lock when
> > a new VA page needs to be allocated.  Eliminating the lock juggling in
> > sgx_encl_grow() paves the way for fixing a lock ordering bug in
> > ENCLAVE_ADD_PAGE without having to also juggle mm->mmap_sem.
> > 
> > Serializing ioctls also fixes a race between ENCLAVE_CREATE and
> > ENCLAVE_SET_ATTRIBUTE, as the latter does not take encl->lock, e.g.
> > concurrent updates to allowed_attributes could result in a stale
> > value.  The race could also be fixed by taking encl->lock or making
> > allowed_attributes atomic, but both add unnecessary overhead with this
> > change applied.
> > 
> > Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
> 
> #PF handler should be good as it has this conditional:
> 
> flags = atomic_read(&encl->flags);
> 
> if ((flags & SGX_ENCL_DEAD) || !(flags & SGX_ENCL_INITIALIZED))
> 	return ERR_PTR(-EFAULT);
> 
> What about the reclaimer?

Can you elaborate?  I'm not sure what you're asking.

  reply	other threads:[~2019-08-29 16:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-27 19:27 [PATCH v2 0/5] x86/sgx: Fix lock ordering bug w/ EADD Sean Christopherson
2019-08-27 19:27 ` [PATCH v2 1/5] x86/sgx: Convert encl->flags from an unsigned int to an atomic Sean Christopherson
2019-08-29 13:09   ` Jarkko Sakkinen
2019-08-29 15:59     ` Sean Christopherson
2019-08-29 18:01       ` Jarkko Sakkinen
2019-08-30  0:02     ` Sean Christopherson
2019-08-27 19:27 ` [PATCH v2 2/5] x86/sgx: Reject concurrent ioctls on single enclave Sean Christopherson
2019-08-29 13:15   ` Jarkko Sakkinen
2019-08-29 16:00     ` Sean Christopherson [this message]
2019-08-29 18:14       ` Jarkko Sakkinen
2019-08-29 18:43         ` Sean Christopherson
2019-08-29 22:22           ` Jarkko Sakkinen
2019-08-27 19:27 ` [PATCH v2 3/5] x86/sgx: Take encl->lock inside of mm->mmap_sem for EADD Sean Christopherson
2019-08-27 19:27 ` [PATCH v2 4/5] x86/sgx: Reject all ioctls on dead enclaves Sean Christopherson
2019-08-27 19:27 ` [PATCH v2 5/5] x86/sgx: Destroy the enclave if EEXTEND fails Sean Christopherson

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=20190829160001.GD26580@linux.intel.com \
    --to=sean.j.christopherson@intel.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=linux-sgx@vger.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.