mmap(), #PF handler and EADD interaction

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.

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

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;

Aah so it was. Can you send me a patch to extend the kdoc with additional paragraph to remark this?

/Jarkko