On Sun, Mar 06, 2022 at 09:20:11AM -0600, Haitao Huang wrote:
> On Fri, 04 Mar 2022 07:50:43 -0600, Jarkko Sakkinen <jarkko@xxxxxxxxxx>
> wrote:
>
> > 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@xxxxxxxxx>
> > > Cc: Nathaniel McCallum <nathaniel@xxxxxxxxxxx>
> > > Signed-off-by: Jarkko Sakkinen <jarkko@xxxxxxxxxx>
> > > ---
> > > 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.
> >
> EACCEPTCOPY will require target pages with RW in PTE. So you would need to
> make mprotect to change PTE permissions afterwards depending on your target
> permissions.
EACCEPTCOPY afaik does depend on EPCM permissions, not PTE permissions.
> Without knowing much your context, if your intent is to
> EACCEPTCOPY(EPCM.RX/EPCM.R, EPCM.pending), then I don't see how the page can
> be used later without making it RW again first, and copy real data into it.
> So these empty EACCEPTCOPYs may be better just EACCEPTs(EPCM.RW,
> EPCM.pending). Then after copy real data into the pages, you do
> EMODPE/EMODPR as needed.
I take this point other than we could potentially use EACCEPTCOPY to
implement semantics for e.g. a mapped file. But yes sometimes you will
need take W out bit EMODPR, you're right.
The key problem in the SGX2 patch set is not EPCM side but PTE side.
In order to effectively adjust PTE permissions, vm_max_prot_bits
should be RWX. They make sense only for the static signed content
at most.
If that is changed in the current patch set, then it should be fairly
easy to tune both PTE and EPCM permissions based on situation.
BR, Jarkko
