public inbox for linux-sgx@vger.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko@kernel.org>
To: Haitao Huang <haitao.huang@linux.intel.com>
Cc: linux-sgx@vger.kernel.org,
	Reinette Chatre <reinette.chatre@intel.com>,
	Nathaniel McCallum <nathaniel@profian.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	"open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" 
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC] x86: Add SGX_IOC_ENCLAVE_AUGMENT_PAGES
Date: Sat, 5 Mar 2022 03:26:12 +0200	[thread overview]
Message-ID: <YiK8NEnvgPerEdFB@iki.fi> (raw)
In-Reply-To: <op.1iilcwhywjvjmi@hhuan26-mobl1.mshome.net>

On Fri, Mar 04, 2022 at 10:27:58AM -0600, Haitao Huang wrote:
> On Fri, 04 Mar 2022 06:28:52 -0600, Jarkko Sakkinen <jarkko@kernel.org>
> wrote:
> 
> > With SGX1 an enclave needs to be created with its maximum memory demands
> > allocated. Pages cannot be added to an enclave after it is initialized.
> > SGX2 introduces a new function, ENCLS[EAUG], that can be used to add
> > pages
> > to an initialized enclave. With SGX2 the enclave still needs to set aside
> > address space for its maximum memory demands during enclave creation, but
> > all pages need not be added before enclave initialization. Pages can be
> > added during enclave runtime.
> > 
> > Add support for dynamically adding pages to an initialized enclave with
> > SGX_IOC_ENCLAVE_AUGMENT_PAGES, which performs EAUG's to a given range of
> > pages. Do not enforce any particular permissions from kernel, like is
> > done
> > for the pages added during the pre-initialization phase, as enclave
> > controls the final permissions and content for these pages by issuing
> > either ENCLU[EACCEPT] (empty RW) or ENCLU[EACCEPTCOPY] (arbitrary data
> > and
> > permissions).
> > 
> > Explicit EAUG ioctl is a better choice than an implicit EAUG from a page
> > fault handler because it allows to have O(1) number of kernel-enclave
> > round
> > trips for EAUG-EACCEPT{COPY} process, instead of O(n), as it is in the
> > case
> > when a page fault handler EAUG single page at a time.
> > 
> > Cc: Reinette Chatre <reinette.chatre@intel.com>
> > Cc: Nathaniel McCallum <nathaniel@profian.com>
> > Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
> > ---
> > Is contained in sgx2-v2.1 branch of
> > git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-sgx.git
> > ---
> >  arch/x86/include/uapi/asm/sgx.h |  14 +++
> >  arch/x86/kernel/cpu/sgx/ioctl.c | 159 ++++++++++++++++++++++++++++++++
> >  2 files changed, 173 insertions(+)
> > 
> > diff --git a/arch/x86/include/uapi/asm/sgx.h
> > b/arch/x86/include/uapi/asm/sgx.h
> > index c4e0326d281d..2b3a606e78fe 100644
> > --- a/arch/x86/include/uapi/asm/sgx.h
> > +++ b/arch/x86/include/uapi/asm/sgx.h
> > @@ -35,6 +35,8 @@ enum sgx_page_flags {
> >  	_IOWR(SGX_MAGIC, 0x06, struct sgx_enclave_modt)
> >  #define SGX_IOC_ENCLAVE_REMOVE_PAGES \
> >  	_IOWR(SGX_MAGIC, 0x08, struct sgx_enclave_remove_pages)
> > +#define SGX_IOC_ENCLAVE_AUGMENT_PAGES \
> > +	_IOWR(SGX_MAGIC, 0x09, struct sgx_enclave_augment_pages)
> > /**
> >   * struct sgx_enclave_create - parameter structure for the
> > @@ -138,6 +140,18 @@ struct sgx_enclave_remove_pages {
> >  	__u64 count;
> >  };
> > +/**
> > + * struct sgx_enclave_augment_pages - parameter structure for the
> > %SGX_IOC_ENCLAVE_ADD_PAGE ioctl
> > + * @offset:	starting page offset
> > + * @length:	length of the data (multiple of the page size)
> > + * @count:	number of bytes added (multiple of the page size)
> > + */
> > +struct sgx_enclave_augment_pages {
> > +	__u64 offset;
> > +	__u64 length;
> > +	__u64 count;
> > +};
> > +
> 
> As I stated in another thread, we need a mechanism to allow EAUG page
> lazily, e.g., on #PF. Can we add a field here to indicate that?

ioctl *does not* prevent lazy behaviour where, or if, it makes sense.

For growing memory (e.g. MAP_GROWSDOWN) you should just take advantage of
the vDSO's exception handling mechanism and call the ioctl on demand.

For a high-performance user space you still want to be also do minimum
round trip "batch jobs" where they are possible.

We exactly have the whole vDSO framework to service the on-demand needs
while still having full control of the execution. EAUG in the #PF handler
is all about being flakky and loosing all robustness.

BR, Jarkko

  reply	other threads:[~2022-03-05  1:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-04 12:28 [PATCH RFC] x86: Add SGX_IOC_ENCLAVE_AUGMENT_PAGES Jarkko Sakkinen
2022-03-04 13:50 ` Jarkko Sakkinen
2022-03-06 15:20   ` Haitao Huang
2022-03-06 16:30     ` Jarkko Sakkinen
2022-03-04 16:27 ` Haitao Huang
2022-03-05  1:26   ` Jarkko Sakkinen [this message]
2022-03-06 13:38     ` Haitao Huang
2022-03-06 16:18       ` Jarkko Sakkinen
2022-03-04 17:08 ` Dave Hansen
2022-03-05  2:17   ` Jarkko Sakkinen
2022-03-05  2:32     ` Jarkko Sakkinen
2022-03-05  2:55       ` 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=YiK8NEnvgPerEdFB@iki.fi \
    --to=jarkko@kernel.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=haitao.huang@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sgx@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=nathaniel@profian.com \
    --cc=reinette.chatre@intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox