linux-sgx.vger.kernel.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).