All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	linux-sgx@vger.kernel.org, akpm@linux-foundation.org,
	dave.hansen@intel.com, nhorman@redhat.com, npmccallum@redhat.com,
	serge.ayoun@intel.com, shay.katz-zamir@intel.com,
	haitao.huang@intel.com, andriy.shevchenko@linux.intel.com,
	tglx@linutronix.de, kai.svahn@intel.com, bp@alien8.de,
	josh@joshtriplett.org, luto@kernel.org, kai.huang@intel.com,
	rientjes@google.com, cedric.xing@intel.com,
	puiterwijk@redhat.com, linux-security-module@vger.kernel.org,
	Suresh Siddha <suresh.b.siddha@intel.com>
Subject: Re: [PATCH v23 12/24] x86/sgx: Linux Enclave Driver
Date: Wed, 30 Oct 2019 02:30:45 -0700	[thread overview]
Message-ID: <20191030093045.GB12481@linux.intel.com> (raw)
In-Reply-To: <20191029092920.GA14494@linux.intel.com>

On Tue, Oct 29, 2019 at 11:29:20AM +0200, Jarkko Sakkinen wrote:
> On Mon, Oct 28, 2019 at 11:03:12PM +0200, Jarkko Sakkinen wrote:
> > +/**
> > + * sgx_ioc_enclave_add_pages() - The handler for %SGX_IOC_ENCLAVE_ADD_PAGES
> > + * @encl:       pointer to an enclave instance (via ioctl() file pointer)
> > + * @arg:	a user pointer to a struct sgx_enclave_add_pages instance
> > + *
> > + * Add (EADD) one or more pages to an uninitialized enclave, and optionally
> > + * extend (EEXTEND) the measurement with the contents of the page. The range of
> > + * pages must be virtually contiguous. The SECINFO and measurement mask are
> > + * applied to all pages, i.e. pages with different properties must be added in
> > + * separate calls.
> > + *
> > + * A SECINFO for a TCS is required to always contain zero permissions because
> > + * CPU silently zeros them. Allowing anything else would cause a mismatch in
> > + * the measurement.
> > + *
> > + * mmap()'s protection bits are capped by the page permissions. For each page
> > + * address, the maximum protection bits are computed with the following
> > + * heuristics:
> > + *
> > + * 1. A regular page: PROT_R, PROT_W and PROT_X match the SECINFO permissions.
> > + * 2. A TCS page: PROT_R | PROT_W.
> > + * 3. No page: PROT_NONE.
> > + *
> > + * mmap() is not allowed to surpass the minimum of the maximum protection bits
> > + * within the given address range.
> > + *
> > + * As stated above, a non-existent page is interpreted as a page with no
> > + * permissions. In effect, this allows mmap() with PROT_NONE to be used to seek
> > + * an address range for the enclave that can be then populated into SECS.
> > + *
> > + * @arg->addr, @arg->src and @arg->length are adjusted to reflect the
> > + * remaining pages that need to be added to the enclave, e.g. userspace can
> > + * re-invoke SGX_IOC_ENCLAVE_ADD_PAGES using the same struct in response to an
> > + * ERESTARTSYS error.
> > + *
> > + * Return:
> > + *   0 on success,
> > + *   -EINVAL if any input param or the SECINFO contains invalid data,
> > + *   -EACCES if an executable source page is located in a noexec partition,
> > + *   -ENOMEM if any memory allocation, including EPC, fails,
> > + *   -ERESTARTSYS if a pending signal is recognized
> > + */
> > +static long sgx_ioc_enclave_add_pages(struct sgx_encl *encl, void __user *arg)
> 
> This should return the number of pages processed instead of zero on
> success. Kernel needs to be able to cap the amount it will process.

Why?  The number of pages processed is effectively returned via the params
on any error, e.g. wouldn't it be more appropriate to return -ERESTARTSYS?
And I don't see any reason to add an arbitrary cap on the number of pages,
e.g. SGX plays nice with the scheduler and signals, and restricting the
number of EPC pages available to a process via cgroups (returning -ENOMEM)
is a better solution for managing EPC.

  reply	other threads:[~2019-10-30  9:30 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-28 21:03 [PATCH v23 00/24] Intel SGX foundations Jarkko Sakkinen
2019-10-28 21:03 ` [PATCH v23 01/24] x86/sgx: Update MAINTAINERS Jarkko Sakkinen
2019-10-28 21:03 ` [PATCH v23 02/24] x86/cpufeatures: x86/msr: Add Intel SGX hardware bits Jarkko Sakkinen
2019-10-28 21:03 ` [PATCH v23 03/24] x86/cpufeatures: x86/msr: Intel SGX Launch Control " Jarkko Sakkinen
2019-10-28 21:03 ` [PATCH v23 04/24] x86/mm: x86/sgx: Signal SIGSEGV with PF_SGX Jarkko Sakkinen
2019-10-28 21:03 ` [PATCH v23 05/24] x86/sgx: Add SGX microarchitectural data structures Jarkko Sakkinen
2019-10-28 21:03 ` [PATCH v23 06/24] x86/sgx: Add wrappers for ENCLS leaf functions Jarkko Sakkinen
2019-10-28 21:03 ` [PATCH v23 07/24] x86/cpu/intel: Detect SGX supprt Jarkko Sakkinen
2019-10-28 21:03 ` [PATCH v23 08/24] x86/sgx: Enumerate and track EPC sections Jarkko Sakkinen
2019-10-28 21:03 ` [PATCH v23 09/24] x86/sgx: Add functions to allocate and free EPC pages Jarkko Sakkinen
2019-10-28 21:03 ` [PATCH v23 10/24] x86/sgx: Add sgx_einit() for wrapping ENCLS[EINIT] Jarkko Sakkinen
2019-10-28 21:03 ` [PATCH v23 11/24] mm: Introduce vm_ops->may_mprotect() Jarkko Sakkinen
2019-10-28 21:03 ` [PATCH v23 12/24] x86/sgx: Linux Enclave Driver Jarkko Sakkinen
2019-10-29  9:29   ` Jarkko Sakkinen
2019-10-30  9:30     ` Sean Christopherson [this message]
2019-10-31 21:12       ` Jarkko Sakkinen
2019-11-05 11:11         ` Jarkko Sakkinen
2019-11-08  8:20           ` Jarkko Sakkinen
2019-10-30 13:45   ` Stephen Smalley
2019-10-31 21:17     ` Jarkko Sakkinen
2019-11-01 13:16       ` Stephen Smalley
2019-11-01 13:28         ` Stephen Smalley
2019-11-01 15:32           ` Sean Christopherson
2019-11-01 17:16             ` Stephen Smalley
2019-11-08  8:05               ` Jarkko Sakkinen
2019-11-28 18:24   ` Greg KH
2019-12-06 20:38     ` Jarkko Sakkinen
2019-12-07  8:09       ` Greg KH
2019-12-09 19:57         ` Jarkko Sakkinen
2019-12-23 11:01           ` Jarkko Sakkinen
2019-10-28 21:03 ` [PATCH v23 13/24] selftests/x86: Recurse into subdirectories Jarkko Sakkinen
2019-10-28 21:03 ` [PATCH v23 14/24] selftests/x86: Add a selftest for SGX Jarkko Sakkinen
2019-10-28 21:03 ` [PATCH v23 15/24] x86/sgx: Add provisioning Jarkko Sakkinen
2019-10-28 21:03 ` [PATCH v23 16/24] x86/sgx: Add a page reclaimer Jarkko Sakkinen
2019-10-28 21:03 ` [PATCH v23 17/24] x86/sgx: ptrace() support for the SGX driver Jarkko Sakkinen
2019-10-28 21:03 ` [PATCH v23 18/24] x86/vdso: Add support for exception fixup in vDSO functions Jarkko Sakkinen
2019-10-28 21:03 ` [PATCH v23 19/24] x86/fault: Add helper function to sanitize error code Jarkko Sakkinen
2019-10-28 21:03 ` [PATCH v23 20/24] x86/traps: Attempt to fixup exceptions in vDSO before signaling Jarkko Sakkinen
2019-10-28 21:03 ` [PATCH v23 21/24] x86/vdso: Add __vdso_sgx_enter_enclave() to wrap SGX enclave transitions Jarkko Sakkinen
2019-10-28 21:03 ` [PATCH v23 22/24] selftests/x86: Add vDSO selftest for SGX Jarkko Sakkinen
2019-10-28 21:03 ` [PATCH v23 23/24] docs: x86/sgx: Document microarchitecture Jarkko Sakkinen
2019-10-28 21:03 ` [PATCH v23 24/24] docs: x86/sgx: Document kernel internals Jarkko Sakkinen
2019-11-21 15:08 ` [PATCH v23 00/24] Intel SGX foundations Nathaniel McCallum
2019-11-27 21:01   ` 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=20191030093045.GB12481@linux.intel.com \
    --to=sean.j.christopherson@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=cedric.xing@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=haitao.huang@intel.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=josh@joshtriplett.org \
    --cc=kai.huang@intel.com \
    --cc=kai.svahn@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linux-sgx@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=nhorman@redhat.com \
    --cc=npmccallum@redhat.com \
    --cc=puiterwijk@redhat.com \
    --cc=rientjes@google.com \
    --cc=serge.ayoun@intel.com \
    --cc=shay.katz-zamir@intel.com \
    --cc=suresh.b.siddha@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.