mmap(), #PF handler and EADD interaction

mmap(), #PF handler and EADD interaction

[Jarkko Sakkinen]

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

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

[Sean Christopherson]

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

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

[Jarkko Sakkinen]

On Mon, Aug 19, 2019 at 10:54:21AM -0700, Sean Christopherson wrote:
> 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.

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

/Jarkko