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.
next prev parent 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).