Re: mmap(), #PF handler and EADD interaction

[Sean Christopherson <sean.j.christopherson@intel.com>]

On Mon, Aug 19, 2019 at 06:24:31PM +0300, Jarkko Sakkinen wrote:
> I did some backtracking today how the permission flow worked.
> 
> With the maximum VM flags defined for a page, what if EADD is done after
> mmap()?  E.g. we first do mmap() with RWX and later EADD with lets say
> RW.

sgx_encl_may_map() returns -EACCESS on any attempt to mmap()/mprotect() a
range that is not fully covered by EADD'd pages with any of PROT_READ,
PROT_WRITE or PROT_EXEC.  This is handled in the !page check below.

	if (!page || (~page->vm_prot_bits & vm_prot_bits))
		return -EACCES;

A waiver is given for PROT_NONE, primarily so that mmap() can be used
prior to ECREATE to find an available ELRANGE, but any attempt to access
a PROT_NONE VMA will result in a SIGSEGV, e.g. access_error() explicitly
checks the RWX prot bits.

	/* PROT_NONE always succeeds. */
	if (!vm_prot_bits)
		return 0;


> 
> The first thing that comes to mind is that the #PF handler should caught
> this corner case.
> 
> Now the code correctly validates when you do either mmap() and
> mprotect() after EADD(s) but I think "other way around" is missing.
> 
> /Jarkko