Re: [PATCH RFC] x86: Add SGX_IOC_ENCLAVE_AUGMENT_PAGES

[Jarkko Sakkinen]

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.

BR, Jarkko