linux-sgx.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko@kernel.org>
To: linux-sgx@vger.kernel.org
Cc: 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: Fri, 04 Mar 2022 15:50:43 +0200	[thread overview]
Message-ID: <13e0c364328ed822c5d358416bb13aa5faea3195.camel@kernel.org> (raw)
In-Reply-To: <20220304122852.563475-1-jarkko@kernel.org>

On Fri, 2022-03-04 at 14:28 +0200, Jarkko Sakkinen 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

I created sgx2-v2.2 branch, which has #PF EAUG removed. I
also moved selftests to the tail in the patch sets so that
it is easier to update them reflecting these and future
changes. Having them intervened makes things just complicated.

I focus now to implement mmap() for Enarx with this, so no
kselftest update just yet.

Roughly the sequence in Enarx is:

1. Enclave traps on syscall (opcode).
2. Host jumps to shim expection handler.
3. Enclave copies the mmap() arguments to a buffer outside
   the enclave.
4. Enclave exists back to the host.
5. Host performs EAUG to the mmap range.
6. Host performs mmap() to the mmap range, which succeeds
   given that vm_max_prot_bits is RWX (i.e. disabled for
   dynamic pages).
7. Host jumps back to the enclave and execution continues
   there in the mmap handler.
8. mmap handler does a series of EACCEPTCOPY operations for
   the range with given permissions and empty page as the
   input data.

Some details might differ a bit but this gives the basic idea.
I like the fact the roud-trips are kind of in control and not
variable, and it is pretty easy to use to implement the basic
syscall behaviour. This has of course some corner cases but
my sequence describes the main flow anyway.

Take it or leave it but this does give at least for me a sound
way to implement my workload. I'll use this up until my changes
have been inducted to the original patch set, or it starts to
look sane with other solutions. The original patch set simply
does not work for us at all.

BR, Jarkko

  reply	other threads:[~2022-03-04 13:51 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 [this message]
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
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=13e0c364328ed822c5d358416bb13aa5faea3195.camel@kernel.org \
    --to=jarkko@kernel.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@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;
as well as URLs for NNTP newsgroup(s).