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, serge.ayoun@intel.com,
	shay.katz-zamir@intel.com
Subject: Re: x86/sgx: v23-rc2
Date: Thu, 10 Oct 2019 10:09:21 -0700	[thread overview]
Message-ID: <20191010170921.GB23798@linux.intel.com> (raw)
In-Reply-To: <20191010132458.GA4112@linux.intel.com>

On Thu, Oct 10, 2019 at 04:37:53PM +0300, Jarkko Sakkinen wrote:
> On Thu, Oct 10, 2019 at 02:37:45PM +0300, Jarkko Sakkinen wrote:
> > tag v23-rc2
> > Tagger: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > Date:   Thu Oct 10 14:33:07 2019 +0300
> > 
> > x86/sgx: v23-rc1 patch set
> > 
> > * Return -EIO instead of -ECANCELED when ptrace() fails to read a TCS page.
> > * In the reclaimer, pin page before ENCLS[EBLOCK] because pinning can fail
> >   (because of OOM) even in legit behaviour and after EBLOCK the reclaiming
> >   flow can be only reverted by killing the whole enclave.
> > * Fixed SGX_ATTR_RESERVED_MASK. Bit 7 was marked as reserved while in fact
> >   it should have been bit 6 (Table 37-3 in the SDM).
> > * Return -EPERM from SGX_IOC_ENCLAVE_INIT when ENCLS[EINIT] returns an SGX
> >   error code.
> > * In v22 __uaccess_begin() was used to pin the source page in
> >   __sgx_encl_add_page(). Switch to get_user_pages() in order to avoid
> >   deadlock (mmap_sem might get locked twice in the same thread).
> 
> __uaccess_begin() is also needed to performan access checks the legit

__uaccess_begin() doesn't check the address space, it temporarily disables
SMAP/SMEP so that the kernel can access a user mapping.  An explicit
access_ok() call should be added as well.

> user space address. What we can do is to use get_user_pages() just to
> make sure that the page is faulted while we perform ENCLS[EADD].


> I updated the master branch with the fix for this. Now the access
> pattern is:
> 
> 	ret = get_user_pages(src, 1, 0, &src_page, NULL);
> 	if (ret < 1)
> 		return ret;
> 
> 	__uaccess_begin();

This should be immediately before __eadd().  I also think it'd be a good
idea to disable page faults around __eadd() so that an unexpected #PF
manifests as an __eadd() failure and not a kernel hang.

> 	pginfo.secs = (unsigned long)sgx_epc_addr(encl->secs.epc_page);
> 	pginfo.addr = SGX_ENCL_PAGE_ADDR(encl_page);
> 	pginfo.metadata = (unsigned long)secinfo;
> 	pginfo.contents = (unsigned long)src;

> 	ret = __eadd(&pginfo, sgx_epc_addr(epc_page));
> 
> 	__uaccess_end();
> 	put_page(src_page);

Not shown here, but mmap_sem doesn't need to be held through EEXTEND. The
lock issue is that down_read() will block if there is a pending
down_write(), e.g. if userspace is doing mprotect() at the same time as
EADD, then deadlock will occur if EADD faults.  Holding encl->lock without
mmap_sem is perfectly ok.

I'll send a small series with the above changes.

  reply	other threads:[~2019-10-10 17:09 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-10 11:37 x86/sgx: v23-rc2 Jarkko Sakkinen
2019-10-10 13:37 ` Jarkko Sakkinen
2019-10-10 17:09   ` Sean Christopherson [this message]
2019-10-10 17:39     ` Sean Christopherson
2019-10-11 16:37 ` Jethro Beekman
2019-10-11 18:15   ` Sean Christopherson
2019-10-14  8:43     ` Jethro Beekman
2019-10-17 17:57       ` Sean Christopherson
2020-02-13 14:10         ` Jethro Beekman
2020-02-15  7:24           ` Jarkko Sakkinen
2020-02-17  8:52             ` Jethro Beekman
2020-02-17 18:55               ` Jarkko Sakkinen
2020-02-17 18:56                 ` Jarkko Sakkinen
2020-02-18 10:42                 ` Dr. Greg Wettstein
2020-02-18 15:00                   ` Andy Lutomirski
2020-02-22  3:16                     ` Dr. Greg
2020-02-22  5:41                       ` Andy Lutomirski
2020-03-01 10:42                         ` Dr. Greg
2020-02-23 17:13                       ` Jarkko Sakkinen
2020-02-18 15:52                   ` Jarkko Sakkinen
2020-02-19 16:26                     ` Dr. Greg
2020-02-20 19:57                       ` Jarkko Sakkinen
2020-02-21  1:19                         ` Dr. Greg
2020-02-21 13:00                           ` Jarkko Sakkinen
2020-03-05 19:51                             ` Sean Christopherson
2020-03-05 20:34                               ` Jethro Beekman
2020-03-05 21:00                                 ` Sean Christopherson
2020-03-06 18:34                               ` Jarkko Sakkinen

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=20191010170921.GB23798@linux.intel.com \
    --to=sean.j.christopherson@intel.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=linux-sgx@vger.kernel.org \
    --cc=serge.ayoun@intel.com \
    --cc=shay.katz-zamir@intel.com \
    /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.