All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko@kernel.org>
To: Dave Hansen <dave.hansen@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 04:32:12 +0200	[thread overview]
Message-ID: <YiLLrDure3canJYy@iki.fi> (raw)
In-Reply-To: <YiLISeGl1mpzY/09@kernel.org>

On Sat, Mar 05, 2022 at 04:17:53AM +0200, Jarkko Sakkinen wrote:
> On Fri, Mar 04, 2022 at 09:08:20AM -0800, Dave Hansen wrote:
> > On 3/4/22 04:28, Jarkko Sakkinen wrote:
> > > 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.
> > 
> > So this is basically an optimization?  It's MADV_WILLNEED or
> > MAP_POPULATE to the cost of avoid future faults?
> 
> Yes.
> 
> So the idea would be that based on these the #PF handler would have more
> smartness, and it would do a batch of EAUG's?
> 
> That could be possibly acceptable but I also had other concern.
> 
> I would like to see this:
> 
> 1. Removal of vm_run_prot_bits.
> 2. Use RWX vm_max_prot_bits for EAUG'd pages.
> 
> During run-time kernel controls PTE's, and enclave has full control of the
> EPCM (EACCEPT, EACCEPTCOPY, EMODPE). By creating artificial limitations how
> to operate with these, it can limit various optimizations in the user space
> code. E.g. a syscall shim can require clever co-operation between in-enclave
> opcodes and what you do with the kernel in various situations.
> 
> RWX sounds provocative yes, but here it means only the limits where kernel
> can set its PTE's and nothing else, not that page table is filled with RWX
> pages, and enclave dictates what is in EPCM, and that's how it actually
> should be (e.g. you can sometimes deliver mmap() without ever going out
> of the enclave with EMODPE).
> 
> If MADV_WILLNEED/MAP_POPULATE approach is combined with this what I
> discussed here, then I think we could have solution to write an efficient
> memory management shims.

Do you already have a rough idea what needs to be done? I can take anyway a
look but just in case you had processed this further, please tell what you
have.

BR, Jarkko

  reply	other threads:[~2022-03-05  2:33 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
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 [this message]
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=YiLLrDure3canJYy@iki.fi \
    --to=jarkko@kernel.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --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 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.