linux-sgx.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Haitao Huang" <haitao.huang@linux.intel.com>
To: "Jarkko Sakkinen" <jarkko.sakkinen@linux.intel.com>,
	"Sean Christopherson" <sean.j.christopherson@intel.com>
Cc: linux-sgx@vger.kernel.org
Subject: Re: [PATCH for_v23 0/7] x86/sgx: Improve add pages ioctl
Date: Wed, 09 Oct 2019 22:28:36 -0500	[thread overview]
Message-ID: <op.z9fc9yu4wjvjmi@hhuan26-mobl.amr.corp.intel.com> (raw)
In-Reply-To: <20191009044241.3591-1-sean.j.christopherson@intel.com>

On Tue, 08 Oct 2019 23:42:34 -0500, Sean Christopherson  
<sean.j.christopherson@intel.com> wrote:

> Enhance the SGX_IOC_ENCLAVE_ADD_PAGE{S} ioctl so that userspace can add
> multiple pages to an enclave in a single syscall.  Also provide a flag
> that allows replicating a single source page to multiple target pages so
> that userspace doesn't need to allocate a giant chunk of memory when
> initializing things like the enlave's .bss, heap, etc...
>
> People that actually develop runtimes, please weigh in.  Jarkko also
> suggested going with a fully flexible ioctl, e.g. essentially creating an
> array of the existing struct so that mrmask and/or secinfo can be unique
> per page.  AFAICT that's overkill and more cumbersome to use as it forces
> userspace to allocate the full array.  My understanding is that the
> majority of enclaves will have contiguous blocks of pages with identical
> mrmask and secinfo, e.g. code segments, ro data, etc..., thus the less
> flexible but easier-in-theory to use approach proposed here.
>
We think using the same mask for all pages (solution in this patch set) is  
reasonable. Although it seems odd that all pages would apply the same  
mask, this allows enough flexibility we can foresee.

Another option acceptable to us (Intel SGX runtime) is to change it to a  
flag and have bit zero define whether the whole page is measured via  
EEXTEND. This is simpler and allows other bits reserved for future usages.  
However, it would fail any SGX runtime that is measuring partial page for  
optimization purposes.

  parent reply	other threads:[~2019-10-10  3:28 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-09  4:42 [PATCH for_v23 0/7] x86/sgx: Improve add pages ioctl Sean Christopherson
2019-10-09  4:42 ` [PATCH for_v23 1/7] x86/sgx: Modify ADD_PAGE ioctl to take offset instead of full address Sean Christopherson
2019-10-09  4:42 ` [PATCH for_v23 2/7] selftests/x86/sgx: Update test to account for ADD_PAGE change Sean Christopherson
2019-10-09  4:42 ` [PATCH for_v23 3/7] x86/sgx: Tweak ADD_PAGE ioctl to allow adding multiple pages Sean Christopherson
2019-10-14 21:32   ` Jarkko Sakkinen
2019-10-14 21:35     ` Jarkko Sakkinen
2019-10-14 23:31       ` Sean Christopherson
2019-10-16 10:17         ` Jarkko Sakkinen
2019-10-16 10:19           ` Jarkko Sakkinen
2019-10-16 10:29             ` Jarkko Sakkinen
2019-10-21 11:24               ` Jarkko Sakkinen
2019-10-09  4:42 ` [PATCH for_v23 4/7] selftests/x86/sgx: Update enclave build flow to do multi-page add Sean Christopherson
2019-10-09  4:42 ` [PATCH for_v23 5/7] x86/sgx: Add a flag to ADD_PAGES to allow replicating the source page Sean Christopherson
2019-10-09  4:42 ` [PATCH for_v23 6/7] selftests/x86/sgx: Update selftest to account for ADD_PAGES flag Sean Christopherson
2019-10-09  4:42 ` [PATCH for_v23 7/7] selftests/x86/sgx: Add test coverage for reclaim and replicate Sean Christopherson
2019-10-10  3:28 ` Haitao Huang [this message]
2019-10-11 14:37   ` [PATCH for_v23 0/7] x86/sgx: Improve add pages ioctl Sean Christopherson
2019-10-13 15:15     ` Dr. Greg

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=op.z9fc9yu4wjvjmi@hhuan26-mobl.amr.corp.intel.com \
    --to=haitao.huang@linux.intel.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=linux-sgx@vger.kernel.org \
    --cc=sean.j.christopherson@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).